RE: Use of metadata in URIs

Hi Larry,

> -----Original Message-----
> From: Larry Masinter [] 
> Sent: 30 September 2003 04:46
> To: 'Williams, Stuart'
> Cc:
> Subject: RE: Use of metadata in URIs
> (trying to keep this short)

Lest it need be said, I very much appreciate your input, thanks.

> > I was actually trying to explore from two perspectives...  that of an 
> > assignment authority (and the infrastructure under their control, eg.
> > servers - and maybe CDNs); and that of 'observers' of URI assigned
> > of their own authority. It seems to me that the 'freedoms' to read
> > into a URI are different from each perspective.
> The finding says it is intended to address two related questions:
> 1. What, if anything, can be inferred from a URI used to 
> identify a resource? 2. What information about a resource can 
> or should be embedded in a URI used to identify that resource?
> Neither of these questions seems to be posed from the point 
> of view of an 'authority' who might 'assign' a URI. 

I see the first question as taking the observers perspective and the second
as taking the assignment authority's perspective. 

> URIs are used in communication. There is the agent (person or 
> software) that utters (publishes, sends) the URI, and there 
> is the agent (person or software) that receives and interprets the URI.


> In some cases, there might also be some process or procedure 
> involving some agents that might cause a URI to be associated 
> with some resource, 


> e.g., a webmaster at a web site 
> configuring a web server and a user of that site storing some 
> file in a directory that the configuration points to. But the 
> intent and roles of these agents ('authorities', if you like) 
> aren't really involved in the conversation about 'what, if 
> anything, can be inferred'.

Ok... maybe... but there is (at least the perception of) a chain of
specifications through which authority is delegated - rooted in the RFC2396
- and that is (or can be) involved in the behaviours that get programmed
into these agents.

Maybe this is a mis-perception, which I think is the position that you are
taking. If that's the case I think it is quite widely held, and I don't know
where the concensus actually lies, even amongst the small community cited as
authoring 2396 - never mind the large community (including myself) that may
have read too much into it.

> When I tell you I have a comment about  
>, our 
> mutual understanding of the meaning of that URI 
> doesn't depend on whoever has "control" or "authority" over "", 
> except for our mutual belief that when we poke that URI we will get the 
> same reaction. It's an operational understanding.

Ok... yes... an operational understanding that there will be some
consistency about representations retrieved (exchanged) when using that URI
with the HTTP protocol.

> Even when an authority 
> does have something to say about a 'http' URI, the authority (should) 
> make its will known by doing something operational.

Examples would be:

- Meta-data in header fields?
- Making available RDF resource decriptions in some way?
- Publishing RSS feeds?


> >(from RFC 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."
> Perhaps it should be clearer, but the goal of this wording was to define 
> the generic syntax, and to allow the generic syntax to be used in a wide 
> variety of schemes. RFC 2396 never mandates that schemes use the generic 
> syntax, it just makes it available. So I don't think the generic syntax 
> should ever be taken as _definitional_ for the meaning of URIs. Every 
> scheme that uses the generic syntax must still say, operationally, how 
> the components are combined to create semantics.

I accept much of this: that RFC 2396 sets up a generic syntax that schemes
can opt into. However RFC 2616, appears to opt-in in the specification of
the HTTP URI scheme, and albeit the last item in a list, explicitly includes
the RFC2396 definition of "authority"

(from RFC 2616)
3.2.1 General Syntax

   URIs in HTTP can be represented in absolute form or relative to some
   known base URI [11], depending upon the context of their use. The two
   forms are differentiated by the fact that absolute URIs always begin
   with a scheme name followed by a colon. For definitive information on
   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
   Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
   1738 [4] and RFC 1808 [11]). This specification adopts the
   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
   "host","abs_path", "rel_path", and "authority" from that

The word 'authority' in the extract from 2396 above is used in two senses.
1) as a syntactic element in a generic syntax; 2) as some instrument of
governance over some 'namespace' associate with a value conveyed in such a
syntactic element.

Is this (over interpretation of the word 'authority' on my part) something
that needs to be cleaned-up in the revison of the URI spec.?



Received on Tuesday, 30 September 2003 07:03:06 UTC