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

["Sam X. Sun" <[e-mail]>]

Hi, Leslie,

First of all, thanks for taking the time answering my questions. 

I do see quite some confusions caused by my inappropriate wording. And I
would like to address them in a line-by-line fashion as follows:


----------
> From: Leslie Daigle <[e-mail]>
> To: Sam X. Sun <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
> Date: Wednesday, December 03, 1997 11:32 PM
> 
> 
> 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.

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

Again, thanks for considering my questions.

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

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

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

There are really two issues I want to address here:

1. To clarify my concept: What is the definition of URN addressed by this
working group. 
Is it a particular name space defined under "urn:", or the entire URN
framework defined by RFC1737? 

You have sort of answered my question on this. But there are aspects I may
not really understand or agree, which I would address later, corresponding
to your individual responses.

2. As you are aware, we have proposed a handle system draft that defines a
syntax, that has quite some difference to the "urn:" syntax proposed in the
"draft-ietf-urn-syntax-05.txt". And I would very much like to take the
opportunity to present it to the working group, and hope to get feedbacks
on areas that it is not appropriate. 

If I understand the working group charter correctly, we are not limited to
define just one name space, or just one resolution system. And we very much
consider Handle System as another implementation under of URN framework as
defined by RFC1737. I hope there's nothing wrong on this.

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

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

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

You conclusion here distinguished "the way to do persistent identification"
from the "urn:" name space defined by the working group. But it didn't
answer my question whether the "urn:" name space defined by the working
group is considered (at least by the working group) the only name space
allowed for URN framework as defined by RFC1737.

If so, I argue that this might not be appropriate. While "urn:" syntax has
many good features, it could also have limitations as well. (Of course,
whether it's a limitation or not is subject to the individual, and it could
very well be my own perspective as one user of the syntax.) For technical
or practical reasons, other URI (seems like I have to user URI, but not
URL?) name spaces like "pdi:" or "hdl:" may serve better in their own
perspective, but could be all under the URN framework defined by RFC1737.

The "_uniformity_ of naming" can be well achieved within the name space
defined under "urn:" syntax. But does it have to be the only name space as
defined by RFC1737? Somehow I fell that I might have missed some important
point here. If that's the case, please advise.

^---------------------------------------------------------

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

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

Thanks for the correction. I would correct it as "URI", instead of "URL".

^---------------------------------------

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

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

This is where my confusions are. When you say "have nothing to do with
URNs", do you mean the URN name space defined by the "urn:" syntax? Or the
URN framework defined by RFC1737?

^-----------------------------------------------------------------

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

-----------------------------------------------------
God excuses me for my inappropriate wording. (I really wish I had paid my
attention to English earlier.) Anyway, as I addressed in the earlier
response to Ron, the "implementation" should really be spelled as "syntax
definition". 

These is no argument "to provide … one way of structuring identifiers …".
The question is, is this considered the only way for the URN framework
defined by RFC1737?

You might ask why I'm so interesting in the exacting working here. And I
would like to take the example in the case of "URL". Here the "URL" take
the sense of "Universal Resource Location", not "Universal Resource
Locator" (otherwise why can't we call "urn:" a URL scheme?).

Under "Universal Resource Location", we have "http", "telnet", "mailto",
etc. Each address resource by "location", but have different syntax to
serve their perspective purpose. If "Universal Resource Location" can allow
different syntax, why "Universal Resource Name" could not?

^---------------------------------------------------

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

--------------------------------------------------------
Again, my inappropriate wording caused the confusion! Two points though:

1.	Limiting "Universal Resource Name" to only one particular syntax does
limit its implementations to whatever the syntax's limitations are. No
matter how many different implementations for that syntax may exist.

2.	The concept that "the handle system is entirely based on proprietary
servers and client plugins" is not correct. Handle System is developed by
CNRI as a prototype implementation following the URN framework as defined
by RFC1737. It's our very intention to have its syntax, protocol, and API
defined as an open standard. The handle system and syntax draft is the
first step towards this direction. Handle System is designed and developed
for general public service to address issues of IIIA as mentioned in
RFC1737. We provide servers to assist the deployment of the prototype, and
give away the plugins to allow people play with the concept. The protocol
and APIs are public available, and nothing prevent people developing their
own server, or building their own client or plugin. The current license
agreement to restrict setting up global handle server is more of a
deployment issue, and should have nothing to do with "proprietary" or not.

