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

Hi:

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.

> - 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 "/"
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
processing.:)

> >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?

> >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.

Tony


Tony Hammond

New Technology, Nature Publishing Group
4 Crinan Street, London N1 9XW, UK 

tel:+44-20-7843-4659
mailto:t.hammond@nature.com




********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************

Received on Wednesday, 1 September 2004 15:56:49 UTC