Subject: Re: [URN] Re: URI documents
From: Patrik Faltstrom <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Date: Sun, 28 Dec 1997 13:53:20 +0100 (MET)

On Sun, 28 Dec 1997, Larry Masinter wrote:

> > Now, you simplify this by saying that syntactically, a URN can be parsed
> > the same way as a URL, and one can install in the software a URN parser
> > just like one does install a handler for a HTTP scheme or mailto scheme.
> > 
> > Well, a lot of people probably do agree with you that that is the way one
> > can _implement_ URLs and URNs, but that is not the way things are defined.
> 
> ....
> 
> The question is: do you think that is the way things SHOULD BE defined?
> I"m guessing that's really what this is about. SHOULD we allow URZs to
> have different rules than URLs and still call them the same protocol element?

This is exactly why we need a URI syntax paper, and a separate URL and URN
one. Everything that fulfils the basic requirements of a URI paper should
be able to be a URZ or whatever. They should not have to fulfil everything
that are URL requirements.

If the URZ designers are smart (and the IETF process should stop them
otherwise) they _inherit_ things from the URL and URN papers so URZ are as
little different from URLs and URNs as possible. One example is that '#'
is a special character in the URN syntax, inherited from the URI RFC 1730
(or whatever it was...), but also because IF '#' was allowed as a
non-quoted character in a URN, it would break so many implementations.

