Subject: [Json] AD Evaluation of draft-ietf-json-text-sequence-07

From: Pete Resnick <[email-masked]>
Date: Sun, 19 Oct 2014 12:35:29 -0500

I hope these comments are helpful:

2 - Editorial: An "ABNF rule" (as the term is used in 5234) is a single 
line. I think what you want is:

NEW
    Two different sets of ABNF rules are provided for the definition of
    JSON text sequences: one for parsers, and one for encoders.  Having
    two different sets of rules permits recovery by parsers from
    sequences where some the elements are truncated for whatever reason.
    The syntax for parsers is specified in terms of octet strings which
    are then interpreted as JSON-texts if possible.  The syntax for
    encoders, on the other hand, assumes that sequence elements are not
    truncated.

2.1/2.2 - Why use the reference to 646? I would have thought either 
referencing ASCII or even Unicode (which are more readily available than 
646) would be a much better choice; I've never seen a reference to 646 
before, and both ASCII and Unicode define RS. Unless there's a good 
reason, I'd prefer to switch it.

2.1 - The last paragraph has me a bit baffled. Starting with the first bit:

    If parsing of such an octet string as a JSON-text fails, the parser
    should nonetheless continue parsing the remainder of the sequence;

Just a nit here: it seems to me "can" is better than "should" here.

    the parser SHOULD report such failures so that applications may
    terminate processing if desired.

That's not an appropriate use of SHOULD. Reporting errors up the 
application stack isn't part of interoperability. Instead, how about: 
"however, applications might wish to terminate processing in this case, 
so it is useful for parsers to report JSON-text parsing failures to the 
application."

    Multiple consecutive RS octets do
    not denote empty sequence elements between them.  Parsers MAY report
    about empty sequence elements.

I cannot parse that above (pun intended). First of all, aside from the 
inappropriate use of MAY, the second sentence makes no sense in light of 
the first: If multiple RSs don't denote empty sequence elements, how can 
the parser report about empty sequence elements? But I'm not even 
getting what the first sentence really means. Did you mean, "Multiple 
consecutive RS octets can be ignored" or "Multiple consecutive RS octets 
are semantically equivalent to a single RS octets"? Please explain.

2.2 - The syntax says:

      JSON-sequence = *(RS JSON-text LF)

but the prose says:

    In prose: any number of JSON texts, each preceded and followed by one
    or more ASCII RS characters and each followed by a line feed (LF).

One of those is incorrect. The syntax only allows for a single RS 
preceding the JSON text.

2.3/2.4 - Reversing the order of these sections would be helpful. 2.3 
occurs because of truncation, which is described in 2.4.

2.3 - "("ws" ABNF rule from [RFC7159])" has the potential for confusion, 
since "ws" from 7159 is optional. I would simply say, "(SP, HTAB, LF, or 
CR)". They're all defined in 5234, which you already have a normative 
reference to.

"(see previous sentence)" seems completely unnecessary. I suggest 
striking it.

s/MAY/can in the last sentence. See comment on 2.1.

2.4 - Strike the word "be" from the title of the section. In the first 
sentence, s/SHOULD NOT/need not.

2.5 - Change "MAY" in the second sentence to "can" or "can attempt to".

3 - I think you should strike the second paragraph in its entirety. This 
is not a security consideration for the data format defined here. It's a 
security consideration for any transport that might move these things 
(or any other data format, for that matter) around, not for the data 
format itself. Now, if you put this in here simply because you thought 
it would satisfy some Security AD, please do take it out and I'll deal 
with the IESG. If you really think it belongs in there, do explain; 
perhaps I'm missing something (or perhaps I'll be in the rough).

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: John Cowan <[email-masked]>
Date: Mon, 20 Oct 2014 09:51:05 -0400

Pete Resnick scripsit:

> referencing ASCII or even Unicode (which are more readily available
> than 646) would be a much better choice; I've never seen a reference
> to 646 before, and both ASCII and Unicode define RS. Unless there's
> a good reason, I'd prefer to switch it.

