Re: [URN] Agenda for Washington Meeting -- Questions on URN

[Martin J. Dürst <[e-mail]>]

On Wed, 3 Dec 1997, Sam X. Sun wrote:

> In light of the handle system draft(draft-sun-handle-system-00.txt), and
> continuing on the earlier discussions with Roy, Martin, and Keith, I would
> like to raise the following questions before we wrap up the working group:

I'm sorry that I won't be able to be in Washington; I am waiting for
my visum for Japan because I will go to work there very soon.


> 2.	Most of the reserved/excluded characters of current URN are really
> restrictions from some current URL schemes, mostly from "http URL". For URN
> name space defined independently from URL, like Handle System, they are not
> required, and should not be put into the URN specification in the broader
> sense. For example, RFC1738 (url syntax), and the new URI draft
> (draft-fielding-uri-syntax-01.txt) allows reserved/excluded character sets
> to be defined on the individual URL scheme basis. Again, we are talking
> about URN in the broader sense here. How it's to be done under "urn:"
> implementation is another issue.

In particular with respect to the '#', which in the terms of
draft-fielding-uri-syntax-01.txt separates a fragment identifier
from the URI proper in an URI reference, you are well advised
to not reuse this character in your own uri scheme. Many
implementations won't like it. For other reserved characters,
the problems are smaller, but also exist.

Also, please note that because of backwards compatibility reasons,
you cannot have a non-ASCII character as scheme-reserved, unless
you completely disallow that character from the non-reserved
syntax of your scheme, because the distinction between %-escaped
and non-escaped octets/characters above 0x7F cannot be used
to distinguish between reserved and non-reserved instances
of the same character.


> 3.	Some URN specifications specifically exclude the support of user
> friendly names. While user friendly name may not be appropriate in some
> case, there are situations where friendly names are desired or even
> required. The underlying technology should not limit the usage of user
> friendly names. 

Fortunately, I currently don't see anything that limits the use
of user-friendly names. It would be difficult anyway, as human
beings are extremely good at giving meaning to even the most
obscure number sequences.


> 	On top of this, for any global naming scheme to support friendly names, it
> should not be limited to ASCII only, but should allow any native characters
> to be used directly without hex encoding. Otherwise, it can only support
> friendly names in English, but not in other languages like Greek, Russian,
> Chinese, Japanese, Korean, etc. For example, how could anyone tell that
> %C2%B7 is a friendly name in Greek? (Note: %C2%B7 is the hex encoded  UTF-8
> encoding of a Greek symbol, code point B7 defined in ISO-8859-7.)

There are various ways to see the current limitation to hex-escaped
UTF-8. One is to say that this limitation is necessary, and should
always be kept. The other is to say that it is temporary, in a
preparation for directly encoded or directly displayed native-script
URLs. Larry has published a draft on native-script UTF-8 URLs/URIs,
and I'm working on expanding this draft and filling in more details.
I'm quite confident that we are moving into the right direction
(but we could of course move faster), and that in due time, whether
or not URLs/URNs will formally be defined as ASCII-only will not
be of interest to users, because the user interface will make the
necessary conversions.


Regards,	Martin.