Anyway, from my point of view, there is a big difference making URZs
compliant to a URI syntax paper -- and then _inheriting_ necessary and
interesting parts from the URL and URN syntax papers, from making URZs
using some "mays" from a common URI/URL syntax document. Say that in URZs
one need (for some reasons) have the query portion specified differently
than in URLs (that's why they are URZs...)? Should that not be allowed?

   Patrik

Date: Sun, 28 Dec 1997 13:43:21 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: Larry Masinter <[email-masked]>
cc: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Sun, 28 Dec 1997, Larry Masinter wrote:

> > What some of us
> > ask for are your document divided in three so it is crystal clear what is
> > a definition for URIs, what is URLs and what is URNs. 
> 
> The proposal (c) divides (b) into two, not into three. I'm
> guessing you really meant "two".

Well, we do have a document which talks about the syntax for URNs aswell.
I.e. yes, it is true that (c) splits the document on the table in two, but
the result will be three documents.

> In an earlier message, it sounds like you are saying that you have
> reviewed (b) (draft-fielding-uri-syntax) and (c) (Leslie's two-documents),
> and that "(c) is the only working solution". Do you mean to say
> that you also have found (a) and (d) unacceptable?

Yes.

What I mean is that I think that draft-fielding-uri-syntax should be split
into two, and as arguments for that I did read the original document --
and then Leslies suggestion on how a split should be done.

> Do you find it less, or more confusing, to have both: 
>
> >    Many URL schemes have been defined.  The scheme defines the
> >    space of the URL, and thus may further restrict the syntax and
> >    semantics of identifiers using that scheme.
> 
> in the URL document, and also
> 
> >   Many URI schemes have been defined.  The scheme defines the
> >   namespace of the URI, and thus may further restrict the syntax and
> >   semantics of identifiers using that scheme.
> 
> in the URI document?

If we just decide that a cut and creation of two documents makes the final
result better, we can then work on the details. I think there are things
in Leslies cut which did not make 100% sense, mostly (I guess) because
text should be rewritten (like the above) when we have two documents.

As it is now -- I do only argue for a separate document about URI syntax
from one about URL syntax.

I think Leslies suggestion did show that two documents were better. I can,
if we go down that path, come with perticular suggestions what should be
better in those.

I think for example that some "may" in the URL document should be "must".

> > This is needed because the document currently under the name of a URI
> > syntax document talk so much about URLs, and use a terminology that is
> > only valid for URLs, that confusion occurs regarding, if nothing else, the
> > difference between a URL and a URN. It does not help that the document
> > have "may" all over the place.
> 
> Can you say what the 'confusion' is? There's a section 1.2 URI, URL, and URN,
> which attempts to discuss the difference.  Is this confusion also in
> place for (d) or (a)?

The confusion is when there are so many parts that talk about (today)
URL-specific things as URI-things, but with a "may". One example is
relative URLs, which I think should be described as relative URLs, and not
relative URIs. The same thing about fragments, and details on how to
construct and parse query/username etc constructions. It sounds like if
these things -- even though they are preceded with a "may" -- should apply
to all URIs, and more specifically to the _design_ of a URZ, URB, URX or
whatever.

> > I think it is definitely better if we have documents about URIs, URNs and
> > URLs, so the number of "may" can be limited to a minimum when we talk
> > about so important things as grammars and what characters are allowed, how
> > encoding is done and how to handle/accept things like fragments, queries
> > and relative addressing.
> 
> There are no fewer "may"s in the combined (c) than there are in (b).

Well, I think they might be able to be fewer. I might be wrong. I would
like to say that _IF_ certain functionality should be able to be applied
to a URL scheme, it _MUST_ syntactically be written in a certain way. That
rule might not be possible to create if we also include URNs -- because
the URN namespace itself might have rules and constructions which makes
that rule not appliable.

Also, because a URN and a URL are different things (as a URN can be used
in a number of ways, N2Ls, N2L, N2C,...) they are also used differently --
and certain operations one can apply to a URL can not be applied to a URN
and vice versa.

> As far as I can tell, there is no proposal to have a different
> set of allowed characters in "URI" than in "URL", so I'm not sure 
> waht you mean by "what characters are allowed". Also, I don't see
> any proposals to have a different mechanism for encoding for URNs
> and URLs. Are you suggesting there might be such a thing?

This is from a discussion I had with the Handle people, which didn't
understand why we when talking about URNs did say that the character set
in use should be UTF-8 encoded UNICODE 2.0, when so many different
character sets did work when using HTTP URLs. Well, this is because when
getting a URL, you normally (there are exceptions of course) get them in a
HTML document as a reference. That reference is then, as-is, passed back
to the same server as the one that did pass the reference to the client,
so noone have to parse the stream of bytes passed back and fourth over the
wire. The URL, if displayed on the screen in the clients browser, might
look funny, or like garbage, but it will work. This as long as the client
doesn't change the stream of bytes.

But, when talking about URNs, the URN will be inside some document, say a
HTML one. That URN will _NOT_ be passed to the same HTTP server, but to
some resolver (in the case of a N2L resolution) which must understand what
characters are represented in the name-space-specific string, so a search
can be done, which in turn will result in the URL which is sent back to
the client. That URL is then what the browser in this example sends back
to the HTTP server to get the next HTML page.

As you can see in this example, we have when using URNs a third party
involved -- or at least some function which acts as a resolver which in
this simple example turns the URN into a URL which is then used as normal.

Because of that -- it is definitely needed when talking about URNs to
agree on what character set and encoding is used, as the parties involved
have to be able to parse the characters (not the bytes) sent in the URN.

> I agree that the query forms are unlikely to apply to URNs, that relative
> addressing is problematic, and that fragments are controversial, but your
> message indicated that you belive there are more extensive differences
> that are not just restrictions, which would be a much more serious issue.

All of these issues you rise are things that we know how to handle in the
case of a URL, and character set issues are things we know when talking
about URNs. We do though not know in detail how things like relative
addressing, fragments, query forms etc etc should, if ever, applicable to
URNs, so I rather have one document for URIs, one for URLs and a third for
URNs.

It does just make so much more sense -- especially when the URLs and URNs
are so different regarding usage. I.e. many things are more mature when
talking about URLs. I do not say that the URN people (including me) should
invent their own way of handling things different than URLs. That would
be stupid. Totally stupid. I just say that some things might NOT apply to
URNs, only to URLs. Who knows if they will apply to URXs? So, let write
about URLs in one document and URNs in one.

I also think it is a good idea to talk about things like how to implement
a parser for URLs that also handle URNs and URXs, like what Roy has done,
but that is something different than talking about the syntax for each one
of the constructs. That is a BCP which might also be needed.

   Patrik

Date: Sun, 28 Dec 1997 00:53:29 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Patrik Faltstrom <[email-masked]>
CC: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I just want to pick up on one more thing:

> Now, you simplify this by saying that syntactically, a URN can be parsed
> the same way as a URL, and one can install in the software a URN parser
> just like one does install a handler for a HTTP scheme or mailto scheme.
> 
> Well, a lot of people probably do agree with you that that is the way one
> can _implement_ URLs and URNs, but that is not the way things are defined.

....

The question is: do you think that is the way things SHOULD BE defined?
I"m guessing that's really what this is about. SHOULD we allow URZs to
have different rules than URLs and still call them the same protocol element?

Date: Sun, 28 Dec 1997 00:45:54 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Patrik Faltstrom <[email-masked]>
CC: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> What some of us
> ask for are your document divided in three so it is crystal clear what is
> a definition for URIs, what is URLs and what is URNs. 

The proposal (c) divides (b) into two, not into three. I'm
guessing you really meant "two".

And the question is whether (c) actually makes it "crystal clear"
what is a definition for URIs, what is URLs and what is URNs. I think
we all want the definitions to be "clear", but it is exactly the clarity
of these documents that we're discussing.

In an earlier message, it sounds like you are saying that you have
reviewed (b) (draft-fielding-uri-syntax) and (c) (Leslie's two-documents),
and that "(c) is the only working solution". Do you mean to say
that you also have found (a) and (d) unacceptable?

Do you find it less, or more confusing, to have both:

>    Many URL schemes have been defined.  The scheme defines the
>    space of the URL, and thus may further restrict the syntax and
>    semantics of identifiers using that scheme.

in the URL document, and also

>   Many URI schemes have been defined.  The scheme defines the
>   namespace of the URI, and thus may further restrict the syntax and
>   semantics of identifiers using that scheme.

in the URI document?

> This is needed because the document currently under the name of a URI
> syntax document talk so much about URLs, and use a terminology that is
> only valid for URLs, that confusion occurs regarding, if nothing else, the
> difference between a URL and a URN. It does not help that the document
> have "may" all over the place.

Can you say what the 'confusion' is? There's a section 1.2 URI, URL, and URN,
which attempts to discuss the difference.  Is this confusion also in
place for (d) or (a)?

> I think it is definitely better if we have documents about URIs, URNs and
> URLs, so the number of "may" can be limited to a minimum when we talk
> about so important things as grammars and what characters are allowed, how
> encoding is done and how to handle/accept things like fragments, queries
> and relative addressing.

There are no fewer "may"s in the combined (c) than there are in (b).

As far as I can tell, there is no proposal to have a different
set of allowed characters in "URI" than in "URL", so I'm not sure 
waht you mean by "what characters are allowed". Also, I don't see
any proposals to have a different mechanism for encoding for URNs
and URLs. Are you suggesting there might be such a thing?

I agree that the query forms are unlikely to apply to URNs, that relative
addressing is problematic, and that fragments are controversial, but your
message indicated that you belive there are more extensive differences
that are not just restrictions, which would be a much more serious issue.

Larry
-- 
http://www.parc.xerox.com/masinter

Date: Sat, 27 Dec 1997 22:45:15 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Patrik Faltstrom <[email-masked]>
CC: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I've been wondering if we might progress with a different
perspective, which I will lay out briefly:

The term "URI" denotes a concept: some kind of uniform
space of identifiers for resources. The terms "URL", and "URN",
however, denote explicit protocol elements, with specific
syntax and semantics associated with that syntax. The URL
syntax is well defined and widely implemented; the URN syntax
is newer, but well underway.

It is possible, and convenient, to allow for mutual embedding
of these protocol elements. That is, the space of URNs can
be embedded in the space of URLs by prepending the URN with
the string "urn:". This means that "all URNs are URLs" only
in the trivial sense that it is possible to write a URN as
a URL. The simple embedding is possible because the URN syntax
was chosen (wisely) to fit within the URL syntax.

Conversely, one could imagine embedding the URL name space
in the URN space. Imagine, for example, a URN which consisted
of a date and a URL. The resource named would be 'the
resource that was available at the specified location
at the specified time. This would be perfectly good URN;
perhaps one could say that 'dated-url' was the naming authority,
and write <durl:199712272238:http://www.parc.xerox.com/masinter>.
as the undecorated URN.

With this notion of 'URI is a concept', we don't need or want
a general URI syntax. There's a URL syntax and a URN syntax.
There might be a completely separate URC syntax at some point.
While it is convenient to embed URNs into the URL name space,
it is just an embedding; the semantics associated with URLs
are not inherited by URNs than they are inherited by email
addresses merely because there is a 'mailto:' URL scheme.

Larry

-- 
http://www.parc.xerox.com/masinter

Date: Sun, 28 Dec 1997 06:52:19 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents 
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Sat, 27 Dec 1997, Roy T. Fielding wrote:

> >I agree with the above. (c) is the only working solution.
> 
> Almost all example URIs are URLs.  There is no way I could talk about
> anything more without defining URN technology, which I preferred to do
> by reference to the relevant URN RFC.  You can't have it both ways.
> All of the requirements, and even all of the "may", do apply to URNs.
> They simply have no impact when they are applied.

This is why most of your text works best in a URL definition paper.

> As we've said a hundred times already, the point of this exercise is
> to define what a parser must do when it is presented with a URI reference,
> before it even knows whether the URI is a URL or a URN.  That is because
> all scheme-specific parsing takes place within the scheme-handler and
> not within the part of the application that deals with URI references.
> The purpose of the document is NOT to describe the intersection between
> URL and URN -- that would be a total waste of time, since by the time
> you know whether it is a URL or URN you are in a different parsing
> situation which is scheme-specific.

Once upon a time, in Houston, we had a vote(!) in the URI working group if
the string "url", the URI scheme "URI", should be included in the syntax
of a URI. It was a close cut, but the majority voted for not including the
string "url:" in the URL. Several people left the room in protest...and it
was not fun at all.

It _might_ be the case that a URN should be parsed differently than a URL.
It might be that a totally new UR* should be parsed even differently than
a URN and a URL. I agree with you that a design like that might be stupid,
but the fact is that you do have some small common syntactic rules for
URNs and URLs, and that is how you find which one it is. A URN is simple
to recognise as it is prepended with the "urn:" string, but a URN is
harder because the URL scheme is syntactically written in the position
where the URI scheme should be. A parser must because of that have a list
of all known URL schemes, and if the URI scheme is one of those, the
identifier is a URL.

Now, you simplify this by saying that syntactically, a URN can be parsed
the same way as a URL, and one can install in the software a URN parser
just like one does install a handler for a HTTP scheme or mailto scheme.

Well, a lot of people probably do agree with you that that is the way one
can _implement_ URLs and URNs, but that is not the way things are defined.
What do we do when we get URZs which _doesn't_ have "URZ" prepended, but
have the URZ scheme immediately in the beginning of the string, just like
URLs? What happens if the market start writing URNs without the string
"urn:" in the beginning of the string, and instead only write "isbn:" (you
write in your document about the "side of the bus problem" regarding the
fact that HTTP URLs loose their "http://" part)? Is "isbn" now a scheme?
Yes, in the implementation it might be when you parse the string, but it
is still a URN, and not a URL.

We have today two different types of URIs; URLs and URNs. What some of us
ask for are your document divided in three so it is crystal clear what is
a definition for URIs, what is URLs and what is URNs. I simply don't
understand why you are opposing that so much?

It will be much simpler to have the documents updated, and each one of the
documents will be much simpler to read and understand, than having URL and
URN implications in the URI definition part and vice versa.

   Patrik

To: Patrik Faltstrom <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents 
Date: Sat, 27 Dec 1997 13:05:58 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

>I agree with the above. (c) is the only working solution.

(c) does not correspond to any implementation that I know of, and
contradicts the implementations of most URI-enabled applications.
You can prove this for yourself by using a URN proxy and attempting
to include "#something" in the reference.  You will find that the
"#something" is stripped before being sent to the proxy, and therefore
cannot be part of the URN because it is the fragment.

>This is needed because the document currently under the name of a URI
>syntax document talk so much about URLs, and use a terminology that is
>only valid for URLs, that confusion occurs regarding, if nothing else, the
>difference between a URL and a URN. It does not help that the document
>have "may" all over the place.

Almost all example URIs are URLs.  There is no way I could talk about
anything more without defining URN technology, which I preferred to do
by reference to the relevant URN RFC.  You can't have it both ways.
All of the requirements, and even all of the "may", do apply to URNs.
They simply have no impact when they are applied.

As we've said a hundred times already, the point of this exercise is
to define what a parser must do when it is presented with a URI reference,
before it even knows whether the URI is a URL or a URN.  That is because
all scheme-specific parsing takes place within the scheme-handler and
not within the part of the application that deals with URI references.
The purpose of the document is NOT to describe the intersection between
URL and URN -- that would be a total waste of time, since by the time
you know whether it is a URL or URN you are in a different parsing
situation which is scheme-specific.

....Roy

Date: Sat, 27 Dec 1997 20:00:06 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: "John C. Mallery" <[email-masked]>
cc: Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Thu, 25 Dec 1997, John C. Mallery wrote:

> Hi Larry,
> 
> Just to be clear, I choose C.
> 
> C Separate documents for URLs, URIs, and URNs.
> 
> Meaning that:
> 
> Documents a, b, d are unacceptable.

I agree with the above. (c) is the only working solution.

This is needed because the document currently under the name of a URI
syntax document talk so much about URLs, and use a terminology that is
only valid for URLs, that confusion occurs regarding, if nothing else, the
difference between a URL and a URN. It does not help that the document
have "may" all over the place.

I think it is definitely better if we have documents about URIs, URNs and
URLs, so the number of "may" can be limited to a minimum when we talk
about so important things as grammars and what characters are allowed, how
encoding is done and how to handle/accept things like fragments, queries
and relative addressing.

Personally I have not read the URI syntax document until I, as a member of
the URN working group, was told about the URL syntax document turning into
a URI syntax document during the IETF in Washington, DC. Leslie, as the
chair of the working group, promised to talk to the authors, the area
directors and Larry as the chair of the HTTP group, about the problems we
in the URN working group saw with the intention of the document changed,
and because of that I have not said anything until now. 

I have now reread draft-fielding-uri-syntax-01.txt aswell as Leslies two
proposed documents, to test the thesis I have that (c) is the best choice,
and I must say that it is.

   Patrik

To: Harald Tveit Alvestrand <[email-masked]>
cc: Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: URI documents 
Date: Fri, 26 Dec 1997 23:51:12 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

>To me in my AD position, the parameters of a solution are:
>
>- The solution must document the overall concept that embraces all the
>  identifiers of this class, commonly called "URI". (This rules out a)
>- The solution must not invalidate current UR* schemes, including URNs.
>- The solution should not needlessly complicate or constrain future UR*
>  schemes
>
>All I can say is - I hope we find a solution.

I claim that <draft-fielding-uri-syntax-01.txt> meets all of those
parameters, and does so in a way that can be demonstrated by current
practice.  The only thing I *would* change at this point is how scheme
prefixes are treated by the relative parsing algorithm (to better match
what has been implemented), but that has nothing to do with the URN
discussion.

....Roy

To: Leslie Daigle <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: URI documents 
Date: Fri, 26 Dec 1997 23:41:42 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

>You currently have your name on an Internet-Draft document that says
>it is a URI syntax document.  To date, you have personally rejected
>100% of the URN WG chairs' required edits to make a document that 
>reflects the work that has been carried out in the IETF's URN Working Group.

That is an interesting interpretation of history.  You asked for no
requirements to be placed on URNs, so I placed no requirements on them.
You asked for me to reference RFC 2141, and I did exactly that.
You asked that we not say things about URNs in a document titled
"URL: Syntax and Semantics", and so Larry first removed what I had
written about URIs and later we changed the document title and rewrote
the entire section.  When the eleventh draft of this review (uri-00)
was completed on November 5th, Keith asked for your comments.
You made no comments that I am aware of until December 10, and even
then you did not send them to me.

When I finally did receive your comments, I provided counterexamples
to every claim you made.  There is no basis for your "required edits",
and therefore I have no reason to make them.

>Thus, your document is just that -- your document, and not a URI syntax
>and semantics document, not an IETF document that accurately reflects
>the syntax and semantics of all URIs as defined within the auspices
>of the IETF.

My document (and yes, it is my document, in addition to Larry and TimBL)
is quite capable of standing on its own.  If you would direct your comments
to what is actually written in the document, instead of what you imagine a
guy like me would be tempted to write, then maybe we can make some progress.

>Your arguments against the "# fragment" and relative URNs are, again, _your_
>arguments -- you are countering the entire output of the URN WG with
>your own interpretations and opinions. THese are all discussions that
>have been held on the URN mailing list, and results are well-documented.
>I'm not going to get back into attempting to justify them to you here; I
>don't see why I have to, as you are not the jury and arbiter on URNs.

And as I said before, the #fragment is not part of the URN.  It doesn't
make sense for the URN working group to have any opinion regarding them,
just as you can't forbid the use of anchor href attributes in HTML.
The #fragment part of a URI-reference is not in your ballywick.
Plenty of URN-based counterexamples have been provided, so at this
point I don't particularly care what was said about them on the URN WG.
They are part of the URI architecture, of which URN is only one element.
They are an optional feature that is checked for and removed from a
reference BEFORE the parser knows whether it is looking at a URL or URN,
so the URN parser can't do a bloody thing about it.  The only way we could
remove them from the syntax is to exclude the use of URNs from the
URI-reference, which would completely oppose the reason for having
a URI syntax in the first place.

>It is in fact this stone-wall editing that caused me concern over the
>whole idea of trying to develop a URI syntax document.  However, I
>have been attempting to work with the material that was put on the table.

No you haven't.  You tried to bypass it.  If you had simply sent your
comments on the actual text of the draft, then we could have discussed them.
Instead, you butchered 14 months of hard work and claimed the result
represented the URI syntax.  Well, I know better -- the URI syntax is
defined by the implementations of protocol libraries like libwww-perl
(which I wrote) and libwww (which is the basis for most URI-enabled
applications).  They allow the usable set of URI schemes, including "urn",
to be extended and dynamically loaded with the implicit assumption that
all schemes obey the requirements described in
<draft-fielding-uri-syntax-01.txt>.  That is how we are able to progress
the URI syntax as a Draft Standard.  It is both technically sound and
demonstrated by deployed applications.

>It's pretty hard to cooperate with a stone wall.  The end result of this
>obstinate lack of cooperation may either be inaccurate documentation or
>the IETF/W3C may have to do without a URI syntax document for now.  
>That seems pretty sad, and I will re-emphasisze it's not because of
>_any_ lack of effort to participate on the URN WG's part.

We have a URI syntax document that meets all of the URN WG's requirements,
as well as those of HTTP, HTML, and XML.  I suggest you read it and make
comments, but don't expect your comments to have any special status just
because you are the chair of a WG.  If the comments are technically
sound, then the WG should be capable of defending them.  The comments
you have made so far have not been technically sound.  Right now the
only excuse you have for not approving the document is that I am one
of the authors, and last I checked that wasn't a valid excuse either.
After all, I won't be able to change the document once it becomes an RFC,
so there is no point in imagining "alarm bells".

....Roy

Date: Fri, 26 Dec 1997 15:36:46 +0100
To: Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>
From: Harald Tveit Alvestrand <[email-masked]>
Subject: [URN] Re: URI documents
Cc: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Harald Tveit Alvestrand <[email-masked]>

At 16:06 24.12.97 -0800, Larry Masinter wrote:
>Between:
>
>a) Roy's last URL syntax draft what we did a last call on.
>b) Roy's attempt to turn this into a URI document, at (I believe
>   the original suggestion of the area directors) by doing
>   a global substitute
>c) Leslie's attempt to split (b) into a URI and a URL document
>d) Larry's attempt to create a single document which discusses
>    URIs and URLs.
>   (ftp://ftp.parc.xerox.com/pub/masinter/uri-url-syntax.txt)
>
>We have heard from a few folks, but not a lot. To recap:

Remember - this is Christmas time.
Season of good cheer and good will to all men, and not too much time
left over for IETF discussions!

Just to recap:
The lack of a basic UR* syntax document is blocking forward progress
on some other documents that have chosen to refer to such a document,
including the data: UR? scheme and the extended mailto: UR? scheme.
(the question marks indicate my doubts about the proper labelling of those
schemes, BTW....)

The ADs found, after some thinking, that the situation where we had
a well documented URL concept, a well documented URN concept,
and a totally undocumented URI concept embracing the two was not only
harmful, 
but silly.

The suggestion was made, perhaps foolishly, by me, to turn the URL document
into an URI document to rectify this problem, and Roy attempted to do this,
not
being terribly happy with the result.

So we're where we are, and searching for a sane way out.
To me in my AD position, the parameters of a solution are:

- The solution must document the overall concept that embraces all the
  identifiers of this class, commonly called "URI". (This rules out a)
- The solution must not invalidate current UR* schemes, including URNs.
- The solution should not needlessly complicate or constrain future UR*
  schemes

All I can say is - I hope we find a solution.

Season's greetings to you all, and have a happy new year!

                                   Harald A

Date: Thu, 25 Dec 1997 13:20:44 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Al Gilman <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Al, you asked:

> On what basis do you feel entitled to "make it really clear"?

I didn't think it required any formal permission to ask someone
to be clear about their opinion on the mailing list. But,
just to make it really clear, I am acting as a member of the
application area directorate:

     http://www.apps.ietf.org/apps-area.html

Within the applications area directorate, I believe that I have 
primary responsibility to facilitate the progress of URI-related
documents, although John Curran has been helping on this particular
issue.

In addition, just to make it clear, I am also speaking as one
of the authors of the documents (a)-(d) in question; my name is
listed as an author on all of them, I have significant investment
in their development. As an editor or author of a standards track
document, I have the responsibility to reflect the consensus of the
Internet community. In order to do so, though, it is reasonable
to ask those members of the community to be clear about which,
if any, of the offered alternatives are acceptable, to explain
their opinions and the basis for them.

> The one thing I would like to vote on is that this process rule
> is out of order.

The rules of order for the Internet process are specified in
RFC 2026. The rules call for open review and discussion. Asking
people to be clear about their opinion on documents seems to
be part of "open review and discussion". I believe that "open review"
means, in particular, "open review of documents". We have four
documents. I would like you to review them. You may have important
opinions about other related topics, but at this point, we need
review of the documents.

> The range of documents offered fails to contain a mutually
> agreeable solution precisely because you have not given enough
> respect and time to the discovery of areas of agreement expressed
> as principles.

Al: We've evaluted the principles endlessly. We have four
documents (or more precisely, three documents and one pair
of documents) to consider as choices. It is reasonable to
poll the community, at this point in the process, to be specific
not just about principles (which have been discussed for at least
four years), but about the specific documents. As it stands,
as long as we are talking about general principles as applied
to Internet Protocols, I think we have general agreement. That is,
there is no disagreement, as far as I can see, over the principle
that the relative forms, the generic URL syntax, or the use of
fragment identifiers are defined for URLs, and, in fact, only
for some URLs and not for others. I think there is no disagreement
or any counter-claims that, in general, these forms do not
apply universally to all URNs. There is also no disagreement,
as far as I can tell, to the claim that these forms *might*,
at some point in the future, apply to *some* URNs. (That is,
the messages have been consistent on the point that this is
something that the URN working group 'has not yet decided',
rather than that this is something that the URN working group
'has decided, and decided that the answer is negative.')

The disagreement seems to be entirely over the proper way of
*expressing* the concepts over which we seem to all agree.

In one expression (a), we merely claim that these forms apply
to URLs, and leave any discussion of whether they might apply
to URNs to some other (yet unwritten) document. In expression (b),
we claim that these forms *might* apply to all URIs, that their
applicability depends on the scheme (for relative forms) or the
scheme and media type (for fragment identifiers), and leave it up
to the definition of the URN scheme to be explicit about the
applicability or non-applicability of those forms.

In expressions (c) and (d), the applicability of relative forms
and fragment identifiers is explicitly only referenced for URLs
and omitted for URNs; (c) does this with two documents and (d)
with one.

> The request from Dan, at least, is insensitive to whether there
> is one document or multiple.  He needs to be able to refer to
> an "URI-reference" in his specs and that definition should be
> in one place.  How the rest gets laid out is not, in principle,
> of concern to him.

The only document which does not define "URI-reference" is (a).
If we proceed with (a), we still have some choices about how to
deal with the request for the definition of such a term.

The other three choices define "URI-reference"; (b) is explicit
about the possibility that a URI-reference *might*, at some point,
consist of a URN and a fragment identifier, while (c) and (d)
do not admit that possibility. 

I believe that the only reasonable way out of the circular discussions
we've had on this is to get a broader set of input from more members
of the Internet community, and ask that people be explicit about
their preference with respect to the particular expressions that
have been produced so far.

If you dislike all of (a) - (d), or think that specific changes would
give us a document or document set we could all rally around, then
please offer us yet another alternative.

Larry
-- 
http://www.parc.xerox.com/masinter

From: Al Gilman <[email-masked]>
Subject: Re: [URN] Re: URI documents
To: [email-masked] (Larry Masinter)
Date: Thu, 25 Dec 1997 12:02:20 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Al Gilman <[email-masked]>

to follow up on what Larry Masinter said:

> > I would like to support Leslie's point (c) that the URI document be separated from
> > the URL document and that it be consistent with the URN work.
> 
> Hi John,
> 
> Just to make it really clear: we're not talking about 'points'
> or 'principles', we're talking about specific documents. Do you
> find that the document(s) that Leslie recently posted (c) are
> the only acceptable solution to documenting the relationship of
> URLs and URIs and URNs? That the documents (a), (b), and (d)
> are unacceptable?

On what basis do you feel entitled to "make it really clear"?
I thought that the decision structure had decomposed to the
point where only the ADs could make that pronouncement.

The one thing I would like to vote on is that this process rule
is out of order.

The range of documents offered fails to contain a mutually
agreeable solution precisely because you have not given enough
respect and time to the discovery of areas of agreement expressed
as principles.

The request from Dan, at least, is insensitive to whether there
is one document or multiple.  He needs to be able to refer to
an "URI-reference" in his specs and that definition should be
in one place.  How the rest gets laid out is not, in principle,
of concern to him.

-- Al Gilman

Date: Thu, 25 Dec 1997 00:29:47 -0500
To: Larry Masinter <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] Re: URI documents
Cc: Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

