metadataInURI-31: Guide to Feedback and Outstanding Issues

Author: Noah Mendelsohn

Date: 28 March 2006

This is a page I prepared to help myself come up to speed on TAG issue metadataInURI-31. I've posted it in hopes it will be helpful to others, but this is not an official work product of the TAG. I'll be glad to consider suggestions for updates, but there's no guarantee that I'll be responsive to requests for changes.

Anyway, I'm trying to do three things here: (1) make it easy to find what I take to be the most important feedback that's been gathered in the years this issue's been alive; (2) summarize some options for how to move ahead; and (3) give some of my own opinions on what the finding should say.

Where to Find the Finding

The main URI for drafts on metadataInURI-31 is:; the latest copy in date space as of today is the draft of 8 July 2003.

Earlier feedback and discussion

Here's a brief guide to discussion that's already been had in TAG meetings and in email.

Discussion of metadataURI-31 in TAG meetings

The issues list entry includes links to TAG minutes in which discussion occurred. As you'll see from the summary below, only a few contained substantive technical discussion. The table below should make those easier to find (I don't guarantee summaries are complete and unbiased—read the originals and draw your own conclusions):

Meeting Date Summary of Discussion
2 Dec. 2002

References message from Ossi Nykänen. Ossi proposes that metadata be in a separate resource, but that a naming pattern in URIs would allow one to guess the name of the metadata resource for any given starting URI. E.g.: For a resource referred to by


the RDF description (declared by the resource) will be found at


So, at the next level, there is metadata in the URI, because you infer a relationship between the two resources.

Dave Orchard expresses an interest in versioning resources. Tim Bray says "Notion of encoding metadata in a URI is broken." Tim Berners-Lee encourages use of RDF :-).

Resolved: Accept issue matadataInURI-NNN with note that TAG thinks the answer is "no" and will explain what to do instead.

6-7 Feb 2003 (Irvine) Stuart Williams assigned to draft finding. No other action or discussion.
7 July 2003 This session appears to be commenting on a 4 July 2003 Member-only draft from Stuart.
  • Dan: (hmm... no story atop 4 July 2003 draft of finding)
  • Dan: I think the finding may be getting too long. I was hoping for three paras that say "Don't peek into URIs. People and software making use of URIs assigned outside of their own authority (i.e. observers) MUST NOT attempt to infer properties of the referenced resource except as licensed by relevant normative specifications or by URI assignment policies published by the relevant URI assignment authority."—Shorten 3 to "Don't peek inside the URI." It's always safe to not peek inside the URI.
  • Dan: the W3C tech reports naming policy isn't based on the URI alone. there's no guarantee that is a W3C working draft. If you know that it is a WD somehow, you can learn stuff from the URI. but you can never just peek into the URI alone. (FWIW: Noah observes several years later that this seems to be a key point. There's metadata you may be able to use in the URI if you have specific information from the resource owner, but that's very different from trying to follow your nose given some arbitrary URI and only well-known specs. with which to grok it.)
    • NW: If I understand DC correctly, sounds like DC is saying that if I know XQuery is a Working Draft, then I can find meaning in WD in URI. If I saw a URI ending in "WD-".... could I infer that it's a WD?
    • DC: No You have to look at the TR page as well. Once you have found something on the TR page, there's quite a bit you can go on. If you start from the TR page and find the URI, that's fine. But if you find the URI on the floor somewhere, you can't go on that alone.
  • DO: Amazon publishes policy for query parameters.
  • Action SW: Create new draft based on input today and send to www-tag.
  • Action DO: Send rationale about why WSDL WG wants to peek inside the URI.
21-23 July 2003 (Vancouver) These minutes appear to have the last detailed technical discussion of metadataInURI-31. They are lengthy and worth reading. Some highlights:
  • SW: Is "don't peek inside" enough advice?
  • TBray: I think happy medium between minimal approach (DC) and SW's current finding is:
    1. When you are processing a URI, there are normative specs (starting with [URI], then scheme specs); it's fine to peek inside URIs and interpret per normative specs.
    2. Beyond that it's inappropriate to make other assumptions by peeking in URI UNLESS you have private agreements (i.e., rules published by the URI authority).

    I think draft finding is too long, but I'm prepared to accept the assertion that SW's finding says what I mean. Do people agree that it's ok for the WSDL folks to say how to interpret their URIs?

    Later it was noted that some feedback in email had been in favor of keeping sections past sectin #1, somewhat contradicting the suggestion to make the finding shorter.

  • DO: I think that we need to describe when it's ok to peek inside a URI. And when it's ok to write a spec that says it's ok to peek inside a URI.
  • TBL: I have a criterion for this: suppose that someone has not come across the WSDL spec. Given a URI that was constructed according to the WSDL rules, can someone with such a URI (alone) determine that it's a WSDL URI? For example, do they get back a description (e.g., in a representation) of how to use the URI?
  • Dan: I think I agree with Bray that replacing the finding by its 1st section would be forward progress.
  • Interchange on fragids and content types:

    • NW: You can't say squat about meaning of frag ids until you get the representation with the proper content type.
    • TBL: I'm fine to talk about an imaginary document. But if you do retrieve it, you need to register a new content type or a frag id syntax.
    • TimBL-YVR, you wanted to say that if you want a funny fragid syntax you need a new mime type
    • DO: The WSDL WG wants to register a new content type.
  • specs defining patterns for using structure in URI assignments to name abstract things, how do you establish a chain to establish authority to make such an assignment? 2396 delegates assignment authority to URI schemes which in turn delegate onwards ultimately to some specification or person or organisation. Such an authority could then explicitly state that they do in fact make assignments according to the specified pattern.
  • Discussion of adding examples. Some sentiment for keeping only section 1, but adding examples. Suggestion that forms be one of the examples.
  • Seeming agreement that it's good to discuss schemes in general (ftp, etc.), not just http.
  • Discussion of pros and cons of fragids carrying metadata. Not sure I follow all the nuances just yet.
  • Discussion of how creating specs that require metadata in URIs causes stress for server systems that have their own mappings from internal structures to URIs.
  • There is repeated reference in the minutes to 19 June summary from DO; unfortunately, that link is a 404!

