W3C home > Mailing lists > Public > www-tag@w3.org > September 2003

RE: Use of metadata in URIs

From: Williams, Stuart <skw@hp.com>
Date: Mon, 29 Sep 2003 15:48:43 +0100
Message-ID: <5E13A1874524D411A876006008CD059F04A077F6@0-mail-1.hpl.hp.com>
To: "'Larry Masinter'" <LMM@acm.org>
Cc: www-tag@w3.org

Hello Larry,

Thanks for your comments.

> -----Original Message-----
> From: Larry Masinter [mailto:LMM@acm.org] 
> Sent: 28 September 2003 17:58
> To: www-tag@w3.org
> Subject: Use of metadata in URIs
> I think the problem is that 
> http://www.w3.org/2001/tag/doc/metaDataInURI-31.html
> has looked at the problem from the wrong perspective.
> "...outside of their own authority (i.e. observers)..."

I was actually trying to explore from two perspectives... that of an
assignment authority (and the infrastructure under their control, eg. origin
servers - and maybe CDNs); and that of 'observers' of URI assigned outside
of their own authority. It seems to me that the 'freedoms' to read something
into a URI are different from each perspective.

> I don't think the web architecture is (or can  be)
> clear about the notion of "authority". It's some terminology 
> that has crept into many of the discussions about URIs and 
> their meaning, and I think it's misplaced.

That's interesting. I had been trying to work with a notion of authority
that I thought was rooted in the generic syntax of RFC2396, sections 3, 3.2.
and 3.2.2. RFC2616, section 3.2.1 also seems to import the definition of
authority from 2396. Granted both 2396 and 2616 speak of authority very much
as a syntactic component and place few (if any) obligations on a naming
authority - form 2396:

  "3.2. Authority Component

     Many URI schemes include a top hierarchical element for a naming
     authority, such that the namespace defined by the remainder of the
     URI is governed by that authority. This authority component is
     typically defined by an Internet-based server or a scheme-specific
     registry of naming authorities."

I, and I believe a number of others, are under the impression that wrt to
URI schemes which use DNS host names in the authority field, then the
governing authority for "the remainder of the URI" is the 'owner' (yes
poorly defined ownership relation) of the DNS host name. Ie. the URI spec.
delegates assignment authority to the scheme spec.; the scheme spec. (in
this case) delegates URI assignment authority to the 'owner' of the DNS host
name... and in parallel the DNS system delegates 'ownership' of DNS names
though a registration process root at the top and delegated through
top-level domains and beyond.

This chain of delegation did (does) make sense to me - with the possiblity
of the delegation chains terminating in a spec. rather than with a machine
or a person or an organisation (modulo organisations being responsible for

> The only URI scheme registered that acknowledges that there 
> might be an "authority" that "assigns" URIs is the "urn:" 
> scheme.  Most other URI schemes give an operational 
> definition -- "http:" about using the HTTP, "ftp:" about 
> using the file transfer protocol, "mailto:" about sending mail.

I accept that the specifications for the http:, ftp: etc URI schemes are
operational in nature (and I like their pragmatic style in that respect).
However, at least the http: spec. in RFC2616 seems to appeal to the notion
of authority in RFC2396 - many of the other scheme specifications pre-date
RFC2396 and (understandably) make no mention of 'authority'.

> I think what the finding is trying to get at could
> be better stated as follows:
> There may be policies and processes involved in creating
> or resources and other communication endpoints that
> can be reached using particular URIs, but an agent
> looking at or trying to interpret those URIs should
> not make any assumptions beyond those that are actually
> defined by the URI scheme definition itself.

That does indeed capture the spirit of things, although I was trying to give
an account from the POV of the assignment authority (or entities operating
on its behalf) as well as from the point of view of 'the casual observer' or
"an agent" in your rendition above.

> Since the HTTP protocol doesn't require that
> URIs ending in ".html" are really text/html,
> or that URIs not ending in ".html" are not,
> then an agent looking at a http URI shouldn't
> try to infer its type from the URI ending.


> (On the other hand, the definition of the "file:" URI
> scheme probably _should_ assign such meanings....)

:-0 ...as a way of 'encoding' the media-type because there is no other
generic way of conveying media type information?

> Larry
> -- 
> http://larry.masinter.net


Received on Monday, 29 September 2003 10:55:30 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:39 UTC