At 8:24 PM -0800 97-12-24, Larry Masinter wrote:
>> I would like to support Leslie's point (c) that the URI document be separated from
>> the URL document and that it be consistent with the URN work.
>
>Hi John,
>
>Just to make it really clear: we're not talking about 'points'
>or 'principles', we're talking about specific documents. Do you
>find that the document(s) that Leslie recently posted (c) are
>the only acceptable solution to documenting the relationship of
>URLs and URIs and URNs? That the documents (a), (b), and (d)
>are unacceptable?

Hi Larry,

Just to be clear, I choose C.

C Separate documents for URLs, URIs, and URNs.

Meaning that:

Documents a, b, d are unacceptable.

Date: Wed, 24 Dec 1997 20:24:07 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "John C. Mallery" <[email-masked]>
CC: Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> I would like to support Leslie's point (c) that the URI document be separated from
> the URL document and that it be consistent with the URN work.

Hi John,

Just to make it really clear: we're not talking about 'points'
or 'principles', we're talking about specific documents. Do you
find that the document(s) that Leslie recently posted (c) are
the only acceptable solution to documenting the relationship of
URLs and URIs and URNs? That the documents (a), (b), and (d)
are unacceptable?

Larry

-- 
http://www.parc.xerox.com/masinter

Date: Wed, 24 Dec 1997 22:44:26 -0500
To: Larry Masinter <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] Re: URI documents
Cc: Leslie Daigle <[email-masked]>, "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

I would like to support Leslie's point (c) that the URI document be separated from
the URL document and that it be consistent with the URN work.

URI's should not be encumbered with the URL lagacy. Separating the documents
is the best way to do this. 

URLs have some muddy distinctions: physical locations (e.g., ftp:) vs. logical 
locations (e.g. news:). It would be nice to clarify these differences by calling 
the logical locations URNs and grandfathering them in. Then, we would have a bit 
cleaner identifier ontology.

These documents are going to provide the foundation for the development of
a world wide assertion infrastructure and everyone will benefit from doing
a clean job on them.

Roy: Remember when I pointed out the need for keep alive in the old http spec
in the summer of 1995? URNs are analogous; in two years these things will be
everywhere and people will be building all kinds of interesting things atop them.
The main difference is that enabling distributed assertions is *really* big -- and
you want to be remembered for doing it right.

If there is some reason why the URI document cannot be done right now, then
the URL document should go forward without *any* mention of URIs or URNs.
Someone else can later do the URI document and perhaps provide a more detached
perspective on the controversies.

Date: Wed, 24 Dec 1997 16:06:33 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Leslie Daigle <[email-masked]>
CC: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: URI documents
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>
Between:

a) Roy's last URL syntax draft what we did a last call on.
b) Roy's attempt to turn this into a URI document, at (I believe
   the original suggestion of the area directors) by doing
   a global substitute
c) Leslie's attempt to split (b) into a URI and a URL document
d) Larry's attempt to create a single document which discusses
    URIs and URLs.
   (ftp://ftp.parc.xerox.com/pub/masinter/uri-url-syntax.txt)

We have heard from a few folks, but not a lot. To recap:

Leslie says "There are only 2 possible paths forward here"
and indicated that only (a) and (c) are acceptable; the arguments
against (b) being posted to the list.

Roy finds (b) acceptable, would find (a) acceptable if some
editorial improvements (included in (b)) were retrofitted,
thinks (c) is totally unacceptable, and thinks the "fixes" in (d)
are are not needed and in several places actually overspecified
the requirements for URNs.  

Dave Durand posted that fragment identifiers SHOULD apply to
some URN in the context of XML, but didn't clearly indicate a
preference for any of the drafts.

Al Gilman posted about the issue of fragment identifiers and
URIs, but didn't indicate a preference for any of the drafts.

Are there any other opinions about the relative merits of the
individual drafts or proposed modifications to any of them?

Regards,

Larry

Date: Wed, 24 Dec 1997 15:13:40 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: URI documents 
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Roy,

You currently have your name on an Internet-Draft document that says
it is a URI syntax document.  To date, you have personally rejected
100% of the URN WG chairs' required edits to make a document that 
reflects the work that has been carried out in the IETF's URN Working Group.

Thus, your document is just that -- your document, and not a URI syntax
and semantics document, not an IETF document that accurately reflects
the syntax and semantics of all URIs as defined within the auspices
of the IETF.

Your arguments against the "# fragment" and relative URNs are, again, _your_
arguments -- you are countering the entire output of the URN WG with
your own interpretations and opinions. THese are all discussions that
have been held on the URN mailing list, and results are well-documented.
I'm not going to get back into attempting to justify them to you here; I
don't see why I have to, as you are not the jury and arbiter on URNs.

It is in fact this stone-wall editing that caused me concern over the
whole idea of trying to develop a URI syntax document.  However, I
have been attempting to work with the material that was put on the table.
It's pretty hard to cooperate with a stone wall.  The end result of this
obstinate lack of cooperation may either be inaccurate documentation or
the IETF/W3C may have to do without a URI syntax document for now.  
That seems pretty sad, and I will re-emphasisze it's not because of
_any_ lack of effort to participate on the URN WG's part.

By the way:

On Tue, 23 Dec 1997, Roy T. Fielding wrote:
> standard!  When I made detailed comments on various URN drafts, they
> were ignored --- not noted as being discussed and "resolved", just ignored.

I went through the entire URN WG mail archive, and found only 2 messages
from you (other than the cc'ed messages re. this document from October).
Neither message contained detailed discussion of documents, or points
that required responses.  So, I don't know where you sent these detailed 
comments that went unanswered, but as it was not the URN mailing list,
I can't speak to the issue. 

> Happy Holidays,

And to you, too.

Leslie.

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

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Fri, 19 Dec 1997 15:17:58 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] URN WG Minutes for Washington DC
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Please find attached the minutes from the URN WG meeting (Dec 11).

Leslie.

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

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

                   Minutes of the URN Working Group
                        40th IETF Washington D.C.
                          December 11, 1997

Session Chair:  Leslie Daigle
Minutes: Sally Hambridge 
Reviewed by:  URN WG

The URN working group met to discuss "URNs in a practical world," with
the intent of talking about registration and standardization, NAPTR,
RFCs, PDIs and the possibility of wrapping up the working group.

There are several systems currently using URNs.  There is a current
draft: draft-lyon-itp-nodes-02.txt, as well as FINBNs and
NISO ISDIs.  The group agreed that these were "good" illustrations
of URNs since they seemed to be using names reasonably.  The lyon
draft specifies the URN as the transaction ID but the common case
is to define its own transaction ID as the URN. This is not standard.
FINDBNs are used by the National Library of Finland.  This is a naming 
system for documents and a name space to fit with it.  NISO ISDIs are digital 
IDs for publications.  Multicast is also interested in URNs for their work.

Registration and Standards Doc - this is a re-working of an earlier document.
It was re-focused at the Munich meeting and is now a set of mechanical
procedures for registering name spaces.  The doc proposed 4 levels:

Experimental
Informal
Standard
Top-level

The idea has been copied in great part from the MIME media-types.  
Experimental namespace IDs would be self-assigned; Informal would be easy 
to get and contexts for use would be identifiable as short-term.  It would
be a string ID based on OID/accession number.  These would not be 
legislated or enforced.  The Standard NIDs would represent a small 
number of namespaces for which the marketplace has decided success.  
These would be built for real name space requirements and used in the
Internet context.  These would require an RFC to document the space
and some entities will wish to document their requirements more closely
than others, but there should be enough documentation for resolution.
Both the name space and the name space ID are specificially registered.

For the Top-level (TL) the proposal is for a hierarchical structure 
with the TL reserved allowing sub-delegation.  A rough cut at the TL is
the RFC 1766 country codes.  This allows a country to delegate the
NID as it sees fit.  We need to make sure that the reserved characters
as stated in the syntax RFC are the only ones we need for this 
hierarchical scheme.  We had a discussion about setting aside a 
particular structure for the TL name spaces.  There was a question
about DNS impact, which was really a question about how flat the name
space is.  We said that these are not volatile structures, but are
fairly static which could be cached and replicated.  There was 
some discussion about the structure and we noted that if we used 
any characters other than A-Z, a-z, 0-9  and - we would be in violation
of our own syntax RFC.

Leslie expressed frustration over the fact that only one person had
commented on the draft on the mailing list, while the room seemed filled
with contentious opinion on the draft.  She urged people strongly to
be sure to bring their thoughts up on the mailing list, where official
group discussion takes place.

The discussion about how to register name spaces fell down the 
proverbial vanity name space well.  The first part of the discussion
concentrated on the process.  The suggestion was that the process
be analogous to mime-type registration a la RFC 2048.  That is, all
NIDs would register with the IANA but Experimental types.  Informal
would have and NID assigned.  Standard and TL would require an 
RFC-publication for documentation.  There was then a discussion about
the problems with conflict and conflict resolution at the Informal 
level.  What if there were duplicates?  The suggestion was that we 
use OIDs and dashes not dots.  Keith Moore claimed this was too complex,
that we need real NIDs with vetting and attainable ones,  that they need 
to be very lightweight and are assigned not requested.  This would need a
lightweight process which is just number assignment.  This position
is based on 2 things: the names have to fit the rules; and they have to 
be unique.  He argued for decoupling the assignment of IDs with 
whether or not they go in registries -- what an entity does internally
doesn't matter.  Other comments included: if they want to collaborate 
and not clash they should use Informal NIDs.  Very well known spaces should 
use TLs and vetting.  Standard and top-level may be combined.  We might 
go to Internal, Public and Private.

This led to the (sigh) discussion about vanity names.  We need to reduce 
the number to these to special standard ones.  We may need to not use
OIDs and IANA hands out a 15 or 32 digit number (or alpha-numeric)
which would not prejudice any particular resolution scheme.  However,
we need some motivation for going formal.  We need implementation
experience with managing the name space.  To take this discussion
back to the original examples used, ISBNs or SICI codes would be
standard; FINBNs would be a assigned by the Finnish TL.  A Big
Corporation would use Informal; Social Security numbers would be 
TL/country specific, and US social security numbers are Top-level
country.  We had a contentious discussion which looked like Munich.
Keith suggested that we need to pick solutions which fit the URN
requirements.  How should they be distinguishable in the RDS?
What is the impact and reliability of the level of service? How
is a lab different from being WWW accessible?  All this needs to be
well documented and described.

Properties and characteristics of the namespace should all be changeable
so they should not be embedded in the name.   Remember - who needs to
know and when do they need to know?  Is 3 classes reasonable?  Is 
renaming reasonable?  This is a registry issue and wrapping a 
quality issue around it is probably a problem.  We need to deal
(still!) with the vanity name spaces as a public process.  Some
should be "very well documented" and not just assigned numbers.

We need to have some consensus here - is a structure allowed in NIDs? 
The document assumed yes it is, but we really don't know.
Experimental may be noted but the structure is left to the name space
owner.  With a registry we need to revisit the entire area, but we 
shouldn't make assumptions.  We actually have 2 design choices:
1) assign numbers with technical criteria
2) pick the hard choice (allow vanity spaces)
This discussion was refferred to te mailing list.

We then went over the documents which were mandated by our charter:
The Biblio IDs - show how grandfathering an existing space would work.
The architecture draft, as the working group chair reminded the AD
needs resolution.  The IETF name space draft may be superceded
by PDIs.  NAPTR needs a document to explain how to get a namespace 
and how it gets resolution.  

John Mallery gave a presentation on PDIs.  The White House is using these
in conjunction with thttp to name documents and get resolution.
The most contentious issue was that they used the "|" and this was
not on the list of OK characters.  Ryan suggested using "$".  Check
the draft for all relevant info, including the BNF.
draft-mallery-urn-pdi-00.txt.

PDI may take the place of ietf as a new namespace showcase example.
PDI needs to coordinate with the http extensions group.

Clearly, we're not wrapped up yet, although the Chair expressed the
hope and expectation that fruitful work on the mailing list could yield
the necessary remaining components before the next IETF meeting.

Date: Thu, 18 Dec 1997 13:24:25 -0500
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URN header
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Should there be a definition for a URN header for email?
for http?

Or would you rather use URI?

Date: Thu, 18 Dec 1997 11:28:30 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] further reflections from Washington meeting
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

One thing that I felt was important to include in the minutes from
the meeting was the following:

  Leslie expressed frustration over the fact that only one person had
  commented on the draft on the mailing list, while the room seemed filled
  with contentious opinion on the draft.  She urged people strongly to
  be sure to bring their thoughts up on the mailing list, where official
  group discussion takes place.