Much more was discussed, but the above gives the flavor of the main areas considered.

6-8 October 2003 (Bristol)
12-14 May 2004 (Boston) Stuart promises draft by mid-June. No technical discussion.
7 Feb 2005 Noah briefly mentions relationship to WS Addressing (I.e. if you don't use reference parameters, then you probably need to encode the equivalent in the URI.) Otherwise, no other technical discussion. Stuart agrees to pursue issue, with help from Noah.
21 Sept 2005 (Edinburgh) Norm says we should keep working. Noah and Roy take ACTION to do it. No other technical discussion.
13 Dec 2005 No substantive technical discussion, except for a bit of review regarding the person who got in legal trouble for trying ../../.. in his browser.

Email discussion

Apparently, Stuart Williams went through a similar process of trying to consolidate input back in November of 2004. He wrote an email (member-only) which is basically an index to all the email he'd been through on the subject to that date. With Stuart's permission, I've included here a list that's heavily based on his input from that email:

Summary of comments on metadataInURI-31 draft finding:

Original question: "Should there be a standard way of embedding metadata
in URI"; Answer NO.

Embedding is ok... extraction may be more problematic:


Technical comment on .ca domain example:
Mark Baker:

Finding size:
  Says too much: 
     Tim Bray:
     Mark Nottingham:
     Oliver Fehr:
     TAG (someof):

  Keep sections 2 and 3:
     Mark Baker:
     Noah Mendelsohn:
     TAG (someof):

Bring some of the more important points forward:
Noah Mendelsohn:
Mark Nottingham:

Embed metadata, DO peek inside:
Michael Daconta:
Michael Daconta:

Don't Peek;
Patrick Stickler:
Paul Prescod:
Len Bullard:

Embed static characteristics only;
Patrick Stickler:
Michael Daconta:

There are better ways of getting resource metadata:
Patrick Stickler:

REST "hypermedia as the engine of application state" of relevance:
Mark Baker:
Mark Baker:
Stuart (understands):

Some URI scheme specs do seem to try to constrain the sort of
resource referenced:

Sort of resource unconstrained by URI scheme (indirect indentification):
Mark Baker:

Just "Don't Peek" is too simplistic:
(but don't peek - generally)
Partick (middle ground):
Mark Nottingham:

Syntactic understanding is not peeking:

Truely opaque URI; syntactic conventions about schemes and #s would
require rework of existing specs.:
Jonathan Borden:

Robustness prinicple applied to URI:
Stuart(some appeal):
Mark Baker (disagrees):

Identity and Identification...don't get confused:

Indirect reference and context of use:
Stuart (agreeing):

Identifiers and Identification are related (inherently):
Len Bullard:

Re: sec 3.3 ednote: Query responses rarely cached, URI treated as opaque
if they are:
Mark Nottingham:

Target some of the comments at 'agent' implementers and spec writers.
Mark Nottingham:
Mark Nottingham:

Notion of Authority is 'overplayed' Most URI scheme defn's are
Larry Masinter:

Assignment, interpretation on receipt and intention when making
reference are different things.
The finding is more about the last two which is separate from the
association of a resource with an identifier.

Operationalise: Think operationally.
Larry (off-list correspondence).

Separate URI assignment from attributions of meaning:
Larry (off-list correspondence)

Forms as server suppled specifications for URI query construction.
Larry (offlist correspondence)
David Orchard (offlist correspondence).

TAG July F2F Comments:
TB,DC,DO proposal: just section 1 plus examples inc. 
 - what format spec. designers can do. (DO)
 - Give an example of a relative normative spec that is providing
policies for looking within the URI.  (RF)
 - add a a mention that fragid needs mime type in 3.4 (TBL)
 - Section 1.1, part one - We need an example. (RF)
 - possibly merge sections 2 and 3 into a URI component centric view.
 - Need to be clear that 'authority' propagates through specs. (TBL)

Deciding how to move forward

Stuart's email makes clear that there's been quite a lot of discussion, and as someone who's just taking responsibility for this finding, it's clear that we need to strike a good balance between:

I think we need to do some of both, but my inclination is to pursue mainly the 2nd path. It's going to be very painful to debate each of the old email points in detail, though I will certainly read them and try to extract key ones. So, in the section below, I offer some strawperson proposals on what the key points of the finding should be.

Proposed key points of a finding on metadataInURI

The following in part reflect my own tentative opinions, and in part my distillation of what appeared to be emerging consensus in earlier discussions. So, I propose that the principle goal of the finding be to make the following points:

I'd be happy if the finding made those four points, perhaps with some examples.

Change log