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(_dot_)hoffman(_at_)vpnc(_dot_)org]
Sent: Thursday, December 11, 2014 1:29 PM
To: Black, David
Cc: Nico Williams; General Area Review Team (gen-art(_at_)ietf(_dot_)org);
ops-
dir(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org; json(_at_)ietf(_dot_)org
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(_dot_)black(_at_)emc(_dot_)com> 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