Fwd: Three bits on MediaTypes and IANA

I think a few of these questions are relevant across w3c technical 
activities so I thought I would forward it on for consideration -- let me 
know if this is inapproriate.

----------  Forwarded Message  ----------

Subject: Three bits on MediaTypes and IANA
Date: Mon, 14 Jan 2002 17:06:45 -0500
From: Joseph Reagle <reagle@w3.org>
To: xml-encryption@w3.org

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

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:
This is an improvement in that I have greater confidence in the
persistence of this URI over that of the ISI:
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:
(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:
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.


TimBL is opposed to using "#" or "?" at the end of example.html (eg.,
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.


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

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:37:33 UTC