Re: comments on draft-eastlake-cturi-01.txt

Hi Larry,

From:  "Larry Masinter" <masinter@Adobe.COM>
To:  <uri@w3.org>, <Donald.Eastlake@motorola.com>
Cc:  "Donald Eastlake 3rd" <dee3@torque.pothole.com>,
            "Graham Klyne" <GK@NineByNine.org>,
            "Michael Mealling" <michaelm@netsol.com>,
            "Ted Hardie" <hardie@equinix.com>
Date:  Thu, 18 Jan 2001 11:01:57 -0800
Message-ID:  <NDBBKEBDLFENBJCGFOIJMEDFEEAA.masinter@adobe.com>
In-Reply-To:  <5.0.0.25.2.20010110132232.02d54bd0@pop.dial.pipex.com>

>I'm taking the liberty of copying this discussion to "uri@w3.org".

Sure.

>A group of us were working on creating a general mechanism
>for writing URIs that identified protocol elements that were
>registered by IANA. The idea was to support, in a general way,
>the policy in some quarters of using URIs as the unique identifiers
>for various protocol elements, rather than having a centralized
>registry.

Huh?  I have no problem with both (1) mapping existing non-URI
protocol parameter values to URIs or (2) using URI syntax as the
syntax for some protocol parameters to start with if appropriate.  But
the first of these doesn't have anything to do with avoiding a central
registry.  And the second only does to the extent that you use URIs
which provide for embedded domain names or sufficiently large random
numbers or something else the provides hierarchical or completely
localized generation of unique identifiers.

There are many protocol parameters for which URI syntax is just not
reasonable as the primary format, many of them low level protocol
fixed size binary fields.  For protocol parameters where a
non-registered value makes sense, there is usually a provision for it,
as in "x-" and "x." MIME types.

>           To allow protocols that used URIs to also reference
>IANA-registered data, we were working on developing a general
>"iana" URN name space, where "urn:iana:<registry>:<value>" would
>make reference to the IANA value.

It strikes me as hard to pre-specify how to map all current and future
possible IANA allocated/registered protocol parameter values to URI
syntax.  And if you did, I certainly don't think it should have the
string "iana" in it.  If the Internet teaches us anything, it is that
things change.  What do you do when something is moved from IANA to
another orgnaization?

>However, for the case of content-types (which was the original
>motivator), Don Eastlake wrote a draft 
>    http://www.ietf.org/internet-drafts/draft-eastlake-cturi-01.txt.

I was originally inspired due to the problems we encountered in the
XMLDSIG effort where we wanted to by able to provide "type" labels and
for a while flip flopped around between allowing URIs,
MIME-Types/Content-Types, or both.  We ended up mostly using URIs but
have an Object element that uses MimeType.  It seemed clear to me that
in a W3C/XML context you usually want URI syntax whereas in
SMTP/HTTP/etc. you have to use Content-Type syntax.  Yet you might, in
either case, wish to express a "type" which was already or more
naturally named in the other syntax.  So I defined a mapping.

>I think draft-eastlake-cturi does a much more complete job
>of injecting content-type definitions into URI space than we
>were contemplating; there's more complexity, but I think the
>complexity is necessary for the application.

Thanks.

>I'm concerned about having a "contenttype" URL scheme, and
>might rather see urn:iana:content-type:... where Don would
>have written "contenttype:", just to avoid proliferation of
>schemes which are merely used for this kind of embedding.
>Now, perhaps "urn" itself isn't the right scheme.

Well, since we both ran into this for Content-Type it is probably the
most common case where a mapping is desired.  Perhaps a try at this
more complex and common case should be considered separately and have
the benefit of the simplicity and brevity of a simple scheme name.  In
any case, as mentioned above, I don't think "iana" should be in the
syntax.  References to particular organizations always get outdated
eventually.  And I don't see that urn adds anything.

>I don't think section 3 belongs in the document; it isn't
>about registering a URI scheme for naming content-types, but
>about some other kind of hint about processing.

The document tries to be more comprehensive that simply providing a
way to subsume content-types into URIs.  It provides mapping in both
directions, because I think there is equal liklihood of a need for
mapping in both directions.  Furthermore, there is almost always
structured processing of Content-Types, with dispatch on the top level
and/or sub-type.  It seems reasonable that there might be structured
processing of type "label" URIs, such as an attempt to dereference
one.  Given this, someone writing either such a URI or a Content-Type
who anticipates that it may be mapped into the other syntax could
benefit from control over such mapping.  If such control is worth the
complexity, which I tend to think it is, I just don't see much point
in bothering to put it in a separate document.

>Larry

Thanks,
Donald
===================================================================
 Donald E. Eastlake 3rd                    dee3@torque.pothole.com
 155 Beaver Streeet                         lde008@dma.isg.mot.com
 Milford, MA 01757 USA     +1 508-634-2066(h)   +1 508-261-5434(w)

Received on Thursday, 18 January 2001 23:36:54 UTC