W3C home > Mailing lists > Public > www-tag@w3.org > January 2011

RE: Feedback on Internet Media Types and the Web

From: Larry Masinter <masinter@adobe.com>
Date: Thu, 13 Jan 2011 15:32:37 -0800
To: "Eric J. Bowman" <eric@bisonsystems.net>
CC: "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D058EB90161@nambxv01a.corp.adobe.com>
The problem is that using something like "+json" without having
a definition for what it means doesn't really help anyone except
if you think that a MIME type is a fashion accessory and not a 
protocol element with a definite meaning. 

Are text/something+json bodies guaranteed to be in UTF8? Which version
of JSON is used?  Is there any internal framing? 

Defining +xml and what guarantees can be assumed by a +xml MIME
type was very difficult. Without any guarantees (for a conforming
implementation), then the adding extra protocol for +json isn't
helpful, since it's meaningless except as a "gee we're cool"

There's nobody home but us. So there's no one else other than the
JSON-mime-type using community to define what "+json" means. If they're
not willing to do that work, then perhaps it isn't important that
the +json MIME types actually be defined, and perhaps they're just
"mime-type-like" labels because there's nothing in particular you would
or should do if you get a text/frob+json MIME body. Right? At least
with XML there was some expectation of generic processing either with
CSS or with XSLT.

I'm willing to put something in the document about this situation,
but would like to get agreement on the nature of the problem,
e.g., something like:

"People want to use suffix-type registration, in analogy to
the +xml definition, for things like types based on ZIP or
JSON, using +zip or +json respectively, but they're not willing to
do the work to define what those suffixes mean."

and then go into some discussion of +json and +zip examples?

Received on Thursday, 13 January 2011 23:33:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:36 UTC