JavaScript Object Notation (JSON) Text Sequences
draft-ietf-json-text-sequence-13

I see others have noticed the glaring typo (0x1E for LF) in the abstract...

I've asked that the media type registration request be posted to the media-types@iana.org list for comment.  That's been done, and there's been a little discussion that's resulted in some suggestions for a couple of minor changes, but nothing major.  I consider this point cleared, knowing that the minor changes are coming.

Thanks for addressing the OPS-DIR review in a timely manner.

Section 2.2.: "textm"

- abstract: 2nd 0x1E should be 0x0A I guess. That really
needs fixing so could well be a DISCUSS but is probably
so obvious it'll happen without that:-) But let me know
if you prefer this be a DISCUSS for tracking purposes.

- 2.1 doesn't say anything about 0x00 which often creates
security issues. Worth a note? Not sure myself. 

- 2.2: thanks for the  ctrl-^ info - that's good. Would it be
worth adding that in e.g. vim/vi you should precede that
ctrl-^ with ctrl-v so as to get the right value into your
file?

- 2.3: I think SHOULD NOT abort is too strong - did the wg
consider saying they SHOULD or MAY abort and giving the log
example as a counter example? It just seems safer to me if
the default behaviour is to abort. However, I'm not that
certain of this point, so this isn't a discuss.

- section 3: 2nd sentence, I think what you really should be
saying is that parsing one of these does not necessarily give
you a good input to a MAC or signature verification process
as you might or might not still have canonicalisation issues. 

- section 3: I think you ought mention the potential here for
careless code to be vulnerable to buffer overruns. We've seen
that too often to ignore it I'd argue.

- Most of the above plus a few others are also noted in
the secdir review [1]. I'm sure the author/shepherd/AD 
will engage with the reviewer there too. 

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg05300.html

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.