Subject: [media-types] MIME type registration for "JSON text sequence" draft-ietf-json-text-sequence-11: (with DISCUSS)

From: Nico Williams <[email-masked]>
Date: Sat, 13 Dec 2014 21:29:37 -0600

The MIME media type for JSON text sequences is application/json-seq.

   Type name: application

   Subtype name: json-seq

   Required parameters: N/A

   Optional parameters: N/A

   Encoding considerations: binary

   Security considerations: See <this document, once published>,
   Section 3.

   Interoperability considerations: Described herein.

   Published specification: <this document, once published>.

   Applications that use this media type: <by publication time
   <https://stedolan.github.io/jq> is likely to support this format>.

   Fragment identifier considerations: N/A.

   Additional information:

   o  Deprecated alias names for this type: N/A.

   o  Magic number(s): N/A

   o  File extension(s): N/A.

   o  Macintosh file type code(s): N/A.

   o  Person & email address to contact for further information:

      *  [email-masked]

   o  Intended usage: COMMON

   o  Author: See the "Authors' Addresses" section of this document.

   o  Change controller: IETF

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 15 Dec 2014 14:30:34 +0100

>   Security considerations: See <this document, once published>,

Which says:

   All the security considerations of JSON [RFC7159] apply.  This format
   provides no cryptographic integrity protection of any kind.

   As usual, parsers must operate on as-good-as untrusted input.  This
   means that parsers must fail gracefully in the face of malicious
   inputs.  Note that incremental parsers can produce partial results
   and later indicate failure to parse the remainder of a text.  Note
   that texts that fail to parse and are ignored can be used to smuggle
   data past sequence parsers that don't warn about JSON text failures.

I think the second paragraph is very unclear and should be rewritten. It
seems for instance the first "must" is meant to say that it's a fact of
life rather than state a requirement. It should not say "must" in that
case, and I do not think this is a fact of life. I also do not think the
second sentence follows. The second sentence also seems to use "must" in
a confusing manner. Are parsers required to recover from syntax errors?
The text above can be interpreted like that, but it's not clear. In the
third sentence it is not clear whether parsers are required to report
errors.

Since there are actual conformance requirements related to this in other
sections of the document, it might be better to describe some of the
issues in terms of consequences of failing to implement relevant SHOULD-
level requirements.

>   <https://stedolan.github.io/jq> is likely to support this format>.

This field is for the general class of application using the type, like 
3D modeling applications or financial transaction systems. It could say
something like "information exchange systems" or explain that because
this is just multiple JSON documents in one document, applications are
similar in nature as those using ordinary JSON, possibly highlighting
that the features of the format make it more suitable for logging and
related functions. It should not list individual projects or products.

>   o  Deprecated alias names for this type: N/A.

As proposed, a non-empty `JSON-sequence` starts with at least one 0x1E
and the characters that can follow in proper documents come from a re-
stricted set. Considering that a leading 0x1E is quite unusual, it may
be reasonable to explain why this field is given as `N/A`.

(There is a typo "JSON textm" in the document.)
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 10:08:15 -0600

On Mon, Dec 15, 2014 at 02:30:34PM +0100, Bjoern Hoehrmann wrote:
> life rather than state a requirement. [...]

Correct, it's a fact of life, not a normative requirement.

>                                [...]. It should not say "must" in that
> case, and I do not think this is a fact of life. [...]

How is the need to operate on "as-good-as-untrusted input" not a fact of
life?

>                                           [...]. I also do not think the

They are required to not be exploitable through malformed input,
including syntactically valid as well as syntactically invalid inputs.

No actual requirement as to recovery is given, but it's recommended that
sequence parsers continue; see section 2.3.  The security considerations
should not be read in isolation.

> third sentence it is not clear whether parsers are required to report

This is covered elsewhere in the document.

> issues in terms of consequences of failing to implement relevant SHOULD-

I did not want to repeat normative language in the security
considerations.

> related functions. It should not list individual projects or products.

There are, in fact, protocols using JSON text sequences as specified in
earlier version of the I-D.  We could not reach consensus to adopt that
form.  The format in -11 hopefully will be adopted by those (and other)
protocols.

> be reasonable to explain why this field is given as `N/A`.

A one-byte magic number seems a bit too small to me to count as magic.

This format could be extended to XML.  An XML and a JSON text sequence
would then require further examination than just that one byte.  It
seems to me inadvisable to specify a magic number at this time.

If the list insists on it, I'll make this change.

> (There is a typo "JSON textm" in the document.)

Thanks.

Nico
--

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 15 Dec 2014 08:21:03 -0800

> Correct, it's a fact of life, not a normative requirement.

I agree with Nico, and disagree that it is "unclear". Saying "parsers MUST fail gracefully in the face of malicious inputs" is far less clear.

> How is the need to operate on "as-good-as-untrusted input" not a fact of

We can change "must" to "needs to", but this change only applies to people who think that 2119 language, even in lowercase, trumps the normal interpretation of English.

> should not be read in isolation.

+1 

> This is covered elsewhere in the document.

+1

> I did not want to repeat normative language in the security

+1

> form.  The format in -11 hopefully will be adopted by those (and other)

Björn is saying that the value for this entry should not be specific applications, but a general class. "Systems that might have long streams of JSON texts" would suffice.

> If the list insists on it, I'll make this change.

Please do *not*. 0x1E is not a sufficiently magic number to identify a blob as a JSON text sequence.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 10:59:09 -0600

On Mon, Dec 15, 2014 at 08:21:03AM -0800, Paul Hoffman wrote:
> We can change "must" to "needs to", but this change only applies to
> people who think that 2119 language, even in lowercase, trumps the
> normal interpretation of English.

RFC2119 says nothing about capitalization, but it's widely understood
that an RFC that refers to RFC2119 and uses normative language with
RFC2119 words capitalized and also "must" and so on in lower-case, means
to use the latter as not-RFC2119 words.

> >[...]
> Björn is saying that the value for this entry should not be specific
> applications, but a general class. "Systems that might have long
> streams of JSON texts" would suffice.

I see.  I can make this change.  Should I submit a -12?

> > [...]

OK, thanks, I won't.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Mon, 15 Dec 2014 14:20:05 -0600

On Mon, Dec 15, 2014 at 09:15:33PM +0100, Julian Reschke wrote:
> On 2014-12-15 17:59, Nico Williams wrote:
> No. That's not widely understood. It's a source of constant confusion.

In the context of this document it surely must be clear.  We could
always add text to that effect.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Mon, 15 Dec 2014 21:15:33 +0100

Reminder:

"In many standards track documents several words are used to signify the 
requirements in the specification.  These words are often capitalized. 
This document defines these words as they should be   interpreted in 
IETF documents.  Authors who follow these guidelines should incorporate 
this phrase near the beginning of their document:"

> ...

Best regards, Julian