After the meeting, I had further reflection that most of the commentary
in the meeting was not well anchored to a discussion of the document
itself -- i.e., we fell into old arguments, not a consideration of the
draft document as a whole.

As a chair of this WG, I am going to pursue these issues on this list
by 

	a) actively soliciting further discussion on this one 
	   remaining point (the assignment of NIDs) on the mailing
	   list, and 

	b) working to keep that discussion focussed and moving towards
	   finding the reasonable engineering solution for today

Specifically, Keith called for a show of hands in support of "get the
IANA to assign a random string of digits & characters" as a solution
for how to assign NIDs today.  I agreed to take that call to the list.

However, further discussion with others in the room afterwards, and in
consideration of some of the proposals that have been circulated 
on this list since, I think that it is premature to make that call.  Apart
from any counterarguments that were presented to it, I think what
was quite clear in the meeting is that we haven't yet teased apart all
the underlying issues that were addressed in the proposed document.
I suggest we do that, and _then_ come back to the issue of how to assign
NID strings in the here and now.

Specific things that I heard as consensus in the meeting room:

	. it's probably too early to attempt to make any suggestions
	  re. hierarchical structures of the NID -- i.e., the "top-level"
	  case in the existing document should be removed, with the
	  view to considering this sort of thing at a later date, when
	  there is more operational experience of why these things might
	  be necessary

	. the document, as it currently stands, mixes some notion of
	  namespace id assignment and expected level of service. These
	  are separate issues, and should be treated as such

I think Michael has already made a pass at trying to tease apart these
issues; let's take the discussion from there.

Leslie.

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

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

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

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Thu, 18 Dec 1997 04:58:41 -0500
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] THHP Spec/resolution
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

When there is underlying knowledge of a resource (as in I2R) and
the resolver is return results over HTTP, it should:

	1. Provide the information for the underlying resource in the head method.

	2. Provide the information for the underlying resource in the get method.

The information is:

	a. content-type
	b. content-length
	c. version/etag
	d. last-modification
	e. content-language
	f. charset as appropriate

Additionally, get should use conditional-get to allow caching via 304.

Some of these may be relevant for other resolution methods as well.

Date: Wed, 17 Dec 1997 13:34:26 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] Draft minutes from Washington DC
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Thanks, Sally, for taking minutes at the meeting and turning them
around so expeditiously!

If no one has anything to add or adjust in these minutes, I will
send them off to the minutes editor on Friday.

If you _do_ have something you feel was missed here, please send me
mail before Friday.

Thanks!
Leslie.

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

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

                DRAFT Minutes of the URN Working Group
                        40th IETF Washington D.C.
                          December 11, 1997

Session Chair:  Leslie Daigle
Minutes: Sally Hambridge 
Reviewed by:  URN WG

The URN working group met to discuss "URNs in a practical world," with
the intent of talking about registration and standardization, NAPTR,
RFCs, PDIs and the possibility of wrapping up the working group.

There are several systems currently using URNs.  There is a current
draft: draft-lyon-itp-nodes-02.txt, as well as FINBNs and
NISO ISDIs.  The group agreed that these were "good" illustrations
of URNs since they seemed to be using names reasonably.  The lyon
draft specifies the URN as the transaction ID but the common case
is to define its own transaction ID as the URN. This is not standard.
FINDBNs are used by the National Library of Finland.  This is a naming 
system for documents and a name space to fit with it.  NISO ISDIs are digital 
IDs for publications.  Multicast is also interested in URNs for their work.

Registration and Standards Doc - this is a re-working of an earlier document.
It was re-focused at the Munich meeting and is now a set of mechanical
procedures for registering name spaces.  The doc proposed 4 levels:

Experimental
Informal
Standard
Top-level

The idea has been copied in great part from the MIME media-types.  
Experimental namespace IDs would be self-assigned; Informal would be easy 
to get and contexts for use would be identifiable as short-term.  It would
be a string ID based on OID/accession number.  These would not be 
legislated or enforced.  The Standard NIDs would represent a small 
number of namespaces for which the marketplace has decided success.  
These would be built for real name space requirements and used in the
Internet context.  These would require an RFC to document the space
and some entities will wish to document their requirements more closely
than others, but there should be enough documentation for resolution.
Both the name space and the name space ID are specificially registered.

For the Top-level (TL) the proposal is for a hierarchical structure 
with the TL reserved allowing sub-delegation.  A rough cut at the TL is
the RFC 1766 country codes.  This allows a country to delegate the
NID as it sees fit.  We need to make sure that the reserved characters
as stated in the syntax RFC are the only ones we need for this 
hierarchical scheme.  We had a discussion about setting aside a 
particular structure for the TL name spaces.  There was a question
about DNS impact, which was really a question about how flat the name
space is.  We said that these are not volatile structures, but are
fairly static which could be cached and replicated.  There was 
some discussion about the structure and we noted that if we used 
any characters other than A-Z, a-z, 0-9  and - we would be in violation
of our own syntax RFC.

The discussion about how to register name spaces fell down the 
proverbial vanity name space well.  The first part of the discussion
concentrated on the process.  The suggestion was that the process
be analogous to mime-type registration a la RFC 2048.  That is, all
NIDs would register with the IANA but Experimental types.  Informal
would have and NID assigned.  Standard and TL would require an 
RFC-publication for documentation.  There was then a discussion about
the problems with conflict and conflict resolution at the Informal 
level.  What if there were duplicates?  The suggestion was that we 
use OIDs and dashes not dots.  Keith Moore claimed this was too complex,
that we need real NIDs with vetting and attainable ones,  that they need 
to be very lightweight and are assigned not requested.  This would need a
lightweight process which is just number assignment.  This position
is based on 2 things: the names have to fit the rules; and they have to 
be unique.  He argued for decoupling the assignment of IDs with 
whether or not they go in registries -- what an entity does internally
doesn't matter.  Other comments included: if they want to collaborate 
and not clash they should use Informal NIDs.  Very well known spaces should 
use TLs and vetting.  Standard and top-level may be combined.  We might 
go to Internal, Public and Private.

This led to the (sigh) discussion about vanity names.  We need to reduce 
the number to these to special standard ones.  We may need to not use
OIDs and IANA hands out a 15 or 32 digit number (or alpha-numeric)
which would not prejudice any particular resolution scheme.  However,
we need some motivation for going formal.  We need implementation
experience with managing the name space.  To take this discussion
back to the original examples used, ISBNs or SICI codes would be
standard; FINBNs would be a assigned by the Finnish TL.  A Big
Corporation would use Informal; Social Security numbers would be 
TL/country specific, and US social security numbers are Top-level
country.  We had a contentious discussion which looked like Munich.
Keith suggested that we need to pick solutions which fit the URN
requirements.  How should they be distinguishable in the RDS?
What is the impact and reliability of the level of service? How
is a lab different from being WWW accessible?  All this needs to be
well documented and described.

Properties and characteristics of the namespace should all be changeable
so they should not be embedded in the name.   Remember - who needs to
know and when do they need to know?  Is 3 classes reasonable?  Is 
renaming reasonable?  This is a registry issue and wrapping a 
quality issue around it is probably a problem.  We need to deal
(still!) with the vanity name spaces as a public process.  Some
should be "very well documented" and not just assigned numbers.

We need to have some consensus here - is a structure allowed in NIDs? 
The document assumed yes it is, but we really don't know.
Experimental may be noted but the structure is left to the name space
owner.  With a registry we need to revisit the entire area, but we 
shouldn't make assumptions.  We actually have 2 design choices:
1) assign numbers with technical criteria
2) pick the hard choice (allow vanity spaces)
This discussion was refferred to te mailing list.

We then went over the documents which were mandated by our charter:
The Biblio IDs - show how grandfathering an existing space would work.
The architecture draft, as the working group chair reminded the AD
needs resolution.  The IETF name space draft may be superceded
by PDIs.  NAPTR needs a document to explain how to get a namespace 
and how it gets resolution.  

John Mallery gave a presentation on PDIs.  The White House is using these
in conjunction with thttp to name documents and get resolution.
The most contentious issue was that they used the "|" and this was
not on the list of OK characters.  Ryan suggested using "$".  Check
the draft for all relevant info, including the BNF.
draft-mallery-urn-pdi-00.txt.

PDI may take the place of ietf as a new namespace showcase example.
PDI needs to coordinate with the http extensions group.

Clearly, we're not wrapped up yet, although the Chair expressed the
hope and expectation that fruitful work on the mailing list could yield
the necessary remaining components before the next IETF meeting.

Date: Wed, 17 Dec 1997 00:09:53 -0500
To: "Ryan Moats" <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] Why hacking the NID is a bad idea.
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

