Subject: Re: [Gen-art] Gen-ART review of 04 draft-ietf-appsawg-http-problem-01

From: Erik Wilde <[email-masked]>
Date: Tue, 1 Dec 2015 09:30:35 +0100

On 2015-11-30 14:31, Romascanu, Dan (Dan) wrote:
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
> Document: draft-ietf-appsawg-http-problem-01
> Reviewer:  Dan Romascanu
> Review Date: 11/30/15
> IETF LC End Date: 12/4/15
> IESG Telechat date:
> Summary: Ready (with one clarification question).
>
> Minor issues:
>
> One question which may be a matter of clarification rather than an issue:
>
> In Section 3:
>
> ØIf such additional members are defined, their names SHOULD start with a
> letter (ALPHA, as per [RFC5234]) and SHOULD consist of characters from
> ALPHA, DIGIT, and "_" (so that it can be serialized in formats other
> than JSON), and SHOULD be three characters or longer.
>
> What is the rationale here for the SHOULDs? What are the exception cases
> that require using SHOULD rather than MUST in this paragraph?

at least part of the reason was that the XML serialization would not be 
able to deal with names starting with numbers (because of XML's naming 
rules), and that this should be taken into account when using additional 
members.

on the other hand, the JSON serialization is meant to be the normative 
one, which means that this XML constraint should not mean that any JSON 
using legal JSON names for new members should be considered invalid, 
even if the names do not conform to XML's naming rules.

mark, am i recalling this correctly? thanks,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 1 Dec 2015 10:28:13 +0000

Hi,

Makes sense. Thanks for the clarification.

Regards,

Dan

> -----Original Message-----
> From: Erik Wilde [mailto:[email-masked]]
> Sent: Tuesday, December 01, 2015 10:31 AM
> To: Romascanu, Dan (Dan); General Area Review Team
> Cc: [email-masked]
> Subject: Re: Gen-ART review of 04 draft-ietf-appsawg-http-problem-01
> 
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.or
> > g_area_gen_trac_wiki_GenArtfaq&d=BQID-
> g&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4d
> >
> zGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=4RJRXp2cq8Xy_5qOfh6O
> emlR2tw
> > Pw7BGuM3S8hPxYf8&s=Y0uKQ8c94in5AWFrviUQeeRYogDlW-
> ZvW60mKhRuaVs&e=
> > ØIf such additional members are defined, their names SHOULD start with
> > a letter (ALPHA, as per [RFC5234]) and SHOULD consist of characters
> > from ALPHA, DIGIT, and "_" (so that it can be serialized in formats
> > other than JSON), and SHOULD be three characters or longer.
> >
> > What is the rationale here for the SHOULDs? What are the exception
> > cases that require using SHOULD rather than MUST in this paragraph?
> 
> at least part of the reason was that the XML serialization would not be able to
> deal with names starting with numbers (because of XML's naming rules), and
> that this should be taken into account when using additional members.
> 
> on the other hand, the JSON serialization is meant to be the normative one,
> which means that this XML constraint should not mean that any JSON using
> legal JSON names for new members should be considered invalid, even if the
> names do not conform to XML's naming rules.
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Dec 2015 15:02:14 +0200

Thanks for the review, Dan! Erik, is there anything in the clarification that would be beneficial for future readers? (Just asking, not suggesting.)

I have balloted no-obj.

Jari

On 01 Dec 2015, at 12:28, Romascanu, Dan (Dan) <[email-masked]> wrote:

> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Erik Wilde <[email-masked]>
Date: Thu, 17 Dec 2015 09:03:18 -0800

hello jari.

> Thanks for the review, Dan! Erik, is there anything in the clarification that would be beneficial for future readers? (Just asking, not suggesting.)

to me, this existing text is clear enough (and it seemed like dan was 
happy with my clarification):

"... (so that it can be serialized in formats other than JSON) ..."

but if anybody thinks that this needs more explaining, we could 
certainly do that. my suggestion is to keep it like it is, but if there 
is a -03, then we can tweak the language a little.

thanks and cheers,

dret.