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

[Leslie Daigle <[e-mail]>]

Sam,

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 happy to entertain discussions re. the timeliness of wrapping up
the working group.  I want it to be clear that I'm proposing that we
should wrap the group because I believe we are near to finishing the work
on our charter; I certainly don't want to curtail efforts where issues
are left outstanding.

However,  I need to hear specific examples of how the documents proposed
by the WG are at odds with or otherwise fail to fulfill our charter. 

I'm still trying to get an understanding of your exact _point_ in your
questions;  the clearest interpretation I can put on them is that you 
think the work of this group can't be considered done until it somehow
acknowledges/embraces/includes the handles system.

If that _isn't_ what you were getting at, please clarify.

I will address your questions from the assumption that it _is_ what you
are getting at, and am gently work towards the following conclusion:

	This working group was chartered to develop a framework
	for Uniform Resource Names.  The premise is that there is
	no single approach that works for all Internet applications
	requiring persistent identifiers (publishers AND protocol
	designers alike), therefore we sought a mechanism that
	would provide the _uniformity_ of naming accessible to
	all Internet applications.  There is an engineering _need_
	here, and we're proposing _a_ solution to it, within
	certain parameters (i.e., our charter) and _without_
	claiming that this is the only way to do persistend
	identification.

	None of this precludes the standardization of the handles
	system, nor does it in any way address the strengths and
	weaknesses of the handles system as a mechanism for
	persistent resource identification.  Neither work need
	impede the other.

Now, for the detailed response:

> 1.	What is the definition for URN addressed by the working group? Are we
> defining it as a particular implementation limited to "urn:" URL scheme, or
> a specification that should embrace all persistent, location independent
> global naming scheme? 

First of all, "urn:" is not a URL scheme  -- that's an error in your
terminology, and should also be removed from your draft (section 9).

I assume you misunderstood the e-mail exchange of a few weeks ago, which
included a discussion of whether "urn:" should be registered in a UR_I_
registry, if the URL registration process was so re-cast.

The URN framework as proposed by this WG aims to provide the Internet
develoment community with a _uniform_ structure of persistent, location
independent identifiers.  Just as there are many "locators" that are
not URLs, there will be some persistent identifiers that have nothing
to do with URNs (whatever your definition of "embrace").


> 	The current URN specification seems to limit the URN into a particular URL
> scheme, eg. "urn:", which is really just one way of implementing
> persistent, location independent, universal resource names. URN in a
> broader sense should not confuse its specification with any particular
> implementation. 

Which level of implementation do you mean?  Structure of the identifier?
Semantics of the identifier?  Underlying resolution systems?

>From an engineering standpoint, we _have_ to provide the development
community with one way of structuring identifiers and interpreting them, 
otherwise they will not be uniform.

As for underlying resolution systems -- Ron has already pointed out that
URNs are not relying  on a single resolution implementation.  I can't
believe that was your point, though -- that would be a case of the pot
calling the kettle black, in that the handles system is entirely 
based on proprietary servers and client plugins for 2 browser (I don't
care if you _are_ giving the client plugins away).

> 	For example, URL as a specification for locating WWW resources, it
> embraces various implementations defined under their corresponding URL
> schemes, including, but not limited to, "http:", "ftp:", and even "urn:".

Yes, and they are all within one single syntactic structure (implementation!)
and locators that aren't mapped to that structure aren't considered
URLs.  A hostname, while resolvable to an IP address, is a locator but
not a URL.

> Handle System is another implementation of persistent, location independent
> global naming scheme. It utilized URL scheme "hdl:" in the WWW context, and
> is considered an implementation of URN in the broader sense.

This is phrased rather speciously, as you haven't defined by _whom_ it
is so considered, nor have you truly defined "the broader sense".

You have given some vague notion that "the broader sense" is that anything
that can identify things should be considered a URN in the broader sense,
and that's not an implementable solution.

> 	It seems URI is the URN in the broader sense. But the recent URI draft
> (draft-fielding-uri-syntax-01.txt) defines URN as "the subset of URI that
> are intended to remain globally unique and persistent even when the
> resource ceases to exist or becomes unavailable". This makes it more nature
> of thinking URN, as addressed by the working group, is by no means limited
> to a particular implementation.

It means that the author of the URI document was defining the context
in which other people (i.e., the URN working group) will define the 
solution.
 
> 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.

I don't see the section in the URI draft that says that characters are
excluded/reserved on a URI scheme basis.  Please cite a specific example
of a character that is reserved/excluded in the URN syntax that 
would be allowed in a URL scheme per the URI draft, and cite the specific
part of the URI draft that says this is permissible.

> 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. 

Which "URN specifications"? Do you mean the RFCs that have been published?
If so, please cite the documents and sections that specifically say
"user friendly names are excluded" so that we can fix the wording.

>From the URN WG charter:

| Although the framework will allow URNs to be defined that vary in terms of
| degree of scalability and persistance, ensuring "user friendliness" of all
| resultant identifiers is beyond the scope of this group.

I.e., we don't _guarantee_ user-friendliness, but we don't actively
look to prevent it.  The reasoning behind that was that it would be
impossible to come up with a single approach that would satisfy everyone's
definition of "user friendly" naming.  You've given your definition of it;
I could say that my definition of user friendly names is strictly US-ASCII
because those are the characters that I can generate reliably from the
largest number of keyboards in the world and can transmit across 
the greatest variety of data interchange mechanisms.  We can both
come up with compelling arguments either way, and  we'll never get the
resolution that satisfies us.

So, it's specifically not in the charter.

To sum up, then, what this WG is doing is defining _a_ uniform mechanism
for persistent, location-independent identifiers in order to fulfill our
charter, just as URLs defined _a_ way to structure Internet locator
identifiers.    They could have been structured differently, but for
uniformity, _one_ way was needed.

That the URN approach is different than the paths you've selected with
handles doesn't make either of these systems "wrong".  We've previously
discussed how handles can be used as a URN namespace, even gatewaying
directly into the handles resolution structure.

If you have a problem with the charter, and that it doesn't include
handles, that's an issue you'll have to take up with the Area Directors
as well.  They've always seemed interested in finding _a_ solution
to the problem, rather than continuously studying the full range of
potentially inexhaustable implementations.

> Most of this issues seems already been discussed in the mailing list. It
> would be more helpful if they can be addressed in a formal document,
> INCLUDING the reasoning behind their perspective conclusions. Digging into

This is true, and it has been on The List of THings to Do.  Dirk even
made a draft of it at some point... 

> the huge mailing list archives is good for background checking, but appears
> to be hard for coming up a conclusive answer (By the way: could the archive
> be threaded by topic, like in the newsgroup?).

FWIW, the IETF requires that an ftp archive be kept.  _Additionally_, it
is possible to set up such a threaded archive; we had one at one point
and I'm willing to accept volunteers to set up another one.

Thanks!
Leslie.

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  [phone]
                      -- ThinkingCat              [e-mail]
----------------------------------------------------------------------------