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

Paul Hoffman <paul.hoffman@vpnc.org> Thu, 11 December 2014 18:29 UTC

Return-Path: <paul.hoffman@vpnc.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9B61A8775; Thu, 11 Dec 2014 10:29:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.647
X-Spam-Level:
X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4Mi58pibuLw; Thu, 11 Dec 2014 10:29:35 -0800 (PST)
Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F17C1A87EF; Thu, 11 Dec 2014 10:29:25 -0800 (PST)
Received: from [10.20.30.90] (142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBBITGOl096071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Dec 2014 11:29:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: proper.com: Host 142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119] claimed to be [10.20.30.90]
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Subject: Re: [Json] Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-10
From: Paul Hoffman <paul.hoffman@vpnc.org>
In-Reply-To: <CE03DB3D7B45C245BCA0D243277949362B18C7@MX104CL02.corp.emc.com>
Date: Thu, 11 Dec 2014 10:29:16 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <475F8F1D-6F6A-47E3-AE60-7BDC7AB6BD66@vpnc.org>
References: <CE03DB3D7B45C245BCA0D243277949362B18C7@MX104CL02.corp.emc.com>
To: "Black, David" <david.black@emc.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/oSE1Xh7PKnsOS9Tbj787NIEraes
Cc: "General Area Review Team (gen-art@ietf.org)" <gen-art@ietf.org>, "json@ietf.org" <json@ietf.org>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Dec 2014 18:29:44 -0000

<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@emc.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.

> 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,".

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.

> 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