Subject: [Json] Fwd: Inconsistency between RFC 8259 and RFC 5234

From: Tim Bray <[email-masked]>
Date: Tue, 12 Dec 2017 23:55:54 +0000

Ouch, I think he's right.
---------- Forwarded message ----------
From: "Dale Schumacher" <[email-masked]>
Date: Dec 12, 2017 12:42 PM
Subject: Inconsistency between RFC 8259 and RFC 5234
To: "Tim Bray" <[email-masked]>
Cc: "Douglas Crockford" <[email-masked]>

I'm attempted to reach out to you directly, since https://www.rfc-editor.
org/info/rfc8259 (the recommended feedback channel) currently returns "RFC
8259 does not exist".

It appears that the JSON grammar makes use of two "Core" ABNF rules:

         DIGIT          =  %x30-39
                                ; 0-9

         HEXDIG         =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

However, JSON allows both upper and lower case in Unicode escapes within a
string. In which case, the grammar for such escapes:

      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

is incorrect.

If I may be permitted a recommendation, I would suggest that the JSON
grammar _not_ use the "Core" ABNF rules. Instead it could provide local
definitions such as:

      digit0-9 = %x30-39         ; 0-9

      hexdigit = digit0-9 / %x41-x46 / %x61-66

The use of "Core" ABNF rules doesn't seem to save much, in this case, and
the indirection makes it easy to overlook this inconsistency.

Thanks for your consideration,
Dale Schumacher

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Dec 2017 11:03:58 +1100

Nope, it's OK. 5234 section 2.3:

"""
   Literal text strings are interpreted as a concatenated set of
   printable characters.

   NOTE:

      ABNF strings are case insensitive and the character set for these
      strings is US-ASCII.

   Hence:

         rulename = "abc"

   and:

         rulename = "aBc"

   will match "abc", "Abc", "aBc", "abC", "ABc", "aBC", "AbC", and
   "ABC".

      To specify a rule that is case sensitive, specify the characters
      individually.

   For example:

         rulename    =  %d97 %d98 %d99

   or

         rulename    =  %d97.98.99

   will match only the string that comprises only the lowercase
   characters, abc.
"""

> On 13 Dec 2017, at 10:55 am, Tim Bray <[email-masked]> wrote:
> 
> I'm attempted to reach out to you directly, since https://www.rfc-editor.org/info/rfc8259 (the recommended feedback channel) currently returns "RFC 8259 does not exist".
> 
> However, JSON allows both upper and lower case in Unicode escapes within a string. In which case, the grammar for such escapes:
> 
>       char = unescaped /
>           escape (
> If I may be permitted a recommendation, I would suggest that the JSON grammar _not_ use the "Core" ABNF rules. Instead it could provide local definitions such as:
> 
>       digit0-9 = %x30-39         ; 0-9
> 
> The use of "Core" ABNF rules doesn't seem to save much, in this case, and the indirection makes it easy to overlook this inconsistency.
> 
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

--
Mark Nottingham   https://www.mnot.net/

---

From: Tim Bray <[email-masked]>
Date: Wed, 13 Dec 2017 00:22:07 +0000

/me sighs in relief.

On Dec 12, 2017 4:04 PM, "Mark Nottingham" <[email-masked]> wrote:

> > I'm attempted to reach out to you directly, since
> https://www.rfc-editor.org/info/rfc8259 (the recommended feedback
> channel) currently returns "RFC 8259 does not exist".
> >
> > However, JSON allows both upper and lower case in Unicode escapes within
> a string. In which case, the grammar for such escapes:
> >
> >       char = unescaped /
> >           escape (
> > The use of "Core" ABNF rules doesn't seem to save much, in this case,
> and the indirection makes it easy to overlook this inconsistency.
> >