RE: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10

["Black, David" <[e-mail]>]

All of this is fine, with the correction below (looks like a copy/paste
problem), and a -11 would be a fine thing to put out w/these changes.

Thanks,
--David

> -----Original Message-----
> From: Paul Hoffman [mailto:[e-mail]]
> Sent: Thursday, December 11, 2014 1:29 PM
> To: Black, David
> Cc: Nico Williams; General Area Review Team ([e-mail]); ops-
> [e-mail]; [e-mail]; [e-mail]
> Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-
> sequence-10
> 
> <shepherd hat on>
> 
> Thanks for the followup comments on -10. In general, I think they are fine,
> and Nico could put out a -11 before IESG telechat review. See below.
> 
> On Dec 10, 2014, at 7:51 AM, Black, David <[e-mail]> wrote:
> > The -10 version of this draft resolves items [A]-[E] from the
> > Gen-ART and OPS-Dir review of -09, and the IESG is in the process of
> > resolving the (silly) idnits complaint about RFC 20 being a possible
> > downref.
> >
> > For item [D], a different approach was taken instead of modifying
> > the ABNF - the resulting new Section 2.4 is a definite improvement
> > to the draft, and is significantly clearer than the modified ABNF
> > would have been.  Nicely done.
> >
> > Item [F] about the <angle-bracketed> text in the IANA Considerations
> > (Section 4) remains open - if the intent is to not deal with replacing
> > that text until after IESG approval, an RFC Editor Note to that effect
> > should be added to Section 4.
> 
> David: I disagree with the need for this change. The RFC Editor can interpret
> the current wording just fine.

Ok.

> > I have an additional editorial concern - given all the discussion about
> > UTF-8, it would be good for the draft to make it clear early on
> > that JSON text sequences are UTF-8 only.  Here are some suggested changes.
> >
> > Abstract:
> >
> >   This document describes the JSON text sequence format and associated
> >   media type, "application/json-seq".  A JSON text sequence consists of
> >   any number of JSON texts, each prefix by an Record Separator
> >   (U+001E), and each ending with a newline character (U+000A).
> >
> > "any number of JSON texts" -> "any number of UTF-8 encoded JSON texts"
> 
> This change concerns me, because it sounds like a JSON text sequence could
> consist of JSON texts encoded in UTF-8 and other encodings. I would instead
> prefer "any number of JSON texts, all encoded in UTF-8,".

Ok.

> I also just now noticed that there is a typo in the abstract: it should say
> "each prefix*ed*".
> 
> > It also looks like ASCII names for RS and LF are being mixed w/Unicode
> > codepoints in the second sentence in the abstract.  I'm not sure that's
> > a good thing to do, especially as the body of the draft refers to RS and
> > LF as being ASCII.  Here are a couple of changes that would remedy this:
> >
> >   "an Record Separator (U+001E)" -> "an ASCII Record Separator (0x1E)"
> >   "a newline character (U+000A)" -> "an ASCII newline character (0x0A)"
> 
> With John Cowan's change ("an ASCII Line Feed character (0x1E)" instead of "an
> ASCII Record Separator (0x1E)"), that would indeed be clearer.

I'm sure Paul meant to write: ("an ASCII Line Feed character (0x0A)"
instead of "an ASCII newline character (0x0A)").

> 
> > Section 2 JSON Text Sequence Format:
> >
> > I suggest adding this sentence as a separate paragraph at the end of this
> > section (i.e., just before Section 2.1):
> >
> >   JSON text sequences MUST use UTF-8 encoding; other encodings of JSON
> >   (i.e., UTF-16 and UTF-32) MUST NOT be used.
> >
> 
> That seems like a good clarifying addition as well.
> 
> Nico: could you issue a -11 with the above changes?
> 
> --Paul Hoffman