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:paul.hoffman@xxxxxxxx] > Sent: Thursday, December 11, 2014 1:29 PM > To: Black, David > Cc: Nico Williams; General Area Review Team (gen-art@xxxxxxxx); ops- > dir@xxxxxxxx; ietf@xxxxxxxx; json@xxxxxxxx > 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 <david.black@xxxxxxx> 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