- 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>
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" indicator. 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? Larry
Received on Thursday, 13 January 2011 23:33:12 UTC