^-------------------------------------------------------


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

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

I don't agree that "http:" and "telnet:" have the same syntax. 

What do you mean by "one single syntactic structure (implementation)"? 

^---------------------------

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

-----------------------------------------
"The broader sense" is my understand of the URN framework as defined in
RFC1737.

Specifically, there is a NCSA report last year, which did a evaluation of
URN implementations. The candidates in the evaluation include WHOIS++, DNS
based URN, and the Handle System. The URL for the evaluation is at:

http://www.ncsa.uiuc.edu/InformationServers/Horizon/URN/design.html

Some of the comments on that document is somewhat out of date, and I have
to admit that the paper addressed Handle in terms of "urn:hdl:", but what
makes it qualify as URN in terms of "urn:hdl:", and disqualifies it under
the syntax "hdl:"? 

If the syntax is the reason, then we are talking about "urn:" is the only
name space qualified for the URN framework as defined in RFC1737.

^---------------------------------------

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

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

Again, my broader sense of URN is my understanding of URN framework as
defined in RFC1737. I hope I have expressed myself clearly on why I think
URN framework should not be considered to be equivalent to the name space
as defined by "urn" syntax. Someone could very well prove me wrong though.
But I would like to hear the reasons.

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

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

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

And we could very well be defining more than one solution, couldn't we?

^----------------------------------------------


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

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

This is the conclusion I got from my earlier question to the mailing list.
You can find it in the mailing list archive. I hate to make reference to
the archive, but it seems I have to. Thus I give you the URL for the
archive here, and it happens to be the first message. The URL is:

ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive/urn-ietf.archive.971
1

^-----------------------------------------


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

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

I might have misunderstood the author here. 

The "URN Architecture" draft (draft-ietf-urn-req-frame-04.txt) mentioned
that: 

'Furthermore, the group decided that these "names" were generally to be for
machine, rather than human, consumption.'; 

and later added:

"In contrast to URNs, one can imagine a variety human-friendly naming(HFN)
schemes supporting different suites of applications and user communities.'.



^--------------------------------------------

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

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

I totally agree with you that there might never be a resolution that
satisfies everyone. And every syntax/implementations may have their
advantage and disadvantage.

There is one thing I do want to point out here, though. Allowing
human-friendly naming(HFN) in ASCII ONLY is not equivalent to allowing HFN
in the global scope. You and I might think ASCII name is friendly enough.
But for people not speaking English, they might not understand "FRIENDLY"
as it is spelled in ASCII. Furthermore, requiring non-ASCII characters to
be hex encoded definitely makes it look unfriendly to anyone. But this is
from the native language viewing point of view. 

The advantage of limiting to US-ASCII is from a easy-ness of keyboard input
point of view, and that is the issue I struggled a lot on designing the
Handle System syntax, which would like to allow any native characters. And
the conclusion I reached is that, until a global input method is defined
someday (let's hope it will happen someday), for native Handle names with
an international scope, it is suggested to provide a US-ASCII alias for it.
I hope it's not too naive of a proposal, but still want to hear anyone's
criticism. For interested people, I have a paper submitted to the UNICODE
conference for evaluation, which tries to address this issue a little
better. And I would like to hear anyone's comment on it.

This may not be in the charter, but might worth to mention…

 ^------------------------------------

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

-----------------------------
Can not agree more…
------------------------------

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

---------------------------------
As I explained earlier, there are two issues:

First of all, the charter says: 

"This WG will define the framework for URNs, at least one resolution
registry system, and at least one namespace".

And I see nothing wrong with proposing another name space, if I understand
what the word "name space" stands for.


Secondly, the question I raised is a conceptual one. As I said, I might
have missed the point. If so, please advise.

^--------------------------------

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

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

Could anyone point me the draft, or the author? Thanks.

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

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

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

Thank you for addressing all my questions so thoroughly! It has cleared a
lot of things I was in doubt. But, as I have put it in this lengthy
response, there are still some areas I'd like to get addressed more
clearly. And I hope you, or anyone in the working group could provide the
answer to me.

Thanks everyone for your patience...

Sam
[e-mail]