Re: [Json] Inconsistency between RFC 8259 and RFC 5234

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 <tbray@textuality.com> wrote:
> 
> Ouch, I think he's right.
> ---------- Forwarded message ----------
> From: "Dale Schumacher" <dale.schumacher@gmail.com>
> Date: Dec 12, 2017 12:42 PM
> Subject: Inconsistency between RFC 8259 and RFC 5234
> To: "Tim Bray" <tbray@textuality.com>
> Cc: "Douglas Crockford" <douglas@crockford.com>
> 
> 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
> 
> _______________________________________________
> json mailing list
> json@ietf.org
> https://www.ietf.org/mailman/listinfo/json

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