Date: Wed, 26 Oct 1994 21:07:47 -0400
Message-Id: <199410270107.VAA03940@lysithea.lcs.mit.edu>
From: "Karen R. Sollins" <sollins@lcs.mit.edu>
To: nl@osf.org
In-Reply-To: <199410241854.OAA03368@postman.osf.org> (nl@osf.org)
Subject: Re: Current URN syntax is unacceptable
Cc: uri@bunyip.com
Date: Mon, 24 Oct 1994 14:53:38 -0400
From: "Norbert Leser - OSF DCE: (617)621-8715" <nl@osf.org>
... text omitted for brevity
I'm glad, that you have brought up this point again. This is still an
contentious area that is more than fuzzy, but we need a solution in order
to make progress. After having brought up some issues surrounding the previous
"Functional Requirements for URNs" draft, it is my understanding that
The URN functional requirements document is just that. The group
reached consensus that it was important to separate the discussion and
documentation of requirements for specifications from the
specifications themselves. The requirements provide the metric by
which one can evaluate a particular proposed scheme in order to accept
or reject it.
1. there is no "common URI syntax" other than the generic format
in the form of
[scheme id tag] : [opaque string]
Thus, the requirements document does not specify a common or any other
syntax. In fact, what was said about syntax was agreed to be the
minimum needed. It is the specfication that needs to be complete.
2. the syntactical definitions specified are for URL schemes such
as http and ftp, for locators and not for names and identifiers;
Of course not. That will appear in the specifications document which
hopefully the group will produce in the near future and which will
have to meet the requirements of the requirements document.
3. the URN requirements document identifies a few encoding requirements
that (though debatable) don't directly impose a specific syntax,
permitted character sets, etc. It specifically says:
"... there is not yet consensus on what the limit might be."
Yes, again, these are only those that it was deemed to put into a
requirements document, but the minimum.
...text omitted for brevity
- The opaque string is interpreted by its respective naming authority
only. URN doesn't impose any encoding restrictions other than those
required by the underlying (transport) protocols.
Any registered naming authority specifies the encoding rules for
these opaque strings. This includes the possible insertion of
multiple and hierarchical sub-naming authorities, the ordering
of multiple atomic names (in hierarchical naming systems, for
instance), the delimiters used for sequences of atomic names,
and other naming system specific properties.
The whole point of the strings being opaque is that they should *NOT*
be interpreted by anyone. They should simply be translated into
addresses or perhaps other opaque strings. If they are interpreted
then I must take that to mean that semantics have been embedded in
them and over a long period of time, that is a bad idea. These are
supposed to be valid for the lifetime of an object. That may mean one
or hundreds of years. For a mutable object almost any semantics can
and might change during such a time period and if anyone or anything
comes to depend on semantics being relevant in a name, it becomes
frustratingly useless when those semantics are invalidated. So, I
strongly urge, if one is planning to do something that will
survive into the future, that the names have no semantics that are
meaningful and might be considered interpretable and therefore whose
validity must be maintained.
Any semantics that are needed will appear in meta-information or other
higher level, user friendly, probably context sensitive naming.
For the purpose of simple name comparison only, instances (such as
client interpreters) that don't have the naming authority's knowledge,
case matching is insensitive and white spaces are not significant.
If you go back to the mail archives and minutes of previous meetings
you should learn that the reason that we reached a conclusion that
simple comparison of names should be a requirement was that one could
not depend on going back to the naming authority or even knowing the
algorithm for generating URNs and in fact it shouldn't be necessary
to. That naming authority (dispenser of names) may no longer be in
business and in fact its algorithms may be forgotten, but that
shouldn't make the names it assigned invalid and lacking in utility.
This can only be true if both comparison and resolution are
independent of assignment. Hence several of the requirements one
finds in the requirements doc.
Now you can go further and define syntactical rules for the opaque string for
already registered naming authorities, such as "dns" or "isbn". I wouldn't
mind having these in separate subsections of the URN draft; but these
have to be separate and distinct from the generic URN "Syntax" section!
A particular scheme could do this and it could be compliant with the
URN requirments document, but I recommend against it, unless these are
only presented as examples with a scheme for how new ones can be
added. The moment there is a new popular one that has not been
included in a restrictive specification, the spec becomes out of date
and needs revision and updating. This means that a working group
needs to exist or come into existence for such a purpose - not a good
idea. Building in extensibility (with controls) seems like a good
idea to me.
...text remainder omitted for brevity.
Karen Sollins