Subject: [Json] Ted Lemon's No Objection on draft-ietf-json-text-sequence-11: (with COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Tue, 16 Dec 2014 06:20:46 -0800

Ted Lemon has entered the following ballot position for
draft-ietf-json-text-sequence-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-json-text-sequence/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I'm not going to raise this as a DISCUSS because I'm on vacation and
can't respond, but I am a bit concerned by the following text in the
document:

   Multiple consecutive RS octets do not denote empty sequence elements
   between them, and can be ignored.

The concern I have is that this document appears to suggest that a large
dataset can be transferred as a series of json text sequences.   But
nowhere in the document (that I noticed) is it explained how each chunk
of text is identified.   It could be that they do not need to be
identified: that each chunk stands alone.   But suppose you are
transferring array elements, rather than database tuples.   In order to
avoid a mis-count, it would have to be the case that each tuple contains
the index of the array element that it represents.

I suspect that the intention is actually that these sequences never be
used this way, but it would be nice to state that explicitly, e.g.
something like this:

   This document does not define a mechanism for reliably identifying
   text sequence by position (for example, when sending individual
   elements of an array as unique text sequences.   Each json text
   sequence should therefore contain sufficient information that
   it is meaningful regardless of the order in which it appears
   in a stream of text sequences.

---

From: John Cowan <[email-masked]>
Date: Tue, 16 Dec 2014 19:10:04 -0500

>    in a stream of text sequences.

The second sentence does not follow from the first.  It is perfectly
possible to have an ordered list without the ability to reference a
particular member of the list by an index number.  A physical example
would be a large book without printed page numbers.  It is clear which
page follows which, even though it is hard to figure out which page is
the 500th.

I recommend therefore dropping the second sentence.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
O beautiful for patriot's dream that sees beyond the years
Thine alabaster cities gleam undimmed by human tears!
America! America!  God mend thine every flaw,
Confirm thy soul in self-control, thy liberty in law!
        --one of the verses not usually taught in U.S. schools

---

From: Nico Williams <[email-masked]>
Date: Tue, 16 Dec 2014 18:28:47 -0600

The intention is that they not be emitted, but that they [optionally] be
tolerated at parse time.

>    elements of an array as unique text sequences.   [...]

Well, yes, nor does it support random access.  I would have thought this
too obvious to mention.  I probably did :)

>                                            [...].   Each json text

Whether or not the sequence elements should contain such information
really depends on the application.  I wouldn't want to say "should", not
even distinguished from RFC2119 SHOULD.  I'd be fine with this reworded
to say that "applications may want to ...".

Alternatively applications using this format should (perhaps even
SHOULD, though this would really be a recommendation for application
*designers*, not implementors) indicate whether truncated (which would
include 'missing') texts should yield a fatal sequence parse error.

Nico
--

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Dec 2014 21:52:55 -0500

> page follows which, even though it is hard to figure out which page is

Sure, but if a page is missing that's kind of a problem.   In the case of a log entry, the entry does contain all the information that the user needs.   It doesn't need an index, because log entries are ordered but not indexed.   Presumably the log entry has a timestamp, which is sufficient to determine its ordering.   I think you can make the case that the text I suggested doesn't make this clear, so it might be good to adjust it to make it clearer, but I am not quite on board with just deleting the text entirely (although since it's a comment you are free to do anything or nothing in response to the comment).

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 12:25:15 -0600

On Tue, Dec 16, 2014 at 09:52:55PM -0500, Ted Lemon wrote:
> Sure, but if a page is missing that's kind of a problem.   In the case
> of a log entry, the entry does contain all the information that the
> user needs.   It doesn't need an index, because log entries are
> ordered but not indexed.   Presumably the log entry has a timestamp,
> which is sufficient to determine its ordering.   I think you can make
> the case that the text I suggested doesn't make this clear, so it
> might be good to adjust it to make it clearer, but I am not quite on
> board with just deleting the text entirely (although since it's a
> comment you are free to do anything or nothing in response to the
> comment).

For a database application returning an indefinite number of rows, each
as a JSON text in a JSON text sequence, there should be no concern about
truncation of middle elements...

... unless the sequence encoder is not encoding (or validating) the
sequence elements.  In which case the sequence encoder should terminate
the sequence at the first invalid text and signal an error.

Truncation should only come up in logging applications.

Nico
--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Dec 2014 13:34:05 -0500

> Truncation should only come up in logging applications.

If you want me to say I'm happy, you have to talk about this in the document.   If you don't care about me saying I'm happy, then there's no need to explain things like this to me--I do understand the permutations that might occur here.   You don't have a required action item here based on my comment unless your AD decides that you do.  :)

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 12:58:41 -0600

On Wed, Dec 17, 2014 at 01:34:05PM -0500, Ted Lemon wrote:
> If you want me to say I'm happy, you have to talk about this in the
> document.   If you don't care about me saying I'm happy, then there's
> no need to explain things like this to me--I do understand the
> permutations that might occur here.   You don't have a required action
> item here based on my comment unless your AD decides that you do.  :)

I want you to be happy.  I'll propose some text this afternoon.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Dec 2014 14:08:25 -0500

> I want you to be happy.  I'll propose some text this afternoon.

Thanks!

---

From: Nico Williams <[email-masked]>
Date: Wed, 17 Dec 2014 17:25:20 -0600

On Tue, Dec 16, 2014 at 06:20:46AM -0800, Ted Lemon wrote:
> [...]

How about (at the end of section 2.3):

   This document does not define a mechanism for reliably identifying
   text sequence by position (for example, when sending individual
   elements of an array as unique text sequences).  For applications
   where truncation is a possibility, this means that intended sequence
   elements can be truncated, and can even be missing entirely,
   therefore a reference to an nth element would be unreliable.

?

Nico
--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 17 Dec 2014 21:49:44 -0500

>   therefore a reference to an nth element would be unreliable.

That'll do it.   Thanks!