Three bits on MediaTypes and IANA

I briefly spoke to TimBL (W3C Director) about our present use of 
media-types, URIs for IANA registry types and he identified three issues 
that require further work. I address the issue and necessary action. I will 
then forward these bits will then be forwarded to the appropriate groups as 
necessary.

IANA/ISI directory

IANA has made progress in maintaining a living directory of assignments on 
the Web at http://www.iana.org/numbers.html . For media types, this 
directory now refers to:
  http://www.iana.org/assignments/media-types/
This is an improvement in that I have greater confidence in the 
persistence of this URI over that of the ISI:
  http://www.isi.edu/in-notes/iana/assignments/media-types/
However, under iana.org they now only provide a URI for the top level types 
(and we want a URI for every type and a way to encode their parameters.) 
For example:
  http://www.iana.org/assignments/media-types/text/
(There's no way to specify text/xml with a URI as one could do under ISI:
  http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml  )

Orthogonally, Eastlake has specified a way of mapping media-types and URIs 
amongst each other:
  http://www.ietf.org/internet-drafts/draft-eastlake-cturi-03.txt
This draft addresses much of the tricky character encoding and parameter 
issues within a URI but relies on the provision of a new URI scheme 
"Content-Type:" (Additionally, Eastlake provides a URI to Media Type 
mapping which is a neat proof-of-concept but I'm not sure its worth the 
complexity in that spec.)

Consequently, it'd be best if we could use Eastlake's encoding and 
parameter rules for URIs hosted at iana.org (instead of creating a 
Content-Type URI scheme) where there was a single de-referencable URI for 
every registered media type and its possible parameters.

ACTION Reagle: send this issue to IETF/W3C coordination list for info from 
IETF on intended direction of iana.org web space. Failing that this is 
likely to be addressed in a timely manner: (a) XML Encryption might revert 
to the xmldsig approach of string values for MimeType and Encoding -- 
unfortunately these are all just strings and we only have one "parameter" 
(the "ds:Encoding" attribute) -- (b) W3C could proxy/create a set of URIs 
for register media types for our own purposes.

PARAMETERS

TimBL is opposed to using "#" or "?" at the end of example.html (eg., 
http://www.isi.edu/in-notes/iana/assignments/media-types/text/html#charset=iso-8859-1&level=2
) if the URI maintainer doesn't provide a way to give something back about 
that information.

ACTION Reagle: Consider the possible alternatives, discuss with TimBL. 
Maybe this can be resolved once there's progress on the above issue.

ENCRYPTION MEDIATYPE

TimBL has suggested that an XML document with EncryptedData at its root 
would benefit from its own mediatype since it has the interesting property 
that an application should be aware of that after decrypting the mediatype 
of this object might itself change! (If I encrypt a PNG, place it in an 
EncryptedData (type text/xml) when I decrypt it, it will no longer be 
"text/xml".)

ACTION Reagle: send request to consider registration of (something like) 
application/xenc+xml to W3C Management.

-- 

Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Monday, 14 January 2002 17:06:45 UTC