At 2:53 PM -0500 97-12-16, Ryan Moats wrote:
>On Sat, 13 Dec 1997 20:38:08 -0500, John C. Mallery wrote:
>
>>		urn:nation: or urn:nat:
>>
>>		urn:company: or urn:com:
>>
>>		urn:int: for international organizations
>>
>>		urn:org: for non-profits
>>
>>		urn:edu: for educational institutions
>
>This begins to look frightenly like DNS, which I'm not convinced is a GOOD thing.
>(in fact, I'm probably closer to it being a BAD thing).  If we consider the history of
>DNS, going this route could concentrate a lot of power into a few hands, with all that
>means...

Putting this stuff in the NID certainly doesn't improve the situation. 
You can break it up some more ways, but it seems to me that the main
point to prevent these issues from overwhelming the entire URN effort.
Sacrifices a few namespaces seems like a fine price to pay.
>
>>9. NIDs should not be restricted to 32 characters. This is
>>a legacy constraint from DNS, which will be important only
>>as long as DNS is used for discovery.  Thereafter, the 32 character
>>constraint disappears, leaving the maximum address space open for
>>future uses. 
>>
>>	a. Tom Knight advise the Internet use 64bits when the 32bit
>>	error was made.
>>
>>	b. There is no reason to make the same mistake again.
>>
>>	c. There is no reason to place arbitrary limits.
>>
>>	d. However, NIDs MAY wish to use combinations less than
>>	32 characters if they expect to use DNS for discovery.
>>
>>	e. NID SHOULD be parsimonious for ease of transcription.
>
>I think this can be put off for later.  I can't believe that having 32 characters as
>a limit for NIDs is a real problem for initial deployment.  If we get some "running
>code" experience that indicates that 63 (or some larger amount) is necessary,
>then we can consider it for the draft standard step.

What we need to avoid is people wiring 32 characters into their parser, which
then prevents subsequent expansion. No limit prevents them from doing this.
A SHOULD BE parsimonious keeps most NID within 32 characters for now. You have
your cake and eat it too by NOT introducing an artificial legacy constraint.
How's that?

Date: Wed, 17 Dec 1997 00:15:47 -0500
To: "Ryan Moats" <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: Comments [URN] PDI Namespace Draft
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Thanks for the comments.

They will be reflected in the 01 draft.

At 2:45 PM -0500 97-12-16, Ryan Moats wrote:
>Well, I'm finally getting around to the note to make to myself to comment on some of the issues (as I see them)
>in this draft...
>
>>        <FRAGMENT-SPECIFIER> = "#" [fragment-scheme "="] position [*("," position)]
>
>John has already proposed that "$" be used instead of "#"...

We going with this since nobody has objected.
>
>>        <RESERVED> = "%" / "." / "," / "/" / "#" / "*" / "@" / 
>>                     "=" / "?" / "+"
>>
>>
>>1.2.5 Reserved Characters
>>
>>   <RESERVED> are used as special characters in the PDI grammar. They
>>   MUST be encoded according to the character escaping method
>>   described in RFC 2141 [17].
>
>Um, they MUST be encoded if they being used in a literal sense.  The way this reads
>now is that they MUST always be encoded, which I don't think was the intent...

Good point.
>
>>2 Discussion
>>   
>>2.1 Minting PDIs
>>   
>>   PDIs are issued by the authority named in <DOCUMENT-SERIES>.
>>   <DOCUMENT-SERIES> is intended to look like a domain name for easy
>>   parsing but there is no requirement to serve the name via the Domain
>>   Name System (DNS) nor to assure that the name is not assigned for
>>   other purposes by DNS. 
>
>Not to be difficult, but I assume that each <DOCUMENT-SERIES> is to be unique
>between minters? I'm not clear from section 2.2 exactly who/what the issuing authority
>is and how this is all supposed to work.  More clarification would be good.

Yes, they must be unique across minters.  

Once someones gets their toplevel components, they delegate within the series.

There is a root issuing authority, and then, everyone can issue authorities within
their document series.  The root issuing regime needs to be specified.

>
>>3.6.1 Minting
>>
>>   When PDIs are minted, they MUST carry a format and a version number
>>   and they MUST NOT contain any wildcards. This ensures that the
>>   identifiers associated with digital resources are fully specified
>>   and convey both the media type and the version number. The presence
>>   of a version number makes it possible to check for a higher version
>>   of the resource.  Together, the format and version number enable
>>   fragment citation.
>
>This should probably be repeated in the minting section (I apologize if it is
>already there, I didn't see it).

OK. These clarification points are good to make sure people understand the spec.

From: "Ryan Moats" <[email-masked]>
To: "John C. Mallery" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 16 Dec 97 14:53:39 
Priority: Normal
Subject: Re: [URN] Why hacking the NID is a bad idea.
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Sat, 13 Dec 1997 20:38:08 -0500, John C. Mallery wrote:

>		urn:nation: or urn:nat:
>
>		urn:company: or urn:com:
>
>		urn:int: for international organizations
>
>		urn:org: for non-profits
>
>		urn:edu: for educational institutions

This begins to look frightenly like DNS, which I'm not convinced is a GOOD thing.
(in fact, I'm probably closer to it being a BAD thing).  If we consider the history of
DNS, going this route could concentrate a lot of power into a few hands, with all that
means...

>9. NIDs should not be restricted to 32 characters. This is
>a legacy constraint from DNS, which will be important only
>as long as DNS is used for discovery.  Thereafter, the 32 character
>constraint disappears, leaving the maximum address space open for
>future uses. 
>
>	a. Tom Knight advise the Internet use 64bits when the 32bit
>	error was made.
>
>	b. There is no reason to make the same mistake again.
>
>	c. There is no reason to place arbitrary limits.
>
>	d. However, NIDs MAY wish to use combinations less than
>	32 characters if they expect to use DNS for discovery.
>
>	e. NID SHOULD be parsimonious for ease of transcription.

I think this can be put off for later.  I can't believe that having 32 characters as
a limit for NIDs is a real problem for initial deployment.  If we get some "running
code" experience that indicates that 63 (or some larger amount) is necessary,
then we can consider it for the draft standard step.

Ryan

From: "Ryan Moats" <[email-masked]>
To: "John C. Mallery" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 16 Dec 97 14:45:04 
Priority: Normal
Subject: Comments [URN] PDI Namespace Draft
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Well, I'm finally getting around to the note to make to myself to comment on some of the issues (as I see them)
in this draft...

>        <FRAGMENT-SPECIFIER> = "#" [fragment-scheme "="] position [*("," position)]

John has already proposed that "$" be used instead of "#"...

>        <RESERVED> = "%" / "." / "," / "/" / "#" / "*" / "@" / 
>                     "=" / "?" / "+"
>
>
>1.2.5 Reserved Characters
>
>   <RESERVED> are used as special characters in the PDI grammar. They
>   MUST be encoded according to the character escaping method
>   described in RFC 2141 [17].

Um, they MUST be encoded if they being used in a literal sense.  The way this reads
now is that they MUST always be encoded, which I don't think was the intent...

>2 Discussion
>   
>2.1 Minting PDIs
>   
>   PDIs are issued by the authority named in <DOCUMENT-SERIES>.
>   <DOCUMENT-SERIES> is intended to look like a domain name for easy
>   parsing but there is no requirement to serve the name via the Domain
>   Name System (DNS) nor to assure that the name is not assigned for
>   other purposes by DNS. 

Not to be difficult, but I assume that each <DOCUMENT-SERIES> is to be unique
between minters? I'm not clear from section 2.2 exactly who/what the issuing authority
is and how this is all supposed to work.  More clarification would be good.

>3.6.1 Minting
>
>   When PDIs are minted, they MUST carry a format and a version number
>   and they MUST NOT contain any wildcards. This ensures that the
>   identifiers associated with digital resources are fully specified
>   and convey both the media type and the version number. The presence
>   of a version number makes it possible to check for a higher version
>   of the resource.  Together, the format and version number enable
>   fragment citation.

This should probably be repeated in the minting section (I apologize if it is
already there, I didn't see it).

Ryan

Date: Tue, 16 Dec 1997 13:04:16 -0500
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] Why hacking the NID is a bad idea.
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

> 9. NIDs should not be restricted to 32 characters. This is
> a legacy constraint from DNS, which will be important only

It was pointed out to me in private email that there is no such 32 character 
limit in the DNS. DNS Labels may consist of up to 63 characters, the maximum 
domain name length is 255. See RFC1035, RFC1123.

Replace 32 with 63 in the discussion.

The same point holds; size limits of contemporary standards should not
be propagated forward to constrain future systems.

From: Michael Mealling <[email-masked]>
Subject: [URN] NID discussions from last week
To: [email-masked]
Date: Mon, 15 Dec 1997 23:59:45 -0500 (EST)
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Hi all,
 
After thinking a bit about what I was trying to say last week (wouldn't it 
be nice if I did that before I opened my mouth?) I think I can articulate it 
a bit better:
 
For those that weren't there the discussion concerned the registration
of NIDs and how to assign them to fix some problems before they become
problems. The standard discussion of vanity names vs standardized names
vs semantically free names happened again with respect to NIDs.
 
The way we handled this problem before was to push it down to the namespace
definer. The reason it became a problem for us was that for the first
time we are actually defining our own namespace which is something
we had hoped to not have to do. 
 
Anyway, in my opinion the debate seemed to deal with two questions:
 
        Do we put structure into the NID?
 
        Do we want short, standardized NIDs to be different from long,
        non-standardized NIDs?
 
The first question is what I'll focus on for my suggested solution since
the second falls out once you make the first decision.
 
The draft, as edited by Leslie and formulated by several other folx,
is fairly sound in terms of assignment. The problem was that the language
made it sound like there was real structure in the NID that someone should
depend on. This was, in my opinion, where the mistake was. The rules
surrounding the assignment were fine with me. But it should be extremely clear
that, while the assigning registrar can use structure to divide the name
up into chunks for ease of assignment, the NID is still to be considered
a flat, unstructured token by everyone else. 
 
Now, this has a slight impact on the character set of the NID. The problem
noted was that the draft uses the "." and "/" character which are
not allowed in the NID (alphas, digits, and "-" only). This is fine
since elements like "." and "/" are only important when there is a structure
to be _parsed_. The only requirement on NIDs that the registrar need 
maintain is uniqueness. 
 
Therefore, simply reserving alpha sequences for certain groups of 
registering entities (countries) should be sufficient.  For example, 
Sweden would get to start its NIDs with SE. So if there was such a 
thing as a Swedish elephant registration service that generated 
elephant codes you could simply use "SEELEPHANT". If someone wanted
a namespace that started with SE they would have to talk to someone in
Sweden. This all assumes we agree that the Top-level (type IV) style
NIDs are really needed. I think we might be able to do without them since
as long as uniqueness is maintained the NID is fine as a flat token. If
you wanted to seperate them then '-' would be fine (SE-ELEPHANT).
 
Now, with that said, I do want to make sure we allow short NIDs and not
give everyone a cumbersome stream of digits that will make even the simplest
URN hard to transcribe correctly. Also, many users who wanted to use 
URNs in the past will probably decide not to use them if their nice,
short, understandable URN all of a sudden starts to look crufty.
 
I also want to voice my support for the x- convention. It has worked
fairly well in similar situations. In the case of MIME types there was
no real force for moving from "x-foo" to "foo" since the systems still
worked. With URNs "x-" is not supported by the RDS (since it isn't registered)
so there is a real insentive to move from experimental to registered NIDs.
 
-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

Date: Mon, 15 Dec 1997 19:19 -0500
From: "John C. Mallery" <[email-masked]>
Subject: [URN] Slides from PDI Talk at URN WG Meeting
To: [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

[FYI, here are URLs for the PDI talk on Thursday.  The spec makes better and
more complete reading, but powerpoint slides look better.]

John C. Mallery ``Persistent Document Identifiers: A Proposed URN Namespace,''
presentation to the Working Group on Uniform Resource Names,'' 40th Meeting of
The Internet Engineering Task Force, Washington, DC, December 11, 1997.

HTML: http://kbcw.ai.mit.edu/talks/1997-12-11-ietf-urn-pdi/index.htm
PDF: http://kbcw.ai.mit.edu/talks/1997-12-11-ietf-urn-pdi.pdf

Date: Sat, 13 Dec 1997 20:38:08 -0500
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] Why hacking the NID is a bad idea.
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

[This roughly summarizes a conversation that I had with
Karen Sollins earlier this evening. I added whatever else I
could think of over dinner and I toss it out for others to
consider.]

Proposal: NID should allow the current alphadigits. No provision
should be made for structure and no random assignment should be done.
No character limit should be imposed in principle, but minimal
characters should be encouraged, and the 32 character DNS limit
clearly noted.

Arguments: 

1. NID should reflect exclusively:

	a. Differences in parsing syntax

	b. Differences in assignment semantics

	c. Differences in operational semantics

2. NID should span the most general class of parsing, assignment, and
operation.
	
	corollary: NID should only be assigned when it is shown that
	no existing namespaces cover the required parsing syntax, assignment
	semantics, and operational semantics available through other namespaces.

3. Vanity country and company namespaces should be defined in order
to localize assignment issues below the level of NIDs, and therefore,
isolating all other namespaces from issues arising in these domains.

	a. Management of the namespace should be delegated to organizations
	that have experience managing the associated issues, thereby freeing
	IETF from problems arising from operating these namespaces.

	b. Everyone is happy because they have their territory.

	c. Global syntax is not corrupted by domain-specific issues.

	d. Proposed names for these namespaces:

		urn:nation: or urn:nat:

		urn:company: or urn:com:

	e Other namespaces might be useful

		urn:int: for international organizations

		urn:org: for non-profits

		urn:edu: for educational institutions

4. Hacking the right side of the identifier keeps namespace and content
area issues local.

	a. preserves the technical logic of the upper components.

	b. Minimizes empiricism of the time in the upper components.

	c. Eliminates ideological battles from the upper components.

	d. Offers the greatest number of potential options for lower
	components.

5. Differentiating toplevel namespaces by operational and definitional
criteria 

	a. avoids the pitfall of content-based differentiation -- which
	will never terminate and will always produce anomalies.

	b. Allows introduction of new definitional and operational criteria
	(within URN rules) without revisions to the definitions of NIDs. 

6. Having reasonable, technical mnemonics for NIDs will make the difference
between widespread adoption and complete marginality.

	a. Nobody [except MIT types :-)] wants a number.

	b. Numbers are too easily confused.

	c. Numbers are not easily remembered.

7. Retaining the options of entity-specific names within designated
namespaces give people what they want; they will accept nothing else.

8. Other namespace can still use whatever rules they like.

9. NIDs should not be restricted to 32 characters. This is
a legacy constraint from DNS, which will be important only
as long as DNS is used for discovery.  Thereafter, the 32 character
constraint disappears, leaving the maximum address space open for
future uses. 

	a. Tom Knight advise the Internet use 64bits when the 32bit
	error was made.

	b. There is no reason to make the same mistake again.

	c. There is no reason to place arbitrary limits.

	d. However, NIDs MAY wish to use combinations less than
	32 characters if they expect to use DNS for discovery.

	e. NID SHOULD be parsimonious for ease of transcription.

Date: Fri, 12 Dec 1997 18:55:10 -0500
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URN-WG HyperArchive
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

A hyperarchive for the URN Mailing list is available at

http://wilson.ai.mit.edu/archives/urn-wg.html

Date: Fri, 12 Dec 1997 16:10:00 -0500
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] FYI PDI Fragment Delimiter Now $
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

The running PDI fragment delimiter character has been changed 
from "|" to "$".(It was originally "#", but there is a legacy
problem with browsers chopping it off.)

If there are any objections or problems forseen with use of
"$", please speak now and propose a better character.

If there are no objections, we going with "$" in the next
PDI draft, which should be available late next week.

Date: Mon, 8 Dec 1997 09:58:29 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: "Sam X. Sun" <[email-masked]>
cc: "=?ISO-8859-1?Q?Martin_J._D=FCrst?=" <[email-masked]>, "Karen R. Sollins" <[email-masked]>, Michael Mealling <[email-masked]>, "John C. Mallery" <[email-masked]>, [email-masked]
Subject: Re: [URN] Agenda for Washington... -- Questions on URN
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hi again, Sam,

My concerns are, as always, the integration of this discussion with
the work of this working group.  I.e., insofar as this mailing list is
for furthering the work we have set out to do, I must ask you to
focus your discussion in terms of concrete references to drafts and
RFCs and proposals that have been discussed here.

I am noting a disconcerting lack of awareness or acknowledgement of
the efforts we are making, to wit:

On Sat, 6 Dec 1997, Sam X. Sun wrote:
> 1.	The Handle System is designed in accordance with URN Functional
> Requirements as defined in RFC1737, and will support the "urn:" syntax as
> defined in RFC2141. 

Conformance to RFC2141 is nice, but not enough -- I have already asked you
to speak to the issues outlined in the "namespace registration" draft.
If "hdl" is to be a URN namespace, there are steps that you'll have to
go through, it won't just "happen", just as URL schemes don't just "happen".
If you have questions or suggestions for that registration process, please
cite them in specific reference to sections of that draft.

> 2.	IMHO, the current "urn:" scheme has its limitations on practical use of
> non-ASCII names (Please see my next email message which explains why). I'm
> here proposing the "hdl:" scheme that allows non-English names to be
> defined and used in a more practical manner.

We've been through this far too many times already, and Larry and Martin
have politely pointed you at the sources for pursuing this -- I expect not
to see any further reference on this mailing list, unless it affects
specific drafts we have circulated.

> 3.	I further argue that since URL allows multiple schemes (eg, http, ldap,
> mailto…), why is URN has to be limited to one scheme (ie. "urn:")? 
> 

You have made this accusation before, I have suggested an explanation,
and unless you have specific issues with what I said, you are just repeating
your opinion and not furthering the discussion.  Please drop it, or
address my comments directly.

Thanks!
Leslie.

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

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Mon, 8 Dec 1997 15:36:01 +0100 (MET)
From: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>
To: "Sam X. Sun" <[email-masked]>
cc: Leslie Daigle <[email-masked]>, "Karen R. Sollins" <[email-masked]>, Michael Mealling <[email-masked]>, "John C. Mallery" <[email-masked]>, urn-ietf <[email-masked]>
Subject: Re: [URN] Agenda for Washington ...-- Questions on URN
Sender: [email-masked]
Reply-To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>

On Sat, 6 Dec 1997, Sam X. Sun wrote:

> Hi, John, Michael, Karen, Martin, and Leslie:
> 
> I think we all agreed that URN should not exclude friendly names. (Thanks
> for clearing this up!) Here I'd like to explain why I think the current
> "urn:" scheme has its limitations on practical use of non-ASCII names, and
> then explain how "hdl:" scheme tries to address those issues.
> 
> The current "urn:" syntax is confined to a limited character set, and
> requires other native characters to be hex encoded. This practically
> disallows non-ASCII names to be defined in its native presentation, and
> presents two problems in practice: 

Hello Sam,

I only want to repeat here again that the current "urn:" syntax
(as well as the URL syntax) *formally* is restricted to ASCII and
hex-encoding (based on UTF-8).

The urn: syntax in no way restricts applications of whatever kind
to use a better user interface for entry and display. Once such
interfaces are available, people will also pass URNs among each
other in native notation. Formally, these might not be URNs,
but the users won't care. Similar things already exist now,
if you have something like:

	www.xyz.org/myfile.html#myanchor

then the official URL/URI is actually
	http://www.xyz.org/myfile.html
but general users won't care, because it works.

> These explains why I think that the "urn:" scheme does not allow friendly
> non-English names. There are over 90% of world population whose native
> language is not English, and I think it's important to address their need
> for friendly names in their own languages.

I very much agree with you.

> And I'm proposing the "hdl:"
> scheme that allows non-English names to be defined and used in a more
> practical manner, without affecting the way ASCII names are defined:
> 
> First of all, under "hdl:" scheme, names can be defined using UTF-8
> encoding directly. No hex encoding is needed. Using editing tools that
> support UTF-8 encoding, names can be defined in any native character
> without losing its native presentation.

The same is possible for URNs and URIs. Whether hex encoding is needed
or not is decided by the transport mechanism, not by the scheme.
Even if an ftp URL is hex-encoded, this hex-encoding is removed for
the actual ftp protocol. For http, it may be removed or not.

> Furthermore, in my paper sent to Unicode conference, I proposed to add
> support of any standard character set encoding defined by ISO.

Please have a look at the presentation I had at the last Unicode conference.
It can be downloaded from
	http://www.ifi.unizh.ch/mml/mduerst/papers.html
(the title is "Internationalized Internet Identifiers").

> For example,
> a name using ISO-8859-x characters can be defined as:
> 
>     hdl:charset=ISO-8859-x@<handle name encoded using ISO-8859-x character
> set>
> 
> This may look cumbersome,

It not only may look cumbersome, it indeed is very cumbersome.
I don't think anybody is ready to use it. Or would you think
that URLs would have had the success they do with English if
you had had to write

	http:charset=US-ASCII@//www.mycompany.com  ????

> but it allows people to define URN names using
> their native characters from authoring tools that support any standard
> character set encoding. And the URN names defined this way can look
> friendly during the exchange among its native people.

URNs are exchanged as characters, and in that sense are always user
friendly. In a document in e.g. ISO-8859-5, they should be encoded as
ISO-8859-5. Please note that HTML 4.0 already has the right specifications
for this:

In HTML 4.0, if an URL is encountered that contains "illegal" (in the
sense of the URI spec) characters, then these characters are translated
to UTF-8 and then %HH-encoded to give a "correct" URL. So one part
of the user-friendliness is already provided for, in a way that will
make it easy to formally allow native characters in URIs in the future.

As Larry and I have said, the rest of this is in the works, and we
would be very glad if you could help us.

Regards,	Martin.

From: "Sam X. Sun" <[email-masked]>
To: "Larry Masinter" <[email-masked]>
Cc: "=?ISO-8859-1?Q?Martin_J._D=FCrst?=" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Agenda for Washington ...-- Questions on URN
Date: Sat, 6 Dec 1997 22:59:55 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

Hi, Larry,

Thanks for the reference. I was about to ask Martin for the document (I
guess this is the one Martin mentioned in his response earlier, too bad
that he couldn't show up in the DC conference.). 

IMHO, like "urn:" syntax has its current limitations on I18N (I hope I'm
not making it up...), the URL syntax as defined in RFC1738 may have a
similar issue too. (I have seen in reality that people using URLs that are
not restricted to the syntax, simply because they want to preserve their
filenames in terms of their native characters.)

I would be glad to talk to you, and anyone else who are interested, to
continue on that work you have started...

Thanks,
Sam
[email-masked]

----------
> From: Larry Masinter <[email-masked]>
> To: Sam X. Sun <[email-masked]>
> Cc: Leslie Daigle <[email-masked]>; Martin J. Dürst
<[email-masked]>; Karen R. Sollins <[email-masked]>; Michael
Mealling <[email-masked]>; John C. Mallery <[email-masked]>;
[email-masked]
> Subject: Re: [URN] Agenda for Washington ...-- Questions on URN
> Date: Saturday, December 06, 1997 4:45 AM
> 
> I suggest that you review draft-masinter-url-i18n-00,
> "Using UTF-8 for non-ASCII Characters in URLs", dated
> May 1997. Martin Duerst has plans to submit an update,
> and I've asked for some time in the URL registration working
> group to at least bring up the internationalization issues.
> 
> Perhaps you would like to help start work in this area?
> 
> It needs a mailing list, a working group chair and a document
> editor. While I started this work, I would like to not be
> the principal document editor.
> 
> Regards,
> 
> Larry
> -- 
> http://www.parc.xerox.com/masinter

Date: Sat, 6 Dec 1997 01:45:39 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "Sam X. Sun" <[email-masked]>
CC: Leslie Daigle <[email-masked]>, "Martin J. =?iso-8859-1?Q?D=FCrst?=" <[email-masked]>, "Karen R. Sollins" <[email-masked]>, Michael Mealling <[email-masked]>, "John C. Mallery" <[email-masked]>, [email-masked]
Subject: Re: [URN] Agenda for Washington ...-- Questions on URN
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I suggest that you review draft-masinter-url-i18n-00,
"Using UTF-8 for non-ASCII Characters in URLs", dated
May 1997. Martin Duerst has plans to submit an update,
and I've asked for some time in the URL registration working
group to at least bring up the internationalization issues.

Perhaps you would like to help start work in this area?

It needs a mailing list, a working group chair and a document
editor. While I started this work, I would like to not be
the principal document editor.

Regards,

Larry
-- 
http://www.parc.xerox.com/masinter

From: "Sam X. Sun" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>, "=?ISO-8859-1?Q?Martin_J._D=FCrst?=" <[email-masked]>, "Karen R. Sollins" <[email-masked]>, "Michael Mealling" <[email-masked]>, "John C. Mallery" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Agenda for Washington ...-- Questions on URN
Date: Sat, 6 Dec 1997 04:21:13 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

Hi, John, Michael, Karen, Martin, and Leslie:

I think we all agreed that URN should not exclude friendly names. (Thanks
for clearing this up!) Here I'd like to explain why I think the current
"urn:" scheme has its limitations on practical use of non-ASCII names, and
then explain how "hdl:" scheme tries to address those issues.

The current "urn:" syntax is confined to a limited character set, and
requires other native characters to be hex encoded. This practically
disallows non-ASCII names to be defined in its native presentation, and
presents two problems in practice: 

1). Non-English names are hard to define or type in.

Imagine what non-English speaking people have to do to define the URN name
using their own alphabet. Because their native characters can not be used
directly in the URN name, they will have to find the UTF-8 encoding of each
of those native characters first, and then hex encode them. (If anyone
don't see the problem here, try to hex encode any ASCII name, and see if it
is practical. Non-ASCII name is much harder, because Unicode table is so
much bigger than ASCII table.)

2). Non-English names do not look friendly, which can make it hard in
exchange, or other practice in the non-English environment.
 
For non-English speaking people, a friendly name should be a name presented
in terms of their native alphabet. But a name like "…%A7%B2%C6%D4%E1%F5…"
does not have the presentation in its native language, and does not look
friendly to anyone.

These problems practically prevent friendly names to be defined or used for
people whose daily alphabet is totally non-ASCII, or totally don't
understand English (To them, ASCII characters could be ancient Maya
characters to you and me.) 

These explains why I think that the "urn:" scheme does not allow friendly
non-English names. There are over 90% of world population whose native
language is not English, and I think it's important to address their need
for friendly names in their own languages. And I'm proposing the "hdl:"
scheme that allows non-English names to be defined and used in a more
practical manner, without affecting the way ASCII names are defined:

First of all, under "hdl:" scheme, names can be defined using UTF-8
encoding directly. No hex encoding is needed. Using editing tools that
support UTF-8 encoding, names can be defined in any native character
without losing its native presentation.

Furthermore, in my paper sent to Unicode conference, I proposed to add
support of any standard character set encoding defined by ISO. For example,
a name using ISO-8859-x characters can be defined as:

    hdl:charset=ISO-8859-x@<handle name encoded using ISO-8859-x character
set>

This may look cumbersome, but it allows people to define URN names using
their native characters from authoring tools that support any standard
character set encoding. And the URN names defined this way can look
friendly during the exchange among its native people.

Also note that, because "hdl:" syntax supports UTF-8 natively, UTF-8
encoded names don't need this extra prefix, which I call it <Modifier>.
Because US-ASCII encoding is preserved by UTF-8, names using US-ASCII
characters do not need this <Modifier> neither.

I hope this explains a little better of  the "hdl:" scheme, and I would
welcome everyone's comments on it.

Now back to address the questions I raised:

IMHO, the issues the "hdl:" syntax trying to address are important. But the
solution proposed by the "hdl:" scheme does not fit the "urn:" scheme, as
defined in RFC2141. Somehow I got the negative impression as to the
possibility to modify the "urn:" scheme, and not sure if it's necessary. On
the other hand, URL as a general concept, allows different schemes (eg.
http, ldap, mailto, …) to be defined for various purpose. If URN is a
general concept parallel to URL, does it have to be limited to only one
"urn:" scheme, or we can define it as a general framework as URL, and
embrace all those schemes that are deemed to have a valid reason?

Thanks,
Sam
[email-masked]

From: "Sam X. Sun" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>, "=?ISO-8859-1?Q?Martin_J._D=FCrst?=" <[email-masked]>, "Karen R. Sollins" <[email-masked]>, "Michael Mealling" <[email-masked]>, "John C. Mallery" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Agenda for Washington... -- Questions on URN
Date: Sat, 6 Dec 1997 04:14:41 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

Hi, John, Michael, Karen, Martin, and Leslie:

Thank you for your responses. I hear some confusion re. our discussion, and
I would like to make them clear here. I'll then explain the technical
reasons in the next email message.

1.	The Handle System is designed in accordance with URN Functional
Requirements as defined in RFC1737, and will support the "urn:" syntax as
defined in RFC2141. 

2.	IMHO, the current "urn:" scheme has its limitations on practical use of
non-ASCII names (Please see my next email message which explains why). I'm
here proposing the "hdl:" scheme that allows non-English names to be
defined and used in a more practical manner.

3.	I further argue that since URL allows multiple schemes (eg, http, ldap,
mailto…), why is URN has to be limited to one scheme (ie. "urn:")? 

Now please read my next email to understand why I think the "urn:" syntax
has its limitations in practice, and how my proposal addresses those
issues. 
 
Thanks,
Sam
[email-masked]

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-resolution-services-04.txt
Date: Fri, 05 Dec 1997 11:23:28 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Uniform Resource Names Working Group of the IETF.

	Title		: URI Resolution Services Necessary for URN Resolution
	Author(s)	: M. Mealling, R. Daniel
	Filename	: draft-ietf-urn-resolution-services-04.txt
	Pages		: 8
	Date		: 04-Dec-97
	
Retrieving the resource identified by a Uniform Resource Identifier
(URI) [3] is only one of the operations that can be performed on a URI.
One might also ask for and get a list of other identifiers that are
aliases for the original URI or a bibliographic description of the
resource the URI denotes, for example. This applies to both Uniform
Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform
Resource Characteristics (URCs) are discussed in this document but only
as descriptions of resources rather than identifiers.
 
A service in the network providing access to a resource may provide
one or some of these options, but it need not provide all of them. This
memo specifies an initial set of these functions, to be used to
describe the functions provided by any given access service and the
requirements that must be met when those operations are encoded in a
protocol.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urn-resolution-services-04.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-resolution-services-04.txt

Internet-Drafts directories are located at:

	Africa:	ftp.is.co.za
	
	Europe: ftp.nordu.net
		ftp.nis.garr.it
			
	Pacific Rim: munnari.oz.au
	
	US East Coast: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-urn-resolution-services-04.txt".
	
NOTE:	The mail server at ds.internic.net can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-resolution-services-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-urn-resolution-services-04.txt";
	site="ds.internic.net";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Fri, 5 Dec 1997 12:19:49 +0100 (MET)
From: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>
To: "Sam X. Sun" <[email-masked]>
cc: Leslie Daigle <[email-masked]>, urn-ietf <[email-masked]>
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Sender: [email-masked]
Reply-To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>

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 sorry that I won't be able to be in Washington; I am waiting for
my visum for Japan because I will go to work there very soon.

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

In particular with respect to the '#', which in the terms of
draft-fielding-uri-syntax-01.txt separates a fragment identifier
from the URI proper in an URI reference, you are well advised
to not reuse this character in your own uri scheme. Many
implementations won't like it. For other reserved characters,
the problems are smaller, but also exist.

Also, please note that because of backwards compatibility reasons,
you cannot have a non-ASCII character as scheme-reserved, unless
you completely disallow that character from the non-reserved
syntax of your scheme, because the distinction between %-escaped
and non-escaped octets/characters above 0x7F cannot be used
to distinguish between reserved and non-reserved instances
of the same character.

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

Fortunately, I currently don't see anything that limits the use
of user-friendly names. It would be difficult anyway, as human
beings are extremely good at giving meaning to even the most
obscure number sequences.

> 	On top of this, for any global naming scheme to support friendly names, it
> should not be limited to ASCII only, but should allow any native characters
> to be used directly without hex encoding. Otherwise, it can only support
> friendly names in English, but not in other languages like Greek, Russian,
> Chinese, Japanese, Korean, etc. For example, how could anyone tell that
> %C2%B7 is a friendly name in Greek? (Note: %C2%B7 is the hex encoded  UTF-8
> encoding of a Greek symbol, code point B7 defined in ISO-8859-7.)

There are various ways to see the current limitation to hex-escaped
UTF-8. One is to say that this limitation is necessary, and should
always be kept. The other is to say that it is temporary, in a
preparation for directly encoded or directly displayed native-script
URLs. Larry has published a draft on native-script UTF-8 URLs/URIs,
and I'm working on expanding this draft and filling in more details.
I'm quite confident that we are moving into the right direction
(but we could of course move faster), and that in due time, whether
or not URLs/URNs will formally be defined as ASCII-only will not
be of interest to users, because the user interface will make the
necessary conversions.

Regards,	Martin.

Date: Thu, 4 Dec 1997 23:42:33 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Sam Sun <[email-masked]>
cc: "Rebecca S. Guenther" <[email-masked]>, "Ron Daniel Jr." <[email-masked]>, [email-masked]
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Sam,

I'm afraid I don't have the resources right now to address your reply
in the detail it deserves -- I will definitely track down the references
you've supplied.

I think others have already covered much ground on this topic, and
I'd like to add only a couple of points (in part to allay other concerns
that have been aired re. this thread):

