Re: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS

Carsten Bormann <cabo@tzi.org> Wed, 12 June 2013 06:19 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: json@ietfa.amsl.com
Delivered-To: json@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CBA21F9AE8 for <json@ietfa.amsl.com>; Tue, 11 Jun 2013 23:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.864
X-Spam-Level:
X-Spam-Status: No, score=-105.864 tagged_above=-999 required=5 tests=[AWL=-0.215, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eignpN-NTuls for <json@ietfa.amsl.com>; Tue, 11 Jun 2013 23:19:28 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 37A1421F8D6D for <json@ietf.org>; Tue, 11 Jun 2013 23:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.4/8.14.4) with ESMTP id r5C6JLSP020544; Wed, 12 Jun 2013 08:19:21 +0200 (CEST)
Received: from [192.168.217.105] (p54893401.dip0.t-ipconnect.de [84.137.52.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 54DCA3760; Wed, 12 Jun 2013 08:19:21 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
Content-Type: text/plain; charset=iso-8859-1
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org>
Date: Wed, 12 Jun 2013 08:19:20 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <BC94A823-6314-4616-A6A7-6EEC8373FEE0@tzi.org>
References: <6898D31C-FF53-4B8D-9F81-5519C934E00D@vpnc.org>
To: Paul Hoffman <paul.hoffman@vpnc.org>
X-Mailer: Apple Mail (2.1508)
Cc: "json@ietf.org" <json@ietf.org>
Subject: Re: [Json] ABNF nits -- LAST CHANCE ON PROPOSALS
X-BeenThere: json@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <json.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/json>, <mailto:json-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/json>
List-Post: <mailto:json@ietf.org>
List-Help: <mailto:json-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/json>, <mailto:json-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 12 Jun 2013 06:19:34 -0000

The efforts to real-world-test the ABNF are ongoing; so far everything looks fine (unsurprisingly).

From a stylistic point of view, I have two comments on the ABNF:


1) the production for char relies on the operator precedence, i.e., concatenation binds closer than alternative.

      char = unescaped /
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              %x75 4HEXDIG )  ; uXXXX                U+XXXX

This is nicely layed out to suggest this priority, and given the precedence defined in 5234, it *is* unambiguous.

Still, section 3.10 of 5234 rightly notes:

   Use of the alternative operator, freely mixed with concatenations,
   can be confusing.

      Again, it is recommended that the grouping operator be used to
      make explicit concatenation groups.

So the canonical form of writing this might be:

      char = unescaped / (
          escape (
              %x22 /          ; "    quotation mark  U+0022
              %x5C /          ; \    reverse solidus U+005C
              %x2F /          ; /    solidus         U+002F
              %x62 /          ; b    backspace       U+0008
              %x66 /          ; f    form feed       U+000C
              %x6E /          ; n    line feed       U+000A
              %x72 /          ; r    carriage return U+000D
              %x74 /          ; t    tab             U+0009
              (%x75 4HEXDIG) ) )  ; uXXXX                U+XXXX



2) the character literals use hex in favor of "x" notation.

begin-array = ws "[" ws
begin-object = ws "{" ws
end-array = ws "]" ws
end-object = ws "}" ws
name-separator = ws ":" ws
value-separator = ws "," ws

would generally be considered slightly more readable.
Productions like minus, zero, plus, would not really be needed.
(Hex notation is indeed needed for quotation-mark, for case-sensitive productions like false, and for the ranges, so using just that instead of a mix with quoted "char-val"s is a simplification for people new to ABNF.)



Now, changing the ABNF even on a stylistic level could make it look like something changed syntactically between 4627 and 4627bis.
On the other hand, I'm not aware of any problems that have been caused by the two stylistic peculiarities.

So I'm not actually proposing to make any of these changes now, but I would like to make sure the WG considered and consciously decided against them because they will inevitably come up at IESG review time.

(If we do decide to change the ABNF for other reasons, these items might be reconsidered.)

Grüße, Carsten