From: mitra@path.net (Mitra)
Subject: Re: Revision of Chris & Peter's URN paper
Message-Id: <CF6FGn.2Fw@pandora.sf.ca.us>
Date: Wed, 20 Oct 1993 03:38:47 GMT
Thanks for the revision Chris, sorry if I rehash stuff thats already
been decided, but we've been so many times around the block on this one
that I forget which way its ended up.
Chris Weider (clw@merit.edu) wrote:
: 3) (Major change) A fifth field has been added, specifying the encoding
: scheme used for the opaque string. It seems to me that it would be unwise to
: limit the potential character sets usable for the opaque string, particularly
: if we're planning for the future. However, we still have those pesky mailers
: to deal with... so I have defined one encoding scheme, ASCII encoded ASCII.
: While this may seem rather redundant, think about other possibilities such
: as ASCII encoded UNICODE, ASCII encoded binary checksums, etc.
Chris - lets think this through, while I'm open to arguments that
this is neccessary, I dont think that adding this fields has achieved
anything. If you dont at least know the encoding method of the string,
then how do you recognize "ASCII". If the Naming_Authority comes from
a fixed character set then its irrelevant there, so the only question
is the opaque string. The question is, whether this string is a binary
string - that is represented the same in different character encodings,
or its a string of letters represented in the appropriate way
for the encoding scheme. If the former then ASCII is meaningless, if
the latter then I would presume that you already have to know what
your character set is?
: 1) The fact that the naming authority identifier may be hierarchical in
: nature, and multi-leveled. Apparently this was not brought out enough in the
: previous draft as we kept getting questions about it.
The current draft specifies a single hierarchical level seperated
by a single colon which has to be there. I thought the proposal was
to make it fully hierarchical - in which case we should use a single
reservered, repeatable and non-":" character (e.g /)
: 3.3.2 The character set encoding code
See comment above
: 3.3.3 The naming authority scheme identifier
: ISBN_Publisher_ID
Cant we make this "ISBN" that's a horrible string
: 3.3.5 The Opaque String
: 1: A given opaque string should be case-insensitive (for compatibility
: with very old systems).
No way! Any application running on a machine that doesnt distinguish
upper and lower case is going to have to escape all characters they
dont handle anyway, this cannot be advisory, either two opaque strings
are compared with strcmp or strcasecmp, I dont care which, but it
has to be defined.
: 4: Setting up as a Naming Authority
: There are 2 scheme identifiers listed here; others will no doubt be suggested
: and added as this draft circulates. They are:
: IANA
: ISBN_Publisher_ID
: To set one's organization up as a Naming Authority, one can use the ISBN
: publisher ID one has been assigned, or one can apply for an Enterprise
: Number from the IANA (Internet Assigned Number Authority) if the organization
: does not already have one. The general syntax is listed in section 5.
Why require a seperate registration process with IANA, if the goal is for
lots of publishers then why not make the IANA scheme be for any registered
FQDN. Why require a single point of registration for tems of thousands
of machines. We already have a process for this.
: 5: Syntax
: Below is a BNF like description of the syntax of the URN. Spaces have
: been used here to separate components for readability, spaces are NOT ALLOWED
: in a syntactically correct URN unless they are escaped with the '\' character.
Why dream up a different escaping scheme than for URL's since urn's are
syntactically similar to URL's it would be really nice for clever
user-interfaces to handle being given either (like telnet handling domain
names and IP addresses) Those '\' characters, are themselves going to
have to be escaped to appear in anyplace a URL could. Also we put
spaces back into URLs. (While deprecating multiple spaces)
: xalpha a | b | c | d | e | f | g | h | i | j | k | l |
: m | n | o | p | q | r | s | t | u | v | w | x |
: y | z | A | B | C | D | E | F | G | H | I | J |
: K | L | M | N | O | P | Q | R | S | T | U | V |
: W | X | Y | Z | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 |
: 9 | 0 | - | _ | . | @
Please - lets not allow a different set than URL's the same logic applies
in both cases.
Thanks again for the draft
- Mitra