[URN] Re: Relative URLs, // and ;

["Martin J. Duerst" <[e-mail]>]

On Mon, 27 Jan 1997, Ron Daniel Jr. wrote:

> [I'm adding [e-mail] to the Cc list since that is the
> list for the IETF's URN-WG.]
> 
> Thus spoke Tim Berners-Lee:
> 
> >The URN scheme should be
> >mapped onto
> >urn1://authority/nameissuedbyauthority

As far as I understand, the first part after the "urn" prefix is
not an authority (work is going on on mechanisms to actually
find such authorities or resolvers), but more akin to a scheme
in the URL case. So the use of ":" instead of "//" has some
merit.


> The proposed URN syntax is laid out in draft-ietf-urn-syntax, but
> the short description is:
>    urn:namespace_id:namespace_specific_string
> for example
>    urn:isbn:1-234-5678-9
>    urn:upc:42709-10150
> etc.
> 
> Some namespaces, such as ISO Formal Public Identifiers, already make
> use of '//'. For such namespaces we say they need to %encode occurances
> of '/' that do not follow the rules of RFC1639. Those rules were that
> '/' denoted hierarchy with the most significant component on the left.

I beg to disagree. URNs are designed to be syntactically equivalent to
opaque URLs. In an opaque URL, escaping of '/' is not needed, unless
it is syntactically significant. See e.g. section 2.1 of draft-fielding-...
The only reserved characters that URN syntax itself uses is ":",
and this doesn't have to be escaped because it cannot appear in the
first two parts ("urn" and e.g. "isbn"). The need of escaping
of reserved characters after the second ":" is determined by the
needs of the namespace. These will usually be rather low, as
some of them don't use many characters so that there is no
problem identifying reserved characters, and others will
most certainly have their own way to get around this problem.
E.g. in the case of "isbn", "-" is a reserved character, but
it is not also used at the place of a digit (or X). In the
case of ISO Formal Public Identifiers, either "/" is also
disallowed between structurally meaningful "/", or there
must be a way to escape such "/".


> At this time we have not defined any relative URN specification.

Because URNs are persistent, the main advantage of relative URNs,
namely invariance on coordinated movements to other locations,
is irrelevant.
What could be more relevant is the possibility to address parts of
resources, or 'locations' within resources, together with URNs.
I have sent some considerations about this to Leslie as a
response to her request on the URN mailing list; I can make
this available if somebody is interested.


Regards,	Martin.