Subject: Re: [Json] NUDGE: Re: Second WG Last Call for json-text-sequence

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Mon, 15 Sep 2014 17:49:44 +0000

On 9/10/2014, 7:09am Stefan Drees wrote:

> besides the elegance of correctly logging pi unadorned in 
> a single eternal line :-?. No from my side a single lined
> +1
> for avoiding bare top-level numbers as excuses for neither
> grammar nor procedural complications.

Works for me.  I suggest we move forward by re-simplifying the grammar, 
merely adding a note about the issue with detecting truncated numbers.  In 
addition, we may want to provide suggestions of alternate numeric 
encodings (such as "1", [1], or {"num":1}) that don't have this problem.

-- 
Joe Hildebrand

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Sep 2014 15:31:42 -0500

OK, if the chair is OK with it I'll make these changes and submit a new version.

Thanks,

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Sep 2014 13:51:54 -0700

> OK, if the chair is OK with it I'll make these changes and submit a new version.

Make it so.

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Sep 2014 09:02:25 +0200

>> OK, if the chair is OK with it I'll make these changes and submit a new version.

FWIW, I still believe that the mix of octet-level and character-level 
ABNF productions is something that ought to be addressed.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Sep 2014 09:31:45 -0500

On Tuesday, September 16, 2014, Julian Reschke <[email-masked]>
wrote:

> FWIW, I still believe that the mix of octet-level and character-level ABNF
> productions is something that ought to be addressed.
>
> Best regards, Julian
>

I thought. i did address it.  It's like an ASN.1 OCTET STRING containing
data in some other encoding.  Here the sequence provides only a sequence of
octets strings (not including RS, which doesn't need escaping because it
never appears in the encoded strings).  Then we say that those octet
strings should be parsed as JSON texts, leaving that entirely to RFC7159.

That's on the parser side.

On the encoder side we don't bother with octet strings at all, just
JSON-texts, LF, and RS.  (Here RS is a single octet owing to its being an
ASCII character.)

Thus there is never any mixing of octet-level and character-level
productions in any ABNF rules here.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Tue, 16 Sep 2014 19:03:33 +0200

On 2014-09-16 16:31, Nico Williams wrote:
> On Tuesday, September 16, 2014, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     FWIW, I still believe that the mix of octet-level and
>     character-level ABNF productions is something that ought to be
>     addressed.
>
>     Best regards, Julian
>
>
> data in some other encoding.  Here the sequence provides only a sequence
> of octets strings (not including RS, which doesn't need escaping because
> it never appears in the encoded strings).  Then we say that those octet
> JSON-texts, LF, and RS.  (Here RS is a single octet owing to its being
> an ASCII character.)
>
> ...

There is a mix, as long as the octet-based ABNF in your spec re-uses a 
production from the JSON-spec, which operates at the character level.

And yes, I understand the intent, but formally it's a problem. 
Rephrasing the reference to the RFC7159 production would be sufficient.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Sep 2014 13:42:42 -0500

> production from the JSON-spec, which operates at the character level.

Not on the parser side: it's one rule for the sequence, then you
separately apply the JSON ABNF to the elements of the sequence, and
each of those elements is an octet string at that point (which the
JSON ABNF then treats as strings of characters).

> And yes, I understand the intent, but formally it's a problem. Rephrasing
> the reference to the RFC7159 production would be sufficient.

It's no more a problem here than in Kerberos, in PKIX, or many other
protocols where we use OCTET STRINGs that carry other
BER-/DER-/whatever-encoded structures.

I'll phrase this as the sequence (on the parser side) being a sequence
of octet strings which are each further parsed as JSON texts.

Nico
--

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Tue, 16 Sep 2014 18:48:52 +0000

>Rephrasing the reference to the RFC7159 production would be sufficient.

I once again suggest something like:

JSON-sequence = *(1*RS possible-JSON)
     RS = %x1E; See RFC20

possible-JSON = 1*(not-RS); <attempt to parse this using RFC7159> 
not-RS = %x01-1d / %x1f-ff; <any byte except RS>

and making sure we specify that the encoding for the bytes in 
possible-JSON is *always* UTF8 unless it's malformed, which is a 
recoverable parsing error.

-- 
Joe Hildebrand

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Sep 2014 14:51:21 -0500

> recoverable parsing error.

That's the intent, yes, especially the part about the texts always being UTF-8.

Nico
--