Subject: [Json] Consensus call: ABNF nits

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Jun 2013 09:40:17 -0700

There are two proposals for dealing with nits in the ABNF:
  0) Leave the ABNF in the current draft as-is
  1) Change the ABNF in the draft to use the values in "Proposal 1" below
Note that later proposals might make technical changes to the ABNF itself; those proposals are not what we are discussing in this consensus call.

Please respond to this message with a list of proposals you could accept, ordered from highest to lowest. Do not list proposals you cannot live with. If you cannot accept any of the proposals, please respond and say why.

Based on the responses we receive, we will try to judge the consensus of the WG.

-- The JSON WG co-chairs

Proposal #1
Note that this ABNF is sprinkled throughout Section 2 of draft-ietf-json-rfc4627bis-02. Each
section below replaces the similar section in the draft.
==============================================================

JSON-text = object / array

begin-array     = ws %x5B ws  ; [ left square bracket
begin-object    = ws %x7B ws  ; { left curly bracket
end-array       = ws %x5D ws  ; ] right square bracket
end-object      = ws %x7D ws  ; } right curly bracket
name-separator  = ws %x3A ws  ; : colon
value-separator = ws %x2C ws  ; , comma

ws = *(
     %x20 /              ; Space
     %x09 /              ; Horizontal tab
     %x0A /              ; Line feed or New line
     %x0D                ; Carriage return
     )

value = false / null / true / object / array / number / string
false = %x66.61.6c.73.65   ; false
null  = %x6e.75.6c.6c      ; null
true  = %x74.72.75.65      ; true

object = begin-object [ member *( value-separator member ) ]
         end-object
member = string name-separator value

array = begin-array [ value *( value-separator value ) ] end-array

number = [ minus ] int [ frac ] [ exp ]
decimal-point = %x2E       ; .
digit1-9 = %x31-39         ; 1-9
e = %x65 / %x45            ; e E
exp = e [ minus / plus ] 1*DIGIT
frac = decimal-point 1*DIGIT
int = zero / ( digit1-9 *DIGIT )
minus = %x2D               ; -
plus = %x2B                ; +
zero = %x30                ; 0
DIGIT = %x30-39            ; 0-9
      ; DIGIT equivalent to DIGIT rule in [RFC5234]

string = quotation-mark *char quotation-mark
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
escape = %x5C              ; \  U+005C
quotation-mark = %x22      ; "  U+0022
unescaped = %x20-21 / %x23-5B / %x5D-10FFFF  ; any Unicode scalar
   ; value, except those that must be escaped (C0 control
   ; characters, "QUOTATION MARK" [U+0022], and "REVERSE SOLIDUS"
   ; [U+005C])
HEXDIG = DIGIT / %x41-46 / %x61-66   ; 0-9, A-F, or a-f
       ; HEXDIG equivalent to HEXDIG rule in [RFC5234]

---

From: Tim Bray <[email-masked]>
Date: Fri, 21 Jun 2013 09:58:36 -0700

I’m OK with #1, the revision. It’s a considerable improvement, and thanks
to the people who did the unglamorous revision work.  -T

On Fri, Jun 21, 2013 at 9:40 AM, Paul Hoffman <[email-masked]> wrote:

> Note that later proposals might make technical changes to the ABNF itself;
> those proposals are not what we are discussing in this consensus call.
>
> Please respond to this message with a list of proposals you could accept,
> ordered from highest to lowest. Do not list proposals you cannot live with.
> If you cannot accept any of the proposals, please respond and say why.
>
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Jun 2013 20:27:17 +0200

1 is better.

(and the tools confirm that 0 and 1 are semantically exactly equivalent, ignoring comments.)

Grüße, Carsten

---

From: Norbert Lindenberg <[email-masked]>
Date: Fri, 21 Jun 2013 11:56:50 -0700

> Please respond to this message with a list of proposals you could accept, ordered from highest to lowest. Do not list proposals you cannot live with. If you cannot accept any of the proposals, plea…

Below are comments on three issues with proposal 1. The second issue, if not addressed, would make proposal 1 unacceptable to me. Otherwise I prefer proposal 1 over the old version.

>        %x75 4HEXDIG ) ) ; uXXXX                U+XXXX

As noted earlier, the last line isn't quite correct - \uXXXX can not only represent U+XXXX, but also be part of U+YYYYYY, where YYYYYY depends on a preceding or following \uXXXX sequence.

Proposal: Replace "U+XXXX" with "U+XXXX or part of U+YYYYYY".

>   ; characters, "QUOTATION MARK" [U+0022], and "REVERSE SOLIDUS"

Describing "unescaped" as "any Unicode scalar value, except..." is wrong. The correct term is "Unicode code point". Unicode scalar values do not include the range U+D800 through U+DFFFF.
http://www.unicode.org/glossary/#unicode_scalar_value

>       ; HEXDIG equivalent to HEXDIG rule in [RFC5234]

To complete the effort of disambiguating Unicode characters in the grammar, the comment should include "U+0030 through U+0039, U+0041 through U+0046, U+0061 through U+0066". We don't want them to be confused with ０-９, Ａ-Ｆ, or ａ-ｆ.

Norbert

---

From: Norbert Lindenberg <[email-masked]>
Date: Fri, 21 Jun 2013 18:09:32 -0700

On Jun 21, 2013, at 17:53 , John Cowan wrote:

> Norbert Lindenberg scripsit:
> 
>> To complete the effort of disambiguating Unicode characters in the
>> grammar, the comment should include "U+0030 through U+0039, U+0041
>> through U+0046, U+0061 through U+0066". We don't want them to be
>> confused with ０-９, Ａ-Ｆ, or ａ-ｆ.
> 
> I fail to see what U+0041 says that %x41 does not already say.

