W3C home > Mailing lists > Public > uri@w3.org > September 2004

RE: updating RFC 2718 (Guidelines for new URL schemes)

From: Martin Duerst <duerst@w3.org>
Date: Sun, 05 Sep 2004 09:04:29 +0900
Message-Id: <>
To: "Hammond, Tony" <T.Hammond@nature.com>, Larry Masinter <LMM@acm.org>, uri@w3.org
Cc: djz@corp.webtv.net, rpetke@wcom.net, 'Harald Tveit Alvestrand' <harald@alvestrand.no>, Tony Hansen <tony@att.com>, 'Paul Hoffman / IMC' <phoffman@imc.org>

At 16:56 04/09/01 +0100, Hammond, Tony wrote:

>I had a few questions - see '@@@'
> > - We have to clearly state that every URI scheme syntax has
> >    to follow the (generic) URI syntax in that it cannot allow
> >    URIs that don't fit into the URI syntax. As a very simple
> >    example, if a foo: scheme would allow "#" as part of the
> >    URI syntax, it would be out. Similar for misusing "%", and
> >    a few other things.
>@@@ Not clear that I understand why "#" would not be allowed. According to
>2396bis it is a legal URI character introducing a fragment component which
>is an optional component of a generic URI.

Yes. But URI schemes only describe the part before the "#".
Fragment identifiers are independent of URI schemes.

In other terms, the syntax that an URI scheme has to define has
to be a subset of absolute-URI in rfc2396bis.

> > - We also should recommend that any components of the generic
> >    syntax (e.g. // for top level, / for hierarchy,...) are used
> >    with the semantics defined in RFC 2396bis.
>@@@ I am also not sure that 2396bis goes so far as to actually require

It does not. That's why I used 'recommend' above, not 'require'.

>to be a hierarchical delimiter for a given scheme, but it rather says that
>URI schemes that do not want to remain opaque must support hierarchical
>processing. (I presume the "data" URI scheme would also support hierarchical

I think we will have to work on the details of the wording here,
to get it right.

> > >I think it's useful if schemes are clear about whether
> > >(or under what circumstance) the 'resource' might be
> > >something that returns a (body/entity/...?) which has
> > >a Media Type, and can be used with fragment identifiers
> > >in their conventional definition.
>@@@ What is the media type of a non-dereferenceable URI, as might be minted
>in a typical RDF application? This all seems very metaphysical to me. Or
>does the media type only come into play if a URI is dereferenced?

The RDF spec has some language somewhere that says something like
that a fragment id is to be interpreted as if the entity was of
type application/rdf+xml in case no entity can be retrieved.
That doesn't really mean too much, it just means "if you don't
have a media type to figure out what a fragment identifier means,
it means whatever it means". Metaphysical if you want to call it
that, or practical "nothing known in particular", if you prefer that.

In the general case, I think this is quite untread territory.

> > >2.3 Demonstrated utility
> > >
> > >I'd like to suggest that we require something stronger: that new URI
> > >schemes have demonstratable, new, long-lived
> > >utility:
> > >
> > >   Because URI schemes are a single, global namespace, the
> > >   unrestricted registration of many new URI schemes can
> > >   clutter implementation space, and possibly lead to
> > >   contention for "short names". For this reason, new
> > >   URI schemes should have a clear utility to the broad
> > >   Internet community, and provide some means of identifying
> > >   resources that is not already available with previously
> > >   registered URI schemes.
> > >
> > >Perhaps this is controversial :)
> >
> > It seems to go into the opposite direction of what was
> > discussed at the BOF, namely to relax the rules. But I guess
> > this could work out by saying that the above is desirable,
> > and there should be potential for it, rather than having it
> > as a hard-and-fast rule.
>@@@ Would have to agree with this last comment. I see no problem with
>cluttering of implementation space. An implementation should be able to
>detect a string being used within a URI context, parse it out to see that it
>conforms to the generic URI syntax, and then discover whether it has any
>rules to dereference such a URI. Of course, most implementations do not
>recognize generic URIs but only specific schemes which are hard coded into
>them. I am not a little sceptical of there being some kind of gold rush on
>URI scheme names.

Do you mean "not even a little sceptical", or "not just a little, but
a lot sceptical"? Or in other words, do you think we will have a gold
rush, or we won't?

Regards,   Martin.
Received on Sunday, 5 September 2004 00:05:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 13 January 2011 12:15:34 GMT