Message-Id: <9310192149.AA18105@tipper.oit.unc.edu>
To: "Chris Weider" <clw@merit.edu>
Subject: Re: Revision of Chris & Peter's URN paper
In-Reply-To: Your message of "Tue, 19 Oct 93 12:04:46 EDT."
<9310191604.AA06476@merit.edu>
Date: Tue, 19 Oct 93 17:49:31 -0400
From: Simon E Spero <ses@tipper.oit.unc.edu>
"Chris Weider" <clw@merit.edu> writes:
>Changes from earlier draft:
>
>1) The multiple colon syntax has been removed; individual fields are now
>separated by colons, with positional semantics indicating the individual
>fields and a 'colon-counting' parse technique.
At last! Something everybody agrees on :-)
>2) The characters < and > are use as delimiters for the URN. Unlike the
>URL, this is built into the syntax of the URN; I still feel there is a need
>for termination characters especially when these are going to be cut and
>pasted.
Again not too controversial, but I wonder if it would be a good idea to
have a small part of the meeting to go into bracketing issues. In particular,
I'm a little unsure about how bracketing interacts with opaque strings
that might contain brackets themselves (should they be escaped? Also,
most uses of URNs require them to be imbedded in other forms of URIs-
what are the bracket matching rules?
>
>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
I'm not 100% sure about this one; I kind of hear the faint echo of a
feeping creature. I'd feel a lot happier if we just treated URN bodies as
octet strings with a defined encoding rather than as characters per-se .
Does seem like a very useful aid to rendering, but I thought the fundamental
requirement for inclusion in the URN itself was that the feature could not
survive outside (i.e. naming schemes). We seem to have picked up a few
bits and pieces that aren't vital for URNs, but are really attributes of the
URN itself and not the named resource. For example, information about the
opaque string encoding, properties beyond equality (e.g. inequality,
self-resolving), adherence to a set of structuring conventions, etc, etc.
A lot of this is just stuff which was discussed for URNs, put punted in
the interests of simplicitly. There's a good case for adding a sister
specification (or possibly a sub-section of the URN spec). I suggest the
term Uniform Resource Number -Informationally Extended (URNIEs).
There's a good case for putting these things in the URC, but it's getting
close to the time when we have to stop saying that ..
>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.
Good - that's an important thing to point out. One thing that would be
very useful to have in this part of the draft is a set of suggested
separators to denote parts of the naming authority (and possibly the
opaque string). If we want to use whois++ style directory architectures to
handle caching and resource replication then having a simple way to decompose
URNs can improve efficiency by a few orders of magnitude. Since there's no
loss if such a scheme isn't followed, such a suggestion couldn't hurt. If
the worst comes to the worst, we could always stick such info in the URNIE.
>an indication of its use. I sent out a message about the dangers of placing
>comparative attributes (such as version number) in the URN itself; since I
>didn't get any response, I must assume that everyone agrees with me
>(wry grin)...
Moi? I don't recall that message, but you did convince me that unless
one has specific meta-data (either from knowledge about the naming-authority
or from an URNIE), the innards of an URN are sacrosanct.
>
Oh, one final point:
Can't we just call them ISBN? and shouldn't we add ISSNs?
Simon