By that logic many of the ABNF comments are unnecessary.

Norbert

---

From: John Cowan <[email-masked]>
Date: Fri, 21 Jun 2013 20:53:30 -0400

-- 
With techies, I've generally found              John Cowan
If your arguments lose the first round          http://www.ccil.org/~cowan
    Make it rhyme, make it scan                 [email-masked]
    Then you generally can
Make the same stupid point seem profound!           --Jonathan Robie

---

From: John Cowan <[email-masked]>
Date: Fri, 21 Jun 2013 21:27:13 -0400

> By that logic many of the ABNF comments are unnecessary.

Quite so.  But the fact that we have some commentary that violates the DRY
rule is not an argument for adding yet more commentary that violates it.

-- 
Cash registers don't really add and subtract;           John Cowan
        they only grind their gears.                    [email-masked]
But then they don't really grind their gears, either;   
        they only obey the laws of physics.  --Unknown

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Sat, 22 Jun 2013 01:32:31 +0000

On 6/21/13 12:56 PM, "Norbert Lindenberg" <[email-masked]>
wrote:

>Describing "unescaped" as "any Unicode scalar value, except..." is wrong.
>The correct term is "Unicode code point". Unicode scalar values do not
>include the range U+D800 through U+DFFFF.

The posted ABNF for option 1 didn't get the last change that I proposed:

unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF

which would make the comment correct.  I like option 1 with that fix.

-- 
Joe Hildebrand

---

From: John Cowan <[email-masked]>
Date: Fri, 21 Jun 2013 21:39:09 -0400

> which would make the comment correct.  I like option 1 with that fix.

If I understand the consensus call correctly, we are not attempting to
change the ABNF itself at this stage.  But I agree with you.

-- 
John Cowan   [email-masked]  http://www.ccil.org/~cowan
Most languages are dramatically underdescribed, and at least one is
dramatically overdescribed.  Still other languages are simultaneously
overdescribed and underdescribed.  Welsh pertains to the third category.
        --Alan King

---

From: Norbert Lindenberg <[email-masked]>
Date: Fri, 21 Jun 2013 18:48:00 -0700

> unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF

That would be a significant normative change, which has been discussed before and will surely come up in other consensus calls. It doesn't fit under "nits".

Norbert

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Jun 2013 19:26:41 -0700

<chair hat on>

> unescaped = %x20-21 / %x23-5B / %x5D-D7FF / %xE000-10FFFF

The purpose of *this* consensus call is a clarification of the ABNF that would technically match the ABNF in the current draft. The change you propose will be in a different consensus call that is dealing with the subject of code points.

--Paul Hoffman

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 22 Jun 2013 05:25:10 +0200

On Jun 22, 2013, at 04:26, Paul Hoffman <[email-masked]> wrote:

> clarification of the ABNF

Yes.  But Norbert and Joe are right that the change to the comment in that clarification already anticipates the change to the ABNF itself in that separate consensus call.
So at this stage, it needs to say "Unicode code point", until we change both the production and the comment to "Unicode scalar value".

This is less a matter of consensus, than of correctness.

Grüße, Carsten

---

From: R S <[email-masked]>
Date: Fri, 21 Jun 2013 20:31:44 -0700

> This is less a matter of consensus, than of correctness.

Fully disagree. The existing specification is imperfect, but running code
seems to exist.

- Rob

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 22 Jun 2013 06:07:02 +0200

On Jun 22, 2013, at 05:31, R S <[email-masked]> wrote:

> Fully disagree. The existing specification is imperfect, but running code seems to exist.

You didn't understand.  The current text says

2 + 2 ; this is 5

You need to either 

1) change the 2 + 2 (which is the substantive change you seem to be opposed of; you are wrong here, but not incorrect).

2) or change the 5 to 4. (which would be wrong, but correct for now).

Since this consensus call is about non-substantive changes, the answer must be 2, and there is no sensible way to disagree with that.

Grüße, Carsten

---

From: R S <[email-masked]>
Date: Fri, 21 Jun 2013 22:22:09 -0700

On Fri, Jun 21, 2013 at 9:07 PM, Carsten Bormann <[email-masked]> wrote:

> You didn't understand.

Frankly, I think you don't understand.

The issue does not matter. Leave the current text. It's fine.

- Rob

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Sat, 22 Jun 2013 05:49:38 +0000

On 6/21/13 8:26 PM, "Paul Hoffman" <[email-masked]> wrote:

>The purpose of *this* consensus call is a clarification of the ABNF that
>would technically match the ABNF in the current draft. The change you
>propose will be in a different consensus call that is dealing with the
>subject of code points.

Then I suggest you remove the (new) comment from that line for this
consensus call.

-- 
Joe Hildebrand

---

From: Stefan Drees <[email-masked]>
Date: Sat, 22 Jun 2013 15:19:44 +0200

On 2013-06-21 18:40 +02:00, Paul Hoffman wrote:
> Note that later proposals might make technical changes to the ABNF
> itself; those proposals are not what we are discussing in this consensus
> call.
>
> Please respond to this message with a list of proposals you could
> accept, ordered from highest to lowest. Do not list proposals you cannot
> live with. If you cannot accept any of the proposals, please respond and
> say why. ...

[1]

But: Please do not forget to at least consider replacing ws by ows to 
somehow indicate the "nothing"ness it might represent and as already 
discussed on this list inside the ABNF nits thread(s). My motviation in 
this regard has already been explicated, so I do not have to repeat it 
here ;-)

Thanks.

{"Stefan":true}