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

Re: Feedback on Internet Media Types and the Web

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Wed, 12 Jan 2011 01:07:22 -0700
To: Larry Masinter <masinter@adobe.com>
Cc: "www-tag@w3.org" <www-tag@w3.org>
Message-Id: <20110112010722.39d7eb7b.eric@bisonsystems.net>
Larry Masinter wrote:
>
> What Ned asked for seems reasonable:
> 
> > 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.)
> 
> I don't see anything keeping you from doing that... and then going on
> to define what "+json" does or does not mean in a MIME type.
> 

My interest is only to avoid being flamed every time I point out that
+json, unlike +xml, is undefined (and thus, not self-descriptive); but
that isn't enough to motivate me to do the work, which I'll leave to
others who are (those desiring to register +json types, or +yaml or
anything else).

>
> I was trying to identify things that were actually wrong with what we
> had and needed to change. As it stands, there's nothing in the way 
> of someone defining other suffix types than "+xml" except for a lack
> of people who are willing to do the work.
> 

The problems with what we have may all be summed up as a failure of the
registry to keep up with the times.  I guess my feedback is that the
scope should be extended to address the suffix problem, because it's
integral to the overall goals -- the lack of a suffix registry leads to
just the failure you mentioned earlier in this thread (proven by the
proliferation of +json types in the wild):

>
> When vendors can and do deploy software which uses non-registered
> values in situations where registration is required, the registration
> process does not accomplish this intention: the situation it is
> meant to avoid is not avoided.
>

So if we're going to talk about proper use of media types, and fixing
the registry and registration process, it seems to me like any changes
required to RFC 4288 for any reason, are a good fit.  I don't make a
distinction between historic problems, and a new problem like the
unforseen demand for suffixes arising from the fantastic success of
+xml.

It doesn't make sense to ignore that problem here, where the interest
and expertise exist to fix the process, and leave changing RFC 4288 up
to guys like Nathan and Kris who just want to define new media types
(although changing RFC 4627 probably is up to them, and out-of-scope
here).

BTW, it's nice to see image/svg+xml in the registry...

-Eric
Received on Wednesday, 12 January 2011 08:07:56 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:29 GMT