On Thu, 4 Dec 1997, Sam Sun wrote:
> It is my believe that a Handle is a URN, and can be presented in syntax of
> either "hdl:" or "urn:hdl:". When used under "urn:hdl:" syntax, it is
> subject to the syntax rules defined by the URN Syntax draft
> (ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-05.txt). And
> when presented using "hdl:" syntax, it follows the syntax defined by the
> Handle Syntax draft
> (ftp://ds.internic.net/internet-drafts/draft-sun-handle-system-00.txt).

As I have said all along, this seems reasonable.

Now, have a look at draft-ietf-urn-nid-req-02.txt, and come to the
meeting with your comments on where you think Handles fit in to this
structure/process for registering URN namespaces!  That document is
_not_ finished, and definitely requires input from people who have
namespaces that they think belong in URN-land!

Now, for some personal opinion matter, which _might_ help clarify
where some of this confusion has erupted from:

It's worth noting that Once Upon A Time Long-Since Obscured, there
were URLs and URNs, and URLs were all prefixed by the four characters
"URL:" and URNs were to be prefixed by "URN:".  

	URL:<url-scheme><url-syntax>
	URN:<nooneknewwhat>

However, URLs were implemented long before URNs, and many schemes 
appeared, and gosh, why bother with the URL: as it was redundant?  So, 
things got abbreviated to <url-scheme><url-syntax>.  

When it came time to discuss URNs seriously, there was further discussion
of this, but "URN:" was felt to be an important part of the URN syntax
in order to distinguish these URIs from all the URL schemes that exist
today (and will exist tomorrow).  So, in it went.  

Note that the URN: was meant to distinguish the type of URI, and the
subsequent chunk of the identifier is to designate the namespace (or
scheme, if you use the URL analogy).

	URN:<namespaceid>:<namespacespecificstring>

More time has gone by, and in the name of convenience,  we talk now
of "URI schemes", and that "URN:" is just one of those schemes.  It's
been pushed down a level.

At this point, that's probably the easiest route forward, so that's fine.
But, it makes it look like there is One True Way to do URNs, whereas
there are A Thousand Blooming Flowers of URL schemes, and I'd argue
that's because they aren't actually being compared at the same level.

As I said, much of the above is personal opinion and recollection of
history, others are free to differ, but it provides a perspective
that might help clarify how limiting we feel this work is _not_.

Leslie.

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

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Thu, 4 Dec 1997 14:03:58 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Hi Sam,

There are lots of opportunities for alternatives.  The URN (by the way
the "U" stands for "uniform" not "universal" despite what you and the
NCSA people say) requirements doc permits many alternatives for
syntaxes.  It places a few requirements on those syntaxes.  Within the
IETF we have chosen one, which is now on standards track.  That one,
even in itself is not particularly restrictive and certainly allows
for an infinite number of scheme syntaxes within it.  It has it's own
set of limitation, restrictions, requirements (whatever you want to
call them) on those schemes, such as character set.  One can imagine
schemes that themselves allow for delegated determination of subspace
syntax as well.  PDIs are a good example of how and why that might be
done.  In each case, flexibility and extensibility were major
significant design criteria.  (Of course, one doesn't have to do it
that way if one wants to design a more limited scheme.)  Of course at
each stage we could have done something different and/or more
restrictive.  In addition, others can.  Someone can define alternative
persistent identifiers (in fact the PURL people did).  Furthermore,
other syntaxes could be defined to meet the URN requirements (handles
might be a good example).  Clearly more than one scheme within the
current syntax can be defined, and I believe we all now understand how
to do that for handles.  In fact, for many (or perhaps all?)
grandfathered schemes, there may need to be a 1:1 translation from
identifiers within the scheme as it exists perhaps outside the digital
world into URNs within our world.  That will be true no matter what
syntax is chosen, unless we go the Tower of Babyl route and decide
against any uniformity.

One of the distinctive characteristics of URN universe (although not
enunciated often enough in my opinion) is the design criterion that
one be able to separate URN syntax and assignment from resolution.
This means that the implementations (and for that matter design) of
resolution mechanisms can, and probably will need to be in the long
run, be independent from what the syntax of specific URNs.  (This is
one of the very interesting differences between schemes such as the
DNS and X.500 where the naming and resolution hierarchies are
coupled.)  In other words, although for the present perhaps there are
only limited resolvers (all implemented and run by CNRI) for
"urn:hdl:.." URNs, since URNs are expected to be persistent, the
resources they identify and the URNs themselves may well be needed and
probably should be usable after the end of the lifetime of CNRI,
something or someone else may take over that responsibility.  In
general, I believe that all the documents that have come out of the
URI and URN working groups have intentionally allowed for this
separation.  I keep imaging a time when network, processor, and
storage capacity are cheap and fast enough that I could simply be a
replicated resolver that knows about _ALL_ URNs.  (I realize that
there are lots of technical hurdles to building such a service, but I
find it valuable to postulate that it could exist, and perhaps aim for
it.)

The question of user friendliness is a red-herring.  We do not
prohibit nor encourage it.  The URN requirements doc says essentially
that transcribability is a requirement; in other words, one needs to
be able to type them, even if it is difficult, but, yes, our primary
objective is to make them machine friendly.  In the "Architectural
Principles" i-d (and note that that document is really about
resolution not schemes or syntax) I added the bit about HFNs because
it is pretty clear to me that there are _LOTS_ of ways to support
humans and no one is the right answer.  So we couldn't be proposing a
complete solution to that.  It was also included because truthfully,
many years ago, we probably made a mistake in calling these things
"names".  That carries too many connotations and there is a great deal
of uninformed, human-centric expectation that they _MUST_ be human
friendly because they are "names".  There is no "must" about it, and I
wanted to clarify that.  But that doesn't outlaw human friendliness
either, especially since the document never mentions requirements,
only guidelines and principles.

