Subject: [ietf-types] Registration of media type application/senml+json

From: Cullen Jennings <[email-masked]>
Date: Tue, 21 Sep 2010 13:12:21 -0600

I'm considering the following media type registration in draft-jennings-senml-03 and would appreciate any feedback. Thanks, Cullen 

  Type name:  application

   Subtype name:  senml+json

   Required parameters:  none

   Optional parameters:  none

   Encoding considerations:  Must be encoded as binary.  See additional
   constraints in [RFC4627].

   Security considerations:  Sensor data can contain a wide range of
   information ranging from information that is very public, such the
   outside temperature in a given city, to very private information that
   requires integrity and confidentiality protection, such as patient
   health information.  This format does not provide any security and
   instead relies on the transport protocol that carries it to provide
   security.  Given applications need to look at the overall context of
   how this media type will be used to decide if the security is
   adequate.

   Interoperability considerations:  JSON allows new fields to be
   defined and applications should be able to ignore fields they do not
   understand to ensure forward compatibility with extensions to this
   specification.

   Published specification:  RFC-AAAA

   Applications that use this media type:  N/A

   Additional information:

   Magic number(s):  none

   File extension(s):  senml

   Macintosh file type code(s):  none

   Person & email address to contact for further information:  Cullen
   Jennings <[email-masked]>

   Intended usage:  COMMON

   Restrictions on usage:  None

   Author:  Cullen Jennings <[email-masked]>

   Change controller:  Cullen Jennings <[email-masked]>

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Tue, 21 Sep 2010 23:52:28 +0200

>   constraints in [RFC4627].

If I understand correctly, this type is just a specialization of the
application/json type. If so this should simply say the considerations
are the same as for application/json.

>   understand to ensure forward compatibility with extensions to this

I think "JSON allows new fields to be defined" is misleading here.
Perhaps you mean to say: if the name of a name-value pair in an
object is not recognized, the pair should be ignored?

>   Applications that use this media type:  N/A

This should be a general description of the type of application
that uses the type, for instance, Office applications, Multimedia
applications, Cartography applications, Web browsers, ...

>   Change controller:  Cullen Jennings <[email-masked]>

As this is a registration in the standards tree through IETF consensus,
this should say The IETF or The IESG; I forgot which is more popular.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Sep 2010 16:00:44 -0600

>    Subtype name:  senml+json

I thought that the "+xml" convention was for the special class of media
types that represent XML MIME entities (RFC 3023). Is there a similar
class of "JSON MIME entities" that would justify "+json"? I don't see a
definition for such a class in RFC 4627 (not that I think it's a bad idea).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 22 Sep 2010 00:09:20 +0200

>definition for such a class in RFC 4627 (not that I think it's a bad idea).

There are by now a number of "+type" media types (the registry has +der,
+wbxml, +fastinfoset) and I've seen "+json" a number of times in the
wild, http://www.w3.org/TR/rdf-sparql-json-res/ for instance uses it.
http://www.alvestrand.no/pipermail/ietf-types/2006-June/001755.html has
http://www.alvestrand.no/pipermail/ietf-types/2006-June/001756.html as
only comment that I could find.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ned Freed <[email-masked]>
Date: Tue, 21 Sep 2010 18:15:43 -0700 (PDT)

> definition for such a class in RFC 4627 (not that I think it's a bad idea).

The situation surrounding the use of +suffix constructs is a little unclear.
RFC 3023 set up the rules for +xml fairly well (but see my earlier comments
about possible coupling of these suffixes to parameters like charset). However,
RFC 3023 said nothing about other +suffix constructs. And people definitely
want to use the convention for other popular structuring syntaxes. And all RFC
4288 has to say is:

    More generally, "+suffix" constructs should be used with care, given the
    possibility of conflicts with future suffix definitions. 

In my role as IANA media tyypes reviewer, I have interpreted this as meaning
that the +suffix construct should only be used when "suffix" actually
identifies a well known structuring syntax. I have pushed back on other
uses (I believe there was someone who wanted to register something like
application/vnd.typename+vendorname, for instance). But beyond that I have
allowed such registrations to go through.

What I do not do, and wish I could do, is push back on registrations of types
based on, say, JSON, saying they should be using +json. I don't believe the
current rules allow me to do that.

What I think is needed here is a revision/update to RFC 4288 to establish a
registry of allowed +suffix constructs as well as expanded guidelines for their
use. I also think pretty much any well defined structuring syntax should be
allowed in the registry. (It's not like there's a shortage of them either.)

				Ned

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 21 Sep 2010 20:34:39 -0600

On 9/21/10 7:15 PM, Ned Freed wrote:

> use. 

That sounds like an excellent idea.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Libbrecht <[email-masked]>
Date: Wed, 22 Sep 2010 09:36:31 +0200

> That sounds like an excellent idea.

Could that include usage of multiple plus for hierarchical typing?
paul

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Sep 2010 09:20:06 -0700 (PDT)

> Could that include usage of multiple plus for hierarchical typing?

Anything is possible, but given past resistance to hierarchical structure in
media types, I think it's a little unlikely we'll get consensus on such a
mechanism. 

My personal take is that it's a bad idea, because I think it will encourage
people to regard these as properties that can be attached to anything or
placed in any order, which isn't how things work.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Sep 2010 12:26:14 -0400

> placed in any order, which isn't how things work.

It's been so long that I've forgotten - what was the reason to not define new top-level types for things like XML and JSON?

Keith

---

From: Mario Salzer <[email-masked]>
Date: Wed, 22 Sep 2010 21:37:19 +0200

> It's been so long that I've forgotten - what was the reason to not define new top-level types for things like XML and JSON?

Laziness and hypothetical compatibility woes. Also top-level mime
types are disallowed to prescribe a format or structure. (Well, except
for multipart/, message/, text/, vnd.*/ ...)

But basically the tertiary MIME descriptor +xml came to be as mailing
list choice award among similar suggestions, and because it was
perceived as too much effort to register an xml/ type:
http://www.imc.org/ietf-xml-mime/mail-archive/mail2.html

---

From: Ned Freed <[email-masked]>
Date: Wed, 22 Sep 2010 09:30:17 -0700 (PDT)

> It's been so long that I've forgotten - what was the reason to not define new
> top-level types for things like XML and JSON?

Mostly because the structuring syntax is completely orthogonal to what
top-level media types tell you. It's entirely reasonable to have image, video,
or model types that use XML or JSON. Subtypes of message that use XML or JSON
aren't out of the question either.

				Ned