Unicode does not define RS, or any C0 control characters except TAB, CR, and
LF.  ISO 646 is ASCII.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
Babies are born as a result of the mating between men and women,
and most men and women enjoy mating.
    --Isaac Asimov in Earth: Our Crowded Spaceship

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2014 16:01:55 +0200

> Unicode does not define RS, or any C0 control characters except TAB, CR, and

But then why does <http://www.unicode.org/charts/PDF/U0000.pdf> list them?

Best regards, Julian

---

From: John Cowan <[email-masked]>
Date: Mon, 20 Oct 2014 10:23:54 -0400

> But then why does <http://www.unicode.org/charts/PDF/U0000.pdf> list them?

Code charts are informative, not normative.  See the Unicode FAQ page at
<http://www.unicode.org/faq/casemap_charprop.html>, which has this
question:

Q: The character name alias for the control character U+0082 is BREAK
PERMITTED HERE. Does that mean I have to interpret that control character
in that way?

A: The Unicode Standard does not define U+0082 to mean "BREAK PERMITTED
HERE". Formally this character is simply one of 65 control codes,
one which in ISO 6429 has the name and meaning of "BREAK PERMITTED
HERE". Implementers of the Unicode Standard are not required to interpret
the character U+0082 in accordance with ISO 6429 (or to interpret it
at all).

The standard does assign particular properties and semantics for certain
controls commonly used in text files including tab, carriage return,
line feed, form feed, and next line. However, it does not give the
majority of control codes any semantics at all; that is left to a
higher-level protocol.

The character names for control characters are actually undefined,
however, name aliases, such as "BREAK PERMITTED HERE" have been
defined. These aliases are based on ISO 6429, and can be used to identify
specific controls, for example in regular expressions. For other control
characters see http://www.unicode.org/charts/PDF/U0080.pdf.

[End of FAQ]

So we could formally cite ISO 6429 or its equivalent ECMA-48 (online at
<http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf>)
rather than ISO 646, I suppose.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
But the next day there came no dawn, and the Grey Company passed on
into the darkness of the Storm of Mordor and were lost to mortal sight;
but the Dead followed them.          --"The Passing of the Grey Company"

---

From: Julian Reschke <[email-masked]>
Date: Mon, 20 Oct 2014 16:52:03 +0200

On 2014-10-20 16:23, John Cowan wrote:
> ...

OK, thanks for the explanation.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Oct 2014 11:31:15 -0500

On Sun, Oct 19, 2014 at 12:35:29PM -0500, Pete Resnick wrote:
> 2 - Editorial: An "ABNF rule" (as the term is used in 5234) is a
> single line. I think what you want is:
> 
> NEW

OK.

> a good reason, I'd prefer to switch it.

Only because I didn't know how to reference RFC 20.  I hadn't noticed
(or rather, I'd forgotten) that it's 0020 as far as bibxml is concerned.

Perhaps I should have submitted a -08 with this (and some other
editorial nits I'd accepted).

> Just a nit here: it seems to me "can" is better than "should" here.

Sure.

> application stack isn't part of interoperability. Instead, how
> about: "however, applications might wish to terminate processing in
> this case, so it is useful for parsers to report JSON-text parsing
> failures to the application."

There's a lot of places where we use RFC2119 language where it has no
interoperability effect (e.g., security).  Are you sure you want this to
not be a recommendation?

> I cannot parse that above (pun intended). First of all, aside from
> the inappropriate use of MAY, the second sentence makes no sense in
> light of the first: If multiple RSs don't denote empty sequence
> elements, how can the parser report about empty sequence elements?

They might still imply truncated elements in some circumstances.

> But I'm not even getting what the first sentence really means. Did
> you mean, "Multiple consecutive RS octets can be ignored" or
> "Multiple consecutive RS octets are semantically equivalent to a
> single RS octets"? Please explain.

Sequence elements are separated by RS bytes.  Does this mean that two
consecutive RS bytes denote an empty/missing/truncated element?  The
desired answer is "no".  I don't think "multiple conseuctive RS octets
are semantically equivalent to a single RS octet" is what we want: the
RS octets as such have no "semantics" as such -- they are a detail of
the encoding.

> One of those is incorrect. The syntax only allows for a single RS

Agreed.  That's one of the nits mentioned above that is to be corrected.
It was an editing error.

> 2.3/2.4 - Reversing the order of these sections would be helpful.
> 2.3 occurs because of truncation, which is described in 2.4.

Agreed.

> 2.3 - "("ws" ABNF rule from [RFC7159])" has the potential for
> confusion, since "ws" from 7159 is optional. I would simply say,
> "(SP, HTAB, LF, or CR)". They're all defined in 5234, which you
> already have a normative reference to.

I don't follow.  For the purpose of this section all that matters is
that the reader understand what is meant by 'ws', which surely the
refernce to RFC7159 is sufficient to ensure.

> "(see previous sentence)" seems completely unnecessary. I suggest

Yeah, it does.

> s/MAY/can in the last sentence. See comment on 2.1.

See above.

> 2.4 - Strike the word "be" from the title of the section. In the
> first sentence, s/SHOULD NOT/need not.

Thanks.

> 2.5 - Change "MAY" in the second sentence to "can" or "can attempt to".

A number of people preferred removing this section.  I think that's a
better approach now.

> 3 - I think you should strike the second paragraph in its entirety.

I'd like to, yes.

> This is not a security consideration for the data format defined
> here. It's a security consideration for any transport that might
> move these things (or any other data format, for that matter)
> around, not for the data format itself. Now, if you put this in here
> simply because you thought it would satisfy some Security AD, please
> do take it out and I'll deal with the IESG. If you really think it
> belongs in there, do explain; perhaps I'm missing something (or
> perhaps I'll be in the rough).

Nah, let's remove it.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 21 Oct 2014 17:30:23 -0700

<shepherd hat on>

Nico: this mostly seems uncontroversial; see below. Go ahead and issue a new draft, and Pete can decide to poke the correct buttons or ask for another round. Turning in your draft sooner rather than later will help avoid the draft deadline crush next Monday.

> interoperability effect (e.g., security).  Are you sure you want this to

This can go either way. RFC 2119 is only for interop and security, and this is an example of neither *except* if you want to make the case that there is a security issue if they don't report failures. That is, I can see Pete's point of view in general, and I can see your point of view in specific here. In this case, I think I would lean towards Pete's view, but not strongly.

> RS octets as such have no "semantics" as such -- they are a detail of

Then I propose we stay away from the nebulous "truncated elements in some circumstances" and say "Multiple consecutive RS octets do not denote empty sequence elements between them, and can be ignored." Remove the second sentence, since it does not help anyone.

> refernce to RFC7159 is sufficient to ensure.

I agree with Nico here. "ws" in 7159 is optional, but understanding it when reading 7159 is not.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Tue, 21 Oct 2014 19:48:39 -0500

On Tue, Oct 21, 2014 at 05:30:23PM -0700, Paul Hoffman wrote:
> Nico: this mostly seems uncontroversial; see below. Go ahead and issue
> a new draft, and Pete can decide to poke the correct buttons or ask
> for another round. Turning in your draft sooner rather than later will
> help avoid the draft deadline crush next Monday.

OK.  I'm traveling, but I can submit one tomorrow.

> This can go either way. RFC 2119 is only for interop and security, and
> this is an example of neither *except* if you want to make the case
> that there is a security issue if they don't report failures. That is,
> I can see Pete's point of view in general, and I can see your point of
> view in specific here. In this case, I think I would lean towards
> Pete's view, but not strongly.

We also do some APIs...  This effectively is a recommendation for an
API.  I don't feel too strongly about it, but I do think that if you
have an API you're feeding octets to, and you're not doing any
interpretation of them, and if you did care to know about truncated
records, then you'd want the API to tell you.  One could always choose
an API that does do that over one that doesn't, so there's not much harm
in removing the recommendation.

> [...]
> Then I propose we stay away from the nebulous "truncated elements in
> some circumstances" and say "Multiple consecutive RS octets do not
> denote empty sequence elements between them, and can be ignored."
> Remove the second sentence, since it does not help anyone.

OK.

(This MAY effectively modifies the SHOULD discussed further up.
Removing it might increase one's desire to also remove the SHOULD above.
I'd rather keep the SHOULD but I don't care enough to argue any further
:)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Oct 2014 12:44:22 -0500

>> Just a nit here: it seems to me "can" is better than "should" here.

Er, in -07 section 2.4 says "parsers SHOULD NOT abort when..." so I
think this should be a SHOULD, not "can".  (Clearly this is the
desired behavior.)

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 23 Oct 2014 13:07:27 -0500

https://tools.ietf.org/html/draft-ietf-json-text-sequence-08

https://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-json-text-sequence-08.txt

https://tools.ietf.org/rfcdiff?url2=draft-ietf-json-text-sequence-08.txt

There's a bit of noise there due to s/JSON-text/JSON text/g and minor
edits I'd agreed to in the last WGLC.

Changes:

 - s/JSON-text/JSON text/g (except in the ABNF)
 - downgraded[*] RFC2119 language about reporting malformed texts
 - removed the second paragraph of section 3
 - removed section 2.5
 - swapped sections 2.3 and 2.4
 - adopted new text proposed by Pete R.
 - section 2.4 (top-level numeric values) got a bit of a re-write
proposed (and accepted) on the list during WGLC, but it keeps the same
meaning
 - removed informative references
 - replaced the ISO 646 reference with RFC20
 - fixed nits
 - added a sentence to the abstrace that was proposed and accepted during WGLC
 - added a note about how to input RS in some systems

[*] Oops, I left a "MAY" in the new section 2.4 that should be "can".
Let me know if that merits a -09 or a note to the RFC-Editor.

Nico
--

---

From: "Manger, James" <[email-masked]>
Date: Fri, 24 Oct 2014 13:51:12 +1100

The abstract says a sequence consists of "any number of JSON tests".
I suspect this tests/texts typo in the abstract warrants another version.

2.2 says "preceded and *followed* by one ASCII RS character", but the JSON-sequence ABNF has no RS following. Drop the "and followed" phrase.

I would put encoding before parsing (move section 2.2 before 2.1). Encoding explains the format more cleanly, without the added complexity of error recovery in the parsing side.

The encoding ABNF is presumably in terms of Unicode code points (%x0 to %x10FFFF), given that is what JSON-text from RFC7159 uses. This should be explicitly stated.

Since encoding is in terms of Unicode, drop "ASCII" from the phrase: "preceded .. by one ASCII RS character".

To the note in section 2.2:
   Note that on some systems it's possible to input RS by typing
   'ctrl-^'.  This is helpful when constructing a sequence manually with
   a text editor.
Add the following ;-):
   But on most systems it is very awkward to input RS so manipulating
   a sequence manually will be frustrating and error-prone.

--
James Manger

---

From: Nico Williams <[email-masked]>
Date: Sun, 26 Oct 2014 23:54:12 -0500

> I suspect this tests/texts typo in the abstract warrants another version.

Meh :)  It's a typo, but sure.

> 2.2 says "preceded and *followed* by one ASCII RS character", but the
> JSON-sequence ABNF has no RS following. Drop the "and followed"
> phrase.

Editing error.  Will fix.

> I would put encoding before parsing (move section 2.2 before 2.1).
> Encoding explains the format more cleanly, without the added
> complexity of error recovery in the parsing side.

I'll let Pete ask for this.

> The encoding ABNF is presumably in terms of Unicode code points (%x0
> to %x10FFFF), given that is what JSON-text from RFC7159 uses. This
> should be explicitly stated.

ABNF deals in bytes, and RFC7159 doesn't say otherwise.  Including the
RFC7159 ABNF by reference is sufficient.

However, there was a comment that I dropped about this format being just
UTF-8 specific -- it has to be, since for the log-type applications
there is a hard requirement for a one-byte record separator.

> "preceded .. by one ASCII RS character".

No need.  We're referencing RFC 20 for RS.

>    a sequence manually will be frustrating and error-prone.

Heh :)  I'll leave it as is though.

Nico
--