So with all that said, what really is your concern?  Would you have
wanted the requirements document to be different (in which case Judy
and Bill should have been more involved years ago)?  Would you have
wanted the syntax document to be different (in which case you or
whoever should have been involved when that document was being
discussed and written)?  Do you have a problem with support for
resolution (in which case, we'd better hear about that right away)?
Are you concerned because you have to encode a character or two for
transmission?  As we discussed in Munich during your talk, I believe,
there is nothing that says that if you need to encode characters for
transmission, that users ever have to see that.  You can cause them to
see whatever you think is appropriate, except that if they are outside
your universe they may not know that or choose to support that.  But
we have technologies to deal with that sort of thing.  So the real
question is whether there is something architectural that you think
has been missed (and, if so, why did none of you nor your predecessors
on this project raise it before now?)  Of course, given the agenda of
this working group, such issues may be out of place for the present,
but we'd better get them on the table.

			Karen

___________________________________________________________________
Karen R. Sollins				[email-masked]
Research Scientist				Phone: 617/253-6006
M.I.T. Laboratory for Computer Science		Fax:   617/253-2673
545 Technology Square
Cambridge, MA 02139

Date: Thu, 4 Dec 1997 13:09:48 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [URN] PDI: Change of Fragment Syntax Character
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

It seems completely reasonable to me to pick a different character to
mean something different.  In this case, client handled vs. client or
server handled fragment.  The only question is whether "|" is really
unencumbered in terms of the common operating systems and browsers.
If so, I'd say, go for it.

			Karen

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
To: [email-masked]
Date: Thu, 4 Dec 1997 10:12:45 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Sam Sun said this:
> This is exactly the point I want to make clear. That is:
> 
> URN specification SHOULD allow for various schemes using whatever syntax
> they define, and that the handle scheme (hdl:) is a particular type of URN
> scheme.
> 
> It is my believe that a Handle is a URN, and can be presented in syntax of
> either "hdl:" or "urn:hdl:". When used under "urn:hdl:" syntax, it is
> subject to the syntax rules defined by the URN Syntax draft
> (ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-05.txt). And
> when presented using "hdl:" syntax, it follows the syntax defined by the
> Handle Syntax draft
> (ftp://ds.internic.net/internet-drafts/draft-sun-handle-system-00.txt).
> 

This sounds somewhat acceptable. We have the same situation with
CIDs. There is a CID URL proposal and probably will be a CID URN namespace
proposed. The problem with this is that its going to confuse the hell
out of the consumer. Does he put urn: on the front or not? Which is 
better: a non-confused customer with full interoperability or an encoded '#'?

BUT, "hdl:" is not a URN because it isn't _uniform_. It has syntax rules
that are different from the other URNs that were specified in RFC2141. "hdl:"
is a URI at the basic level. But it is a URI that has some aspects of
naming which coincide with what the URN framework specifies. But not until you 
stick "urn:" on the front does anyone know you are following all of the 
rules that URNs say you have to follow. E.g. if I say a "hdl:" URI come 
floating by I wouldn't know how it's naming characteristics related to 
other URIs that had naming type qualities. But if you put "urn:" in front 
then I know that you are agreeing to live within the framework of the 
_Uniform_ Resource Name.  Before you did that you were just claiming to 
be a Resource Name that was encoded as a URI.

I do have one major nit to pick as well. The URN Syntax document is no
longer a draft. It is RFC2141 and is a Standards Track document. Please
refer to it as RFC2141 since the drafts are now gone and should not be
referenced.

-MM

> -----Original Message-----
> From: Rebecca S. Guenther <[email-masked]>
> To: Sam X. Sun <[email-masked]>
> Cc: Ron Daniel Jr. <[email-masked]>; [email-masked]
> <[email-masked]>
> Date: Thursday, December 04, 1997 9:15 AM
> Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
> 
> 
> >On Thu, 4 Dec 1997, Sam X. Sun wrote:
> >
> >>
> >> First of all, what I meant by implementation should really be "Syntax
> >> definition". It's true that we may never be able to address all possible
> >> syntax definitions that ever come up. But limiting URN to one particular
> >> syntax definition has the effect of rejecting other URN syntax based on
> >> other URL/URI schemes. While "urn:" scheme has its nice feature of easy
> >> input from standard English Keyboard, "hdl:" (handle system) scheme has
> its
> >> advantage of requiring less reserved/excluded characters and allowing
> >> native characters to be used without hex encoding, and the "pdi:"
> >> (persistent document identifier) scheme has been used for document
> >> identification for years.
> >
> >.....stuff deleted....
> >
> >> In summary, my point is that "urn:" syntax, as it defined now, serves
> well
> >> as one URN "syntax definition", or one URN name space. But URN as a
> general
> >> concept for persistent naming scheme, may not necessarily be restricted
> to
> >> one URI/URL scheme. Besides "urn:", we now have seen "hdl:" and "pdi:"
> >> claiming to be under the URN framework. And there could very well be
> other
> >> URI/URL schemes to be proposed to serve the same purpose, but with
> >> different syntaxes, and with their own set of implementations.
> >>
> >>
> >> Thanks much for your response...
> >> Sam
> >> [email-masked]
> >
> >I've been trying to follow these discussions and am feeling confused. I
> >always thought that the URN specification allows for various schemes using
> >whatever syntax they define, and that the handle scheme (hdl:) was a
> >particular type of URN scheme. That is how we represented it to the MARC
> >world when we requested the addition of a data element to accommodate a
> >URN.  Although the particular need was for a handle in a MARC record, our
> >intention was to accommodate URNs in general.  This message implies that
> >you have a URN or you have a handle, and a handle is not a URN. Please
> >clarify.
> >
> >Rebecca
> >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >^^  Rebecca S. Guenther                                   ^^
> >^^  Senior MARC Standards Specialist                      ^^
> >^^  Network Development and MARC Standards Office         ^^
> >^^  Library of Congress                                   ^^
> >^^  Washington, DC 20540-4020                             ^^
> >^^  (202) 707-5092 (voice)    (202) 707-0115 (FAX)        ^^
> >^^  [email-masked]                                          ^^
> >^^                                                        ^^
> >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >
> >
> >
> 

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
To: [email-masked]
Date: Thu, 4 Dec 1997 09:55:48 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Rebecca S. Guenther said this:
> On Thu, 4 Dec 1997, Sam X. Sun wrote:
> 
> > 
> > First of all, what I meant by implementation should really be "Syntax
> > definition". It's true that we may never be able to address all possible
> > syntax definitions that ever come up. But limiting URN to one particular
> > syntax definition has the effect of rejecting other URN syntax based on
> > other URL/URI schemes. While "urn:" scheme has its nice feature of easy 
> > input from standard English Keyboard, "hdl:" (handle system) scheme has its
> > advantage of requiring less reserved/excluded characters and allowing
> > native characters to be used without hex encoding, and the "pdi:"
> > (persistent document identifier) scheme has been used for document
> > identification for years.
> 
> .....stuff deleted.... 
> 
> > In summary, my point is that "urn:" syntax, as it defined now, serves well
> > as one URN "syntax definition", or one URN name space. But URN as a general
> > concept for persistent naming scheme, may not necessarily be restricted to
> > one URI/URL scheme. Besides "urn:", we now have seen "hdl:" and "pdi:"
> > claiming to be under the URN framework. And there could very well be other
> > URI/URL schemes to be proposed to serve the same purpose, but with
> > different syntaxes, and with their own set of implementations.
> > 
> > 
> > Thanks much for your response...
> > Sam
> > [email-masked]
> 
> I've been trying to follow these discussions and am feeling confused. I
> always thought that the URN specification allows for various schemes using
> whatever syntax they define, and that the handle scheme (hdl:) was a
> particular type of URN scheme. That is how we represented it to the MARC
> world when we requested the addition of a data element to accommodate a
> URN.  Although the particular need was for a handle in a MARC record, our
> intention was to accommodate URNs in general.  This message implies that
> you have a URN or you have a handle, and a handle is not a URN. Please
> clarify.
> 

Rebecca,
  You are essentially correct. The URN syntax we've specified in RFC2141
allows for each 'scheme' or namespace identifier to specify its own
internal syntax and semantics but within certain rules. These rules are
what the overall URN syntax document specifies. Those rules say nothing
about a namespaces internal syntax or semantics. Just that if you have
certain characters you have to encode them so that a) the URN can
be parsed and b) it will pass through numerous communications channels 
without being corrupted.

  From what I have been able to gather, Sam's concerns are that the
URN syntax doesn't allow for ANY syntax. I.e. the handle system desires
that the URN syntax allow for the handle to be unencoded for appearance
reasons (the # sign is a specific example I think). This is simply not 
possible due to how nearly every browser in the world acts when given 
a URI of any type. While this may not be an optimal situation for the 
handle system, it is reality and one we have to live with.

  I hope I helped. If not feel free to call me....

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

From: "Sam Sun" <[email-masked]>
To: "Rebecca S. Guenther" <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Date: Thu, 4 Dec 1997 09:41:16 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>

This is exactly the point I want to make clear. That is:

URN specification SHOULD allow for various schemes using whatever syntax
they define, and that the handle scheme (hdl:) is a particular type of URN
scheme.

It is my believe that a Handle is a URN, and can be presented in syntax of
either "hdl:" or "urn:hdl:". When used under "urn:hdl:" syntax, it is
subject to the syntax rules defined by the URN Syntax draft
(ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-05.txt). And
when presented using "hdl:" syntax, it follows the syntax defined by the
Handle Syntax draft
(ftp://ds.internic.net/internet-drafts/draft-sun-handle-system-00.txt).

Sam
[email-masked]

-----Original Message-----
From: Rebecca S. Guenther <[email-masked]>
To: Sam X. Sun <[email-masked]>
Cc: Ron Daniel Jr. <[email-masked]>; [email-masked]
<[email-masked]>
Date: Thursday, December 04, 1997 9:15 AM
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN

>On Thu, 4 Dec 1997, Sam X. Sun wrote:
>
>>
>> First of all, what I meant by implementation should really be "Syntax
>> definition". It's true that we may never be able to address all possible
>> syntax definitions that ever come up. But limiting URN to one particular
>> syntax definition has the effect of rejecting other URN syntax based on
>> other URL/URI schemes. While "urn:" scheme has its nice feature of easy
>> input from standard English Keyboard, "hdl:" (handle system) scheme has
its
>> advantage of requiring less reserved/excluded characters and allowing
>> native characters to be used without hex encoding, and the "pdi:"
>> (persistent document identifier) scheme has been used for document
>> identification for years.
>
>.....stuff deleted....
>
>> In summary, my point is that "urn:" syntax, as it defined now, serves
well
>> as one URN "syntax definition", or one URN name space. But URN as a
general
>> concept for persistent naming scheme, may not necessarily be restricted
to
>> one URI/URL scheme. Besides "urn:", we now have seen "hdl:" and "pdi:"
>> claiming to be under the URN framework. And there could very well be
other
>> URI/URL schemes to be proposed to serve the same purpose, but with
>> different syntaxes, and with their own set of implementations.
>>
>>
>> Thanks much for your response...
>> Sam
>> [email-masked]
>
>I've been trying to follow these discussions and am feeling confused. I
>always thought that the URN specification allows for various schemes using
>whatever syntax they define, and that the handle scheme (hdl:) was a
>particular type of URN scheme. That is how we represented it to the MARC
>world when we requested the addition of a data element to accommodate a
>URN.  Although the particular need was for a handle in a MARC record, our
>intention was to accommodate URNs in general.  This message implies that
>you have a URN or you have a handle, and a handle is not a URN. Please
>clarify.
>
>Rebecca
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>^^  Rebecca S. Guenther                                   ^^
>^^  Senior MARC Standards Specialist                      ^^
>^^  Network Development and MARC Standards Office         ^^
>^^  Library of Congress                                   ^^
>^^  Washington, DC 20540-4020                             ^^
>^^  (202) 707-5092 (voice)    (202) 707-0115 (FAX)        ^^
>^^  [email-masked]                                          ^^
>^^                                                        ^^
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
>

Date: Thu, 4 Dec 1997 09:15:34 -0500 (EST)
From: "Rebecca S. Guenther" <[email-masked]>
To: "Sam X. Sun" <[email-masked]>
cc: "Ron Daniel Jr." <[email-masked]>, [email-masked]
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Sender: [email-masked]
Reply-To: "Rebecca S. Guenther" <[email-masked]>

On Thu, 4 Dec 1997, Sam X. Sun wrote:

> 
> First of all, what I meant by implementation should really be "Syntax
> definition". It's true that we may never be able to address all possible
> syntax definitions that ever come up. But limiting URN to one particular
> syntax definition has the effect of rejecting other URN syntax based on
> other URL/URI schemes. While "urn:" scheme has its nice feature of easy 
> input from standard English Keyboard, "hdl:" (handle system) scheme has its
> advantage of requiring less reserved/excluded characters and allowing
> native characters to be used without hex encoding, and the "pdi:"
> (persistent document identifier) scheme has been used for document
> identification for years.

.....stuff deleted.... 

> In summary, my point is that "urn:" syntax, as it defined now, serves well
> as one URN "syntax definition", or one URN name space. But URN as a general
> concept for persistent naming scheme, may not necessarily be restricted to
> one URI/URL scheme. Besides "urn:", we now have seen "hdl:" and "pdi:"
> claiming to be under the URN framework. And there could very well be other
> URI/URL schemes to be proposed to serve the same purpose, but with
> different syntaxes, and with their own set of implementations.
> 
> 
> Thanks much for your response...
> Sam
> [email-masked]

I've been trying to follow these discussions and am feeling confused. I
always thought that the URN specification allows for various schemes using
whatever syntax they define, and that the handle scheme (hdl:) was a
particular type of URN scheme. That is how we represented it to the MARC
world when we requested the addition of a data element to accommodate a
URN.  Although the particular need was for a handle in a MARC record, our
intention was to accommodate URNs in general.  This message implies that
you have a URN or you have a handle, and a handle is not a URN. Please
clarify.

Rebecca
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^  Rebecca S. Guenther                                   ^^
^^  Senior MARC Standards Specialist                      ^^
^^  Network Development and MARC Standards Office         ^^
^^  Library of Congress                                   ^^
^^  Washington, DC 20540-4020                             ^^
^^  (202) 707-5092 (voice)    (202) 707-0115 (FAX)        ^^
^^  [email-masked]                                          ^^
^^                                                        ^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Date: Thu, 4 Dec 1997 07:04:42 -0500
To: "Sam X. Sun" <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] Agenda for Washington ...-- Questions on URN
Cc: "Leslie Daigle" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Sam,

I think the answers to your questions is interoperability.
If interoperability is important to you, then URN conformance
will help. (It may not be for proprietary schemes that
will be narrowly deployed in known environments.)

a. URN: announces that resolvers for your namespace
can be discovered by using URN discovery standards.
Without this hint, every user-agent would need to
know how to perform specialty resolution for each namespace --
which would put the URN effort back where URLs are now.

b. Conforming to URN syntax increases the probability
that your identifiers will be transported in tact through
the internet, i.e. that they will actually work!  Sticking
with least common denominator character sets increases the
likihood that a random transport link won't just drop out
a few characters from your identifier that don't happen to
exist in its worldview.

c. The PDI://  is a legacy feature because we initially deployed
the identifiers in 1994 before urn standards existed. That
legacy component was co-opted as a feature by also declaring
PDIs to be a URL, and thus, allowing existing browsers to
parse them like the familiar HTTP:// urls.

John C. Mallery
Artificial Intelligence Laboratory, Massachusetts Institute of Technology
545 Technology Square, NE43-797, Cambridge, MA 02139-4301 USA
Email: [email-masked], Phone: 617-253-5966, Fax: 617-253-5060 
WWW: http://www.ai.mit.edu/people/jcma/jcma.html

Date: Thu, 4 Dec 1997 06:18:26 -0500
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] PDI: Change of Fragment Syntax Character
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Ron Daniel has suggested using | in place of # to indicate
the start of the fragment syntax in PDIs following the lead
of XML.  Existing browsers do not transmit # delimited fragment 
specifiers in PDIs unless they are escaped.

The idea is that # has come to mean a client handled syntax
whereas | is unencumbered by legacy interpretations.

| would mean a fragment syntax that may be handled by either
the server or the client.

This seems quite reasonable to me.

Does anyone have reactions to this change?

From: "Sam X. Sun" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Agenda for Washington ...-- Questions on URN
Date: Thu, 4 Dec 1997 04:50:03 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

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 <[email-masked]>
> To: Sam X. Sun <[email-masked]>
> Cc: [email-masked]
> 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
[email-masked]

From: "Sam X. Sun" <[email-masked]>
To: "Ron Daniel Jr." <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Date: Thu, 4 Dec 1997 01:13:36 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

Hi, Ron,

Thanks for your response. 

----------
> From: Ron Daniel Jr. <[email-masked]>
> 
> At 03:23 AM 12/3/97 -0500, Sam X. Sun wrote:
> >
> >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?
> 
> IMHO, it is not possible to come up with a specification that embraces
> all persistent, location-independent, global naming schemes. The
> URN work covers a subset of them, and uses the "urn:" prefix to
> let people and software know if they are dealing with something
> in that subset.
> 

First of all, what I meant by implementation should really be "Syntax
definition". It's true that we may never be able to address all possible
syntax definitions that ever come up. But limiting URN to one particular
syntax definition has the effect of rejecting other URN syntax based on
other URL/URI schemes. While "urn:" scheme has its nice feature of easy 
input from standard English Keyboard, "hdl:" (handle system) scheme has its
advantage of requiring less reserved/excluded characters and allowing
native characters to be used without hex encoding, and the "pdi:"
(persistent document identifier) scheme has been used for document
identification for years.

I agree with you that there might be no one specification or syntax that
could embrace all persistent, location-independent, global naming schemes.
But this doesn't mean we have to pick one and reject all others. RFC1737
(URN requirement) does define URN to be limited to "urn:" scheme. But "URN
Syntax" draft (draft-ietf-urn-syntax-05.txt, section 2) starts to define
all URN have the syntax of:  URN ::= "urn:" NID ":" NSS. And this is where
get me confused.

> Second, this is not tied to one particular "implementation". The
> URN syntax document specifies a syntax, but there is no tie to a
> particular resolution mechanism. Instead, clients may use any mechanism
> for resolving the identifier that they want. NAPTR and THTTP are
> provided in case people wnat to use them, but the Handle system could
> just as easily be used.
> 

Again, I'm sorry for the confusion made by the word "implementation". It
should be "syntax definition".  On the other hand, the implementations
mentioned above are constraint to the syntax defined by the "urn:" scheme.
Thus if the syntax has any limitation, so would be the implementations that
implement it.

In summary, my point is that "urn:" syntax, as it defined now, serves well
as one URN "syntax definition", or one URN name space. But URN as a general
concept for persistent naming scheme, may not necessarily be restricted to
one URI/URL scheme. Besides "urn:", we now have seen "hdl:" and "pdi:"
claiming to be under the URN framework. And there could very well be other
URI/URL schemes to be proposed to serve the same purpose, but with
different syntaxes, and with their own set of implementations.

Thanks much for your response...
Sam
[email-masked]

Date: Wed, 3 Dec 1997 23:32:34 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: "Sam X. Sun" <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

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
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

Date: Wed, 03 Dec 1997 12:39:05 -0700
To: "Sam X. Sun" <[email-masked]>, "Leslie Daigle" <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Cc: <[email-masked]>
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

At 03:23 AM 12/3/97 -0500, 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:
>
>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?

IMHO, it is not possible to come up with a specification that embraces
all persistent, location-independent, global naming schemes. The
URN work covers a subset of them, and uses the "urn:" prefix to
let people and software know if they are dealing with something
in that subset.

Second, this is not tied to one particular "implementation". The
URN syntax document specifies a syntax, but there is no tie to a
particular resolution mechanism. Instead, clients may use any mechanism
for resolving the identifier that they want. NAPTR and THTTP are
provided in case people wnat to use them, but the Handle system could
just as easily be used.

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:[email-masked]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545  

From: "Sam X. Sun" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Agenda for Washington Meeting -- Questions on URN
Date: Wed, 3 Dec 1997 03:23:49 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

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:

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? 

	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. 

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

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.

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. 

	On top of this, for any global naming scheme to support friendly names, it
should not be limited to ASCII only, but should allow any native characters
to be used directly without hex encoding. Otherwise, it can only support
friendly names in English, but not in other languages like Greek, Russian,
Chinese, Japanese, Korean, etc. For example, how could anyone tell that
%C2%B7 is a friendly name in Greek? (Note: %C2%B7 is the hex encoded  UTF-8
encoding of a Greek symbol, code point B7 defined in ISO-8859-7.)

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

Regards.
Sam
[email-masked]

From: "Sam Sun" <[email-masked]>
To: <[email-masked]>
Subject: [URN] Handle System namespace draft...
Date: Mon, 1 Dec 1997 15:01:51 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>

Greetings everyone,

As some of you may already know, a new IETF draft on the Handle System is
put out last week. The draft is available on line at:

ftp://ds.internic.net/internet-drafts/draft-sun-handle-system-00.txt

The Handle System is a general persistent naming system. It meets all the
URN functional requirements as outlined in RFC1737. However, Handle System
allows a broader syntax than is envisaged in RFC2141 (urn syntax) and
RFC1737 (urn requirement), but can be constrained to support the URN syntax
(eg. urn:hdl: ) as defined in RFC2141.

The syntax of Handle namespace is different from URN syntax in the following
ways:

1. Handle, as a universal resource name, is based on UTF-8. This allows
Handles to be specified using any native language character set, so that
people speaking any language can define Handles in terms of their native
character set.  RFC1737/2141 defines URN using a subset of ASCII, and all
other native characters will have to be hex encoded.

2. The Handle namespace by itself does not require any reserved/excluded
characters. It is defined independent of URL. Names from real world naming
scheme, such as SICI, can be directly mapped into the Handle namespace. When
used in the WWW context however, it may impose some encoding restrictions
depending on the particular URL scheme in use.

3. In addition to the URN specified URL scheme ( urn:hdl: ), Handles can be
specified using URL scheme “hdl:”. Under “hdl:” scheme, it defines a minimum
set of reserved character set, and allows Handle names be preceded with a
<Modifier> (refer to draft for detail).

4. Handle syntax proposes a concept of <Modifier> that can be used with
Handles or other URNs in real world applications. The <Modifier> is located
in front of the Handle name, separated by “@” (refer to the draft for
detail). This may not seem to be conventional, but it really opens up the
door for defining preferred operations and/or characteristics of the
underlying Handle or URN, without posing any extra reserved/excluded
character in its namespace.

All these differences are based on the fundamental concept that Handle
System namespace is defined independent from the URL namespace. URL is
considered as a particular application of Handle name. By separating Handle
namespace from URL namespace, it allows Handles be defined with a much
richer character set, and be defined by any native language character set in
the world.

The URN and Handle System are all aimed at providing a solution for global
unique, persistent, and location independent naming space. The expertise of
this working group would help us tremendously in our future development. Any
comments and suggestions from this working group are extremely appreciated.

Regards,
Sam
[email-masked]