Subject: [URN] WG Last Call -- URI Services document
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Date: Fri, 31 Oct 1997 18:02:56 -0500 (EST)

The editors tell me this document is stable,  so it's time to do
a "working group last call" on:

	draft-ietf-urn-resolution-services-03.txt
        (URI Resolution Services Necessary for URN Resolution)

ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-resolution-services-03.txt

If there are any issues, please bring them up on the list or do the authors
directly, by November 14 (2 weeks).  If nothing major is brought up,
the document will then be recommended as an Informational RFC to the
ADs.

Leslie.

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

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

Date: Fri, 31 Oct 1997 15:20:10 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Keith Moore <[email-masked]>
cc: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: draft-fielding-uri-syntax-00 
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Fri, 31 Oct 1997, Keith Moore wrote:
> 
> Would one of the URN group chairs or authors be willing to 
> suggest, by private mail to Roy, appropriate wording changes?

I will look at the document.  I will either have specific wording changes
of the nature you suggest, or concrete concerns that I would like to hear
addressed, in consensus-fashion, on the URN/URI mailing lists.

Leslie.

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

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

From: "Sam Sun" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: [URN] URN/URL spec issues...
Date: Fri, 31 Oct 1997 13:10:57 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>

Hi, Roy,

In reading the proposed drafts on URI and URL (v09), I have several issues
that I would like to get clarified:

1. Should the reserved character set be reconsidered for URL, or why such a
big set of reserved characters? Your draft states that "Characters in the
'reserved' set are not reserved in all contexts". I think it's more
appropriate to say that reserved characters are defined on a per URL scheme
bases. This is because some URL schemes may require more reserved characters
because of their more complicated <scheme-specific-part>, while other URL
schemes may need no reserved characters at all, and making hex encoding is a
totally unnecessary overhead. The URL is defined as a super set covering all
URL schemes, and so it should make the least restrictions.

2. Similar issues goes to URN. Are we defining URN as a specific global
naming scheme implementation, or as a guideline specification for the set of
global naming systems? If URN is intended as a guideline for a set of URN
specifications, it should not impose such a restricted character set,
neither so many reserved characters.

3. What is URI? Is it intended for the common denorminator of URL and URN,
or for the super set specification for both of them?

4. Following your earlier thread, URL is for locator, not necessarily
location. And the semantics of any particular URL should be defined by the
corresponding URL scheme. Hence when defined properly, certain URL schemes
could very well be used as an implementation of URN, that is, locate by name
instead of by location. Is this the common understanding or have I missed
some point here?

-Sam
[email-masked]

-----Original Message-----
From: Roy T. Fielding <[email-masked]>
To: [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>;
[email-masked] <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Date: Thursday, October 30, 1997 3:13 AM
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs

>Just to see what it would be like, I rewrote the URL spec into a URI spec.
>The result is at
>
>   http://www.ics.uci.edu/~fielding/url/uri.txt
>
>I am not very happy with it, since the additional terms tend to cloud
>the implementation advice.  I could fix that by calling everything a URL
>except in the Introduction, but it probably isn't worth the effort.
>Others may feel differently, so give it a look if you care about this
>issue.
>
>So, my feeling is that draft 09 is the final URL draft and it should be
>sent to the IESG now.  I'd appreciate it if people using/developing the
>latest versions of URL-enabled applications could run the tests on
>
>   http://www.ics.uci.edu/~fielding/url/test1.html
>
>and send me the results.  We need to compile a list of implementations
>for each URL "feature" in order to progress to Draft Standard.
>
>....Roy

From: Keith Moore <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] draft-fielding-uri-syntax-00 
Date: Fri, 31 Oct 1997 00:14:13 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

Roy,

http://www.ics.uci.edu/~fielding/url/uri.txt
mostly looks okay to me.

I think the URN people will want slightly different language
to distinguish between URLs and URNs: e.g. URNs are distinguished
not only because there is an extra resolution step, but also in
the rules for assignment and use that are designed to make them
more likely to be suitable as long-term identifiers.  

In the section on relative URIs, you might want to explicitly
say that some schemes do not use relative URIs.

But that's all I found on a quick glance-through.
If you can tweak the URN description slightly, I'd say ship it.

Would one of the URN group chairs or authors be willing to 
suggest, by private mail to Roy, appropriate wording changes?

Keith

Date: Thu, 30 Oct 1997 22:50:10 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: "Roy T. Fielding" <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Just what I'm looking for! [was: The UR* scheme registry, Citing URL/URI specs]
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Roy T. Fielding wrote:
> 
> Just to see what it would be like, I rewrote the URL spec into a URI spec.
> The result is at
> 
>    http://www.ics.uci.edu/~fielding/url/uri.txt
Last Modified: Thursday, October 30, 1997 7:26:21 GMT

I just got around to reading this carefully.

> I am not very happy with it,

I am! This is JUST what I need!

In particular, the HTML 4 spec needs
the term URI-reference as described therein.

I'm quite confident that TimBL would prefer to have
his name on this document than on the one with
URL in the title. (I'll get him to confirm if
anybody really cares.)

> since the additional terms tend to cloud
> the implementation advice.  I could fix that by calling everything a URL
> except in the Introduction, but it probably isn't worth the effort.
> Others may feel differently, so give it a look if you care about this
> issue.

Now... if the editing-fairy will similarly sprinkle URI-dust
on the process draft (and if this document goes forward in
place of the one with URL in the title), I'll be all set!

> So, my feeling is that draft 09 is the final URL draft and it should be
> sent to the IESG now.

"should be sent..." who does the sending?
you're the editor, and there's no WG chair, so that's you, no?

-- 
Dan
http://www.w3.org/Architecture/

Date: Thu, 30 Oct 1997 10:21:26 -0500
From: <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Sender: [email-masked]
Reply-To: <[email-masked]>

Roy T. Fielding writes:
 > Just to see what it would be like, I rewrote the URL spec into a URI spec.
 > The result is at
 > 
 >    http://www.ics.uci.edu/~fielding/url/uri.txt

 > I am not very happy with it, since the additional terms tend to cloud
 > the implementation advice.  I could fix that by calling everything a URL
 > except in the Introduction, but it probably isn't worth the effort.
 > Others may feel differently, so give it a look if you care about this
 > issue.

I have mixed feelings about this.  On the one hand, the URI label at
least puts both URLs and URNs under the same abstract umbrella.  On the
other hand, it lends credence to the notion that there is a technical
difference between URLs and URNs.  The only argument for the technical
distinction in this draft is:

   A URN differs from a URL in that at least one name resolution pass is
   required in order to access a resource, thus providing the ability to
   ensure the identifier's persistence via a level of redirection. 

I used to argue that this at-least-one-redirection criteria is the only
remaining distinction between names and locations, but I have since then
dropped even that.  I.e., a URN could resolve "directly" to a resource
with no intermediary URL or URC.  (Note: No defense for that claim given
here.)  What gives a URN persistence is the *possibility* to instead
resolve to a redirection to another URI (either another URN or a URL).
But HTTP URLs give you the same possibility.

I would replace the above paragraph with the following argument for a
non-technical distinction:

   A URN differs from a URL in that a URN is intended to remain globally
   unique and persistent long after the resource it refers to ceases to
   exist or becomes unavailable.

This non-technical distinction seems to agree with Keith Moore's
argument that URNs are really for humans.  We could leave it at that or
add some further explanation, which perhaps gets too close to the
controversy:

   A URN should be associated with a global, persistent service for
   resolving it or returning a redirection to another URI.

There continues to be confusion (or a difference of opinion at least)
about the key term "resolution".  Those who believe URNs are not
technically different from URLs think of the process of looking up
resolvers for a URN as just one part of the whole "resolution" process,
whereas those who believe there is a distinction between URNs and URLs
see the look-up-resolvers step as something other than resolution
itself.  They also believe that looking up an identifier in a cache is not
part of resolution, so it is not clear to me what resolution really
could be in their minds.

So until we can agree on what "resolution" is, I expect we won't agree
on URNs vs URLs, or whether URIs are a useful concept as distinct from
URNs or URLs.

--
Daniel LaLiberte
[email-masked]

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
To: [email-masked] (Roy T. Fielding)
Date: Thu, 30 Oct 1997 09:34:54 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Roy T. Fielding said this:
> >> Please note that the "L" in "URL" represents "Locator", not "Location".
> >> Any naming scheme that requires there exist some mechanism for resolution,
> >> whether or not the mechanism is currently in operation, changes over time,
> >> or subject to multiple levels of indirection, is a locator.
> >
> >URNs never required a mechanism for resolution.
> >
> >> There do exist names that are not locators, but those names are not URNs.
> >
> >Actually, unless the documents have changed the design was that the URN
> >need not have a resolution method.
> 
> That's what I thought too, until RFC 2141 went up for last call.  E.g.,
> 
>    7. Functional Equivalence in URNs
> 
>       Functional equivalence is determined by practice within a given
>       namespace and managed by resolvers for that namespeace.
> 
> which in my mind is the same as requiring a resolution method.  There is
> no value in the "urn" scheme if it doesn't define functional equivalence.
> 

Hmm... then we should have done a better job on that section. The document
_should_ have had nothing to say about resolution but I guess it snuck in.

I wonder if that's fixable...

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

To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Date: Wed, 29 Oct 1997 23:58:28 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

>> Please note that the "L" in "URL" represents "Locator", not "Location".
>> Any naming scheme that requires there exist some mechanism for resolution,
>> whether or not the mechanism is currently in operation, changes over time,
>> or subject to multiple levels of indirection, is a locator.
>
>URNs never required a mechanism for resolution.
>
>> There do exist names that are not locators, but those names are not URNs.
>
>Actually, unless the documents have changed the design was that the URN
>need not have a resolution method.

That's what I thought too, until RFC 2141 went up for last call.  E.g.,

   7. Functional Equivalence in URNs

      Functional equivalence is determined by practice within a given
      namespace and managed by resolvers for that namespeace.

which in my mind is the same as requiring a resolution method.  There is
no value in the "urn" scheme if it doesn't define functional equivalence.

Grump.  Somebody should stick a spell checker in the RFC process --
I noticed a few weeks ago that the "Standard Copyright Notice" for all
RFCs has misspelled "implementation".

....Roy

To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Date: Wed, 29 Oct 1997 23:35:21 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

Just to see what it would be like, I rewrote the URL spec into a URI spec.
The result is at

   http://www.ics.uci.edu/~fielding/url/uri.txt

I am not very happy with it, since the additional terms tend to cloud
the implementation advice.  I could fix that by calling everything a URL
except in the Introduction, but it probably isn't worth the effort.
Others may feel differently, so give it a look if you care about this
issue.

So, my feeling is that draft 09 is the final URL draft and it should be
sent to the IESG now.  I'd appreciate it if people using/developing the
latest versions of URL-enabled applications could run the tests on

   http://www.ics.uci.edu/~fielding/url/test1.html

and send me the results.  We need to compile a list of implementations
for each URL "feature" in order to progress to Draft Standard.

....Roy

Date: Wed, 29 Oct 1997 16:03:56 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: "David G. Durand" <[email-masked]>
CC: Larry Masinter <[email-masked]>, Al Gilman <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] development track for "where-it-says"
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

David G. Durand wrote:
> 
> The XLL linking language

http://www.w3.org/TR/WD-xml-link-970731

-- 
Dan Connolly, W3C Architecture Domain Lead
Always cite a source!
http://www.w3.org/People/Connolly/#cite

Date: Wed, 29 Oct 1997 16:31:41 -0800
From: [email-masked] (David G. Durand)
To: [email-masked], [email-masked] (Larry Masinter), Al Gilman <[email-masked]>
Subject: Re:  [URN] development track for "where-it-says"
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (David G. Durand)

The XLL linking language has a very simple literal string match in its
locator language (whose expressions _can_ be placed in the fragment
identifier of a URL). It also has a lot of structural operations that
don't make much sense for non-XML documents, of course.

The current URL architecture forces you to decide if things are server
side (in the URL) or client-side (in the fragment ID). At one point
XML had added an additional delimiter ("|", I believe) to express that
the application is free to decide.

I'm behind on the drafts, so this may have changed -- and the drafts
may not currently reflect the editor's most recent thinking, but I'm
not aware that this aspect has changed from what I'm describing.

   -- David
xvip
------------------------------------------+----------------------------
David Durand                 [email-masked]| [email-masked]
Boston University Computer Science        | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/  | http://dynamicDiagrams.com/
                                          | MAPA: mapping for the WWW

Date: Wed, 29 Oct 1997 14:36:35 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: Al Gilman <[email-masked]>
CC: Larry Masinter <[email-masked]>, [email-masked], [email-masked], [email-masked], Gordon Irlam <[email-masked]>
Subject: [URN] Re: development track for "where-it-says" [patented?]
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Al Gilman wrote:
> 
> To do a little forward thinking, and follow up on what Larry Masinter said:
> 
> > The "#fragment" notation is only used for named components.
> >
> 
> Makes a lot of sense to me.
> 
> My initial stab at syntax for "where-it-says" was a
> searchpart along the lines of ...?find="string-to-match" .

Would you please research the www-talk archives or whatever
to find the earliest dicussion of this technique that you can
find? I have recently
been informed that there is a patent application[1] out
on this idea. I'm appalled that Nielsen would claim
credit for this idea, which has been kicked around on
public mailing lists for years.

Yikes! Issued Aug 19 1997?

[1] 659729 : Method and system for
implementing hypertext scroll attributes 
INVENTORS: Nielsen; Jakob, Atherton, CA
ASSIGNEES: Sun Microsystems, Inc., Mountain View, CA
ISSUED: Aug. 19, 1997
FILED: Feb. 1 , 1996
http://patent.womplex.ibm.com/details?patent_number=5659729

-- 
Dan Connolly, W3C Architecture Domain Lead
http://www.w3.org/People/Connolly/
phone://1/512/310-2971

From: Al Gilman <[email-masked]>
Subject: [URN] development track for "where-it-says"
To: [email-masked] (Larry Masinter), [email-masked]
Date: Wed, 29 Oct 1997 14:54:04 -0500 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Al Gilman <[email-masked]>

To do a little forward thinking, and follow up on what Larry Masinter said:

> The "#fragment" notation is only used for named components.
> 

Makes a lot of sense to me.

My initial stab at syntax for "where-it-says" was a
searchpart along the lines of ...?find="string-to-match" .

What I have learned from this discussion is that I need to start
with the HTML community.

If I can interest HTMLx development in exporting a reliable (i.e.
consistent across browsers) string-matching search/location
method for HTML, I hope that the URL specs won't have narrowed to
the point where there is no reasonable syntax by which to ask for
it.  

I believe that the XML project is already working on
intra-document locators in XLL although I am not sure that they
provide any sort of a pattern match yet.

-- Al Gilman

PS: I know that searchparts are presently server-side functions
but I don't immediately see that extending them to be sometimes
done client-side poses any real conflict.

Date: Mon, 27 Oct 1997 19:25:57 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Leslie Daigle <[email-masked]>
CC: Al Gilman <[email-masked]>, [email-masked], Klaus Weide <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

The "#fragment" notation is only used for named components.

A lot of us have, at some point, imagined using it for more: byte ranges,
pages, chapters, hytime designators, etc. However, I've come to the conclusion
that doing so is inappropriate, and we should leave it alone. Client-side
sub-location is likely to be scheme specific.

With that restriction, #fragment works as well for URNs as it does for
URLs -- the creator of the work assigns names to elements that are intended
to be named, and if the work changes enough that the names disappear, well,
it's no different from any other kind of incompatible modification that
could be made.

> My point is that if all of the URL syntax/semantics is to be applied
> to URIs in general, a careful and informed analysis by people who understand
> what _has_ been done in _both_ areas is necessary.  And, I don't see
> that in this discussion. 

I'm willing to assert that I have an 'informed' analysis (as someone who
has read as much mail on the topic of URLs and URNs as anyone else on the
planet). I don't see any reason to *not* claim that a URN is a special
kind of a URL, which, like many other URL schemes, sets its rules for
the syntax & semantics of the scheme-specific part.

> Bear in mind that with URNs you are not referring to a single media
> type -- a single URN _can_ refer to an ascii file, a PS file, a word
> document, a bitmapped image of a page, etc.  You can't even reliably
> define "paragraph", "page", "file". 

Bear in mind that with URLs you are not necessarily referring to a single
media type -- a single URL _can_ refer to an ascii file, a PS file, a word
document, a bitmapped image of a page, etc. It can refer to a page in
French and a page in English, depending on the language preferences of
the person that accessed it. You can't even reliably define "paragraph",
"page", "file". Fortunately, none of those terms are required to be
defined by any of the mechanisms in the URL syntax & semantics.

> What I have seen done with the URL syntax/semantics spec in the past is
> that any feature in it that is described as "optional" then becomes _expected_
> of any "scheme" that falls within its purview.  E.g., people would
> expect retrofitted implementations of "# fragment" semantics to URN identifiers
> because the spec says they _could_.  That's a lot of  baggage that I
> don't see URNs needing to inherit.

So, who expects #fragment to work with "telnet:" URLs? I don't believe
it is reasonable to avoid a design just because someone who hadn't
actually read the spec might guess that it said something that it didn't.

The only constraint the URL document places on URNs is syntactic: don't
use the reserved characters for purposes different than they're used for
in URLs. That is, it assigns semantics to the syntactic characters ("/ means
hierarchy") and that assignment of semantics should be there for URNs too:
don't use "/" for, say, delimiting the authority's private key. That's
a good idea.

I don't see any reason to change draft-fielding-url-syntax-09.txt again,
as what it says is fine as far as it goes.

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

From: Keith Moore <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
cc: [email-masked], Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Date: Mon, 27 Oct 1997 23:27:44 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

I don't want to get in the battle of whether or not a URN is a kind 
of URL.  Like it or not, the difference is important to some people.
The difference may be less one of definition and more one of 
perception.  I doubt we could get everyone to agree on a precise
definition of URLs, much less whether URNs are a subset of URLs.

We could even think of it as a marketing ploy: the URN proponents 
want to establish that URNs are used differently than other kinds 
of URLs; they think having a different name and a slightly different
(though compatible) syntax will help fix the difference in people's
minds.  Maybe it will, maybe it won't, but they have good reasons for
wanting to do so, and it seems worth a try.

I suspect the meanings of URN and URL, like most words, will change
over time as new ways get found to use the old identifiers.
(and we'll change the meanings of the letters to fit the new meanings)

> I can easily change the URL spec such that it covers all locators and
> still gives autonomy over the "urn" scheme's namespace to the set of
> URN RFCs.  If Keith gives the okay (I believe Harald has already suggested
> it more than once), then I'll do that later this week.

Can you be more specific about what changes are you proposing ?
(I don't want to open up another long-running political discussion)

Keith

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
To: [email-masked]
Date: Mon, 27 Oct 1997 22:52:20 -0500 (EST)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Roy T. Fielding said this:
> One of the nice things about being out with a cold for three days
> is you get to see the tail end of these conversations before being
> able to reply.

Nice to hear from you. I was beginning to wonder where you were these days!

I just had to quible on one of your points. The rest are old arguments
that we both know by heart.

> Please note that the "L" in "URL" represents "Locator", not "Location".
> Any naming scheme that requires there exist some mechanism for resolution,
> whether or not the mechanism is currently in operation, changes over time,
> or subject to multiple levels of indirection, is a locator.

URNs never required a mechanism for resolution.

> There do exist names that are not locators, but those names are not URNs.

Actually, unless the documents have changed the design was that the URN
need not have a resolution method. The design was that URNs be defined without 
ever mentioning a resolution mechansim. Resolution mechanisms were proposed
but they were seperate documents that had no bearing on the identifiers
themsevles. The idea was to make all URNs into names that are not
locators.

E.g. the entire point was that URNs only do one thing: name something.
So in that sense they are not Locators. They are Identifiers.

If you define a seperate resolution mechanism and use it to find
things that claim to have that name then you might have a Locator but
that idea applies not to the Identifier but to what your are using some
resolution/database lookup process for.

I'll shutup now...

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

To: [email-masked]
cc: Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Date: Mon, 27 Oct 1997 18:04:43 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

One of the nice things about being out with a cold for three days
is you get to see the tail end of these conversations before being
able to reply.

When I agreed to revise and combine the URL specifications over a year ago,
the first question I asked of the other authors is whether I should write
it as the URI syntax or the URL syntax.  The question of whether or not
the two are equivalent was never an issue --- the reason I asked the question
was to determine if it was politically feasible to make the specification
match the URI/URL/URN design, or if it would be better to maintain the
artificial distinction for the purpose of getting the spec out faster.
A year later, it is clear we made the wrong choice.

Leslie Daigle writes:
>By the way -- note that this is the 
>
>	"Uniform Resource Locators (URL): Generic Syntax and Semantics"
>
>draft, and it's the "and semantics" parts that concerns me particularly
>when talking about sweeping URN syntax into this and calling it the URI
>syntax document.

The definition of URN given in RFC2141 and its relatives is a subset of
the definition of a URL scheme, both in terms of semantics and syntax.
The URN requirements apply additional constraints on the naming authority
and the syntax, but those constraints are no different than what can be
applied to any new URL scheme.  URNs are already bound by the syntax of
a URL in order to fulfill one of the earliest requirements --- that URNs
be usable in the same context as one would use a URL reference.

Please note that the "L" in "URL" represents "Locator", not "Location".
Any naming scheme that requires there exist some mechanism for resolution,
whether or not the mechanism is currently in operation, changes over time,
or subject to multiple levels of indirection, is a locator.
There do exist names that are not locators, but those names are not URNs.

The argument that fragment identifiers might not be useful with URNs
is ridiculous.  A fragment is a client-side specialization of the
identification of a resource, and thus is independent of both URLs and URNs
except for the fact that they occur within the same data field.
They are a property of some URL references, and thus a required property
of some URN references.  RFC2141 does recognize that requirement, even
if it does so in a particularly wishy-washy fashion that should have been
unacceptable in any Proposed Standard.

Whether or not a URN is allowed to be used in relative form is not
relevant.  There are many URL schemes which have no use for relative
forms.  There are many demonstrated uses for abbreviated names, so it
is a pity that the "urn" syntax was chosen to exclude their possibility
using the standard relative URL algorithm.  Instead, you will be stuck
with application-dependent macros.  They will be created whether you like
them or not --- the desire to abbreviate is part of the human psyche
and not subject to IETF standardization.

>#2 is a definite "no"; URN namespaces are _not_ just like URL schemes.  THey
>have implications of ownership, maintaingin registries and validation
>services, and a whole set of requirements centred on uniqueness, etc.

Those are all scheme-dependent requirements.  The only thing the "urn"
scheme does is gather a bunch of naming authorities under a single,
as-yet-undefined set of requirements.  There is no RFC that defines
those requirements, which is why I didn't reference anything beyond
the original Informational spec.  If the "urn" scheme is to be useful,
it will need to require things which some existing name services do not
support, and thus there will exist location-independent URLs which
are not URNs.  Heck, that is already the case today.

I do agree that URN NIDs are not URL schemes, and should not be in
the same registry.  They don't even have the same syntax.

If this sounds a bit confusing, please recall that I argued many times
against the URN WG using the name "urn" for what was clearly only one
possible scheme for defining names.  Monopolizing the namespace is
counterproductive.

I can easily change the URL spec such that it covers all locators and
still gives autonomy over the "urn" scheme's namespace to the set of
URN RFCs.  If Keith gives the okay (I believe Harald has already suggested
it more than once), then I'll do that later this week.

 ...Roy T. Fielding
    Department of Information & Computer Science    ([email-masked])
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-1715
    http://www.ics.uci.edu/~fielding/

Date: Mon, 27 Oct 1997 21:28:53 +0100 (MET)
From: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>
To: Leslie Daigle <[email-masked]>
cc: Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>

On Mon, 27 Oct 1997, Leslie Daigle wrote:

> Well, there are 2 separate questions on the table:
> 
> 	1.  Does "URN:" appear in this registry as one UR{I|L} scheme?
> 
> 	2.  Do URN namespaces (i.e., that part that appears after the URN:
> 	    e.g., urn:ietf:<blah>) get registered in that registry.  You
> 	    suggest not; Larry later suggested he thought they ought.

> #2 is a definite "no"; URN namespaces are _not_ just like URL schemes.  THey
> have implications of ownership, maintaingin registries and validation
> services, and a whole set of requirements centred on uniqueness, etc.  I'm
> sorry to be so vague here -- this is exactly the part that the URN WG
> is trying to nail down now (and if I could be less vague, I'd be halfway
> to having the I-D written :-)

I guess what will happen is that URN namespaces will be registered in
a separate registry, but in a registry that will be kept in close
coordination with the URL scheme registry. Should IANA for some
reason not qualify as the top URN registry maintainer (they maintain
a lot of other stuff, so I don't know why they wouldn't, but anyway),
it would definitely be a good idea to have them keep a "shadow
registration" reflecting the registered URNs for further reference.

Regards,	Martin.

Date: Mon, 27 Oct 1997 14:54:39 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Al Gilman <[email-masked]>
cc: [email-masked], Klaus Weide <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

If you want to have a discussion about whether or not fragment identifiers
make sense in URNs, I suggest that chopping the [email-masked] mailing
list out of the CC list was poor optimization...

On Fri, 24 Oct 1997, Al Gilman wrote:
> 
> Various of the schemes now called URLs make more sense as names
> than as locators.  
> 
> And relative references such as 'ibid' and 'loc_cit' abound in
> the natural-language reference vocabulary we should try to serve

The problem is not whether, in an abstract sense, relative references
make sense in conjunction with names rather than locators.  The issue
is one of whether or not the defined implementation of "# fragments"
for URLs is applicable to the defined implementation of URNs.

There is a long discussion on the topic that you will find in the URN
working group's mail archive:

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

You can review this, and the URN documents, if you really want to pursue
this thread.

My point is that if all of the URL syntax/semantics is to be applied
to URIs in general, a careful and informed analysis by people who understand
what _has_ been done in _both_ areas is necessary.  And, I don't see
that in this discussion. 

For example, 
> If URNs don't like the fragment rules that go with URLs, it is
> probably because they are not really accessing the same media
> types.  If you can't index into a resource after retrieving it by
> an URN with the same semantics as if you retrieved it with an
> URL, you just need to define a new object class with appropriate
> interior access methods and register that class as an internet
> media type and voila -- URNs with fragments.

Bear in mind that with URNs you are not referring to a single media
type -- a single URN _can_ refer to an ascii file, a PS file, a word
document, a bitmapped image of a page, etc.  You can't even reliably
define "paragraph", "page", "file".  The only level at which 
relative references might make sense within URNs is between URN-identified
objects (e.g., volumes in a a series) -- i.e., media-type-independent
references.

Note that I am _not_ saying relative references _can't_ be useful and
usable with URNs.  But any previous discussion has suggested that it
would be very namespace-specific (and by "namespace", I mean a subscheme
within the space of URN:, for the uninitiated), and there will be namespaces
for which it is not relevant.

What I have seen done with the URL syntax/semantics spec in the past is
that any feature in it that is described as "optional" then becomes _expected_
of any "scheme" that falls within its purview.  E.g., people would
expect retrofitted implementations of "# fragment" semantics to URN identifiers
because the spec says they _could_.  That's a lot of  baggage that I
don't see URNs needing to inherit.

> Hope this helps.  I don't think that the URL spec ties the hands
> of the URN inventors to any significant degree.

Well, what you are saying here is that you believe you could implement _a_
naming system within the constraints of the URL specifications, not that
a system that met the requirements of URNs (as has been defined by the
URN working group) is not constrained by this spec.

Leslie.

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

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

Date: Mon, 27 Oct 1997 14:33:39 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Dan Connolly <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

[At this point, many other people have replied to several points in this
message, so rather than just adding "me too" to what has been said adequately,
I'll only address points that still seem to be outstanding.  Dan, if
you still want more detail on things I leave out, please let me know. -- LLD]

On Fri, 24 Oct 1997, Dan Connolly wrote:
> Short version:
> 
> Leslie Daigle wrote:
> > >      Syntax draft says "URIs are covered by other specs".
> > >      What other specs?
> > 
> > RFC2141
> 
> Hmmm.... checking...
> The term URI does not occur in RFC2141.
> So that's no help.

Well, I responded to the larger excerpt from the "syntax" draft (which
I assume is draft-fielding-url-syntax-09.txt) which says:

   "The syntax and semantics of other
    URIs are defined by a separate set of specifications, although
    it is expected that any URI notation would have a compatible syntax."

RFC2141 is an appropriate reply to _this_ quote, as it says that _other_
URI specs are defined elsewhere.  I had misunderstood that you had
read it to mean that _URI_ syntax was covered elsewhere.

By the way -- note that this is the 

	"Uniform Resource Locators (URL): Generic Syntax and Semantics"

draft, and it's the "and semantics" parts that concerns me particularly
when talking about sweeping URN syntax into this and calling it the URI
syntax document.

> > > don't reflect that. The IANA registry[1] claims to be
> > > a URL scheme registry, rather than a URI scheme
> > > registry. So I wonder... is it expected that urn: will
> > > appear in that registry?
> > 
> > Not necessarily.
> 
> Can I please have a clear "yes" or "no" from your
> own personal perspective? Do you expect it to
> go in that list or not?

Well, there are 2 separate questions on the table:

	1.  Does "URN:" appear in this registry as one UR{I|L} scheme?

	2.  Do URN namespaces (i.e., that part that appears after the URN:
	    e.g., urn:ietf:<blah>) get registered in that registry.  You
	    suggest not; Larry later suggested he thought they ought.

If the IANA registry is truly to be the URI registry, and an informed
discussion (i.e., by people who know about that registry AND the current
state of URNs) shows this will not restrict the usage of URNs, then sure,
the answer to #1 is yes, urn: can/should appear there (and a ghost of myself 
from a couple of years ago just passed out in shock that I said that ;-)

#2 is a definite "no"; URN namespaces are _not_ just like URL schemes.  THey
have implications of ownership, maintaingin registries and validation
services, and a whole set of requirements centred on uniqueness, etc.  I'm
sorry to be so vague here -- this is exactly the part that the URN WG
is trying to nail down now (and if I could be less vague, I'd be halfway
to having the I-D written :-)

> But I haven't run into one that told me how they're
> currently using them (except for PURLs, which use the http:
> scheme,  [...]

They exist -- if you need specific pointers, I can send them to you
out-of-band.

Leslie.

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

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

Posted-Date: Sat, 25 Oct 1997 13:08:42 +0100 (MET)
Date: Sat, 25 Oct 1997 13:08:42 +0100 (MET)
From: Dirk-Willem van Gulik <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: Leslie Daigle <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Reply-Path: [email-masked]
Sender: [email-masked]
Reply-To: Dirk-Willem van Gulik <[email-masked]>

On Fri, 24 Oct 1997, Dan Connolly wrote:

> Short version:
> 
> Leslie Daigle wrote:
> > >      Syntax draft says "URIs are covered by other specs".
> > >      What other specs?
> > 
> > RFC2141
> 
> Hmmm.... checking...
> The term URI does not occur in RFC2141.
> So that's no help.
> 

1630 ?!

Hmm, Alhoug I might sail into dangerous groups, I've always felt that
somewhere rough consensus suggest that in the big and happy
UR-<alphabet-soup> group of things a 'URI' could kind of be seen as the
thing that imposes constraints on all, i.e. RFC1630 (and I could see the
need for some updating there). The various URL specs (for http, finger,
ldap, z3950, handle-scheme, telnet, ftp, mailto, etc) should all just
refine the 1630 definition; as does the URN definition 2141.

Nicely enough, the 1994 written RFC 1630 says:

   URLs are listed here. The Uniform Resource Name (URN) debate attempts
   to define a name space (and presumably resolution protocols) for
   persistent object names. This area is not addressed by this document,
   which is written in order to document existing practice and provide a
   reference point for URL and URN discussions.

And I would most certainly advocate to use it as such a reference point,
and make the URN just one of those flavours URIs, and adhere to the
same 'Universal Syntax'.

Although I might be wrong, (and am most certainly wrong when it comes
to some of the URLs currently in use) I would assert that the current
URN (21441) syntax fits perfectly within the 1630 constraineds of its
'Universal Syntax'. If this is not the case we should fix it.
 
> > One specific document you don't seem to have been aware of is the URN syntax
> > standards-track RFC (RFC2141).
> 
> I'm aware of it (I read some of the earlier drafts.) It specifies
> a syntax where all the strings start with urn: . I got
> the impression urn: would go in the list along with http:
> and ftp: and all the rest in places like the IANA registry,
> the Java APIs, the Address/Location field in browsers etc.
 
> Not so?

Syntax wise, I would guess that most people on this list would give a big
yes, sematically of course it is a diffeernt issue.

> > I won't speak directly to the issue of whether or not the W3C documents
> > should refer to URIs or URLs,

> I wish you would.

Well, let me make a stab at this as well... jus to see if this would
narrow down the discussion.

I personally believe that the w3c documets should use the term URI when
they refer to a universally applicable name which is to contain references
to registered protocols, namespaces. When the documents refers to the
location of the resource, as to be used to obtain the resource from the
given localtion(s) with the given protocol, i.e.without any level of
indirection outside the name (though possibly within the protocol) then
the more preciese term URL should be used. If however the application
described in the w3c document needs to be very explicit about
the location independent resource idenfification it would be bettter to
use the URN word.

Quite naturally there is a blurr between a URNs and URLs, in particular a
carefully choosen URL might fullfill most, if not all, _functional_
requirements of a URN; and a poorly chosen URN space can end up being as
messy and location dependent as URLs. 

So as a usefull guideline, I would look at the functional requirements in
the w3c drafts, what is it that one expects from that information element
reffered to, and when in doubt use the 'URI' word. Though it would surpize
if that is that often needed, when you get to the gritty details of
actually coding it, meeting the functional requirements of URNs and using
them that way makes them very, very different from URL's and it is very
obvious which is which, and why you need both.

> > URLs.  URNs are discussed in RFC2141.  The syntaxes are intended to be
> > compatible.
 
> I keep hearing that, but I look at the standards-track documents,
> and I don't see it in black-and-white.

So would it help if there was an updated 1630 which talked only about URI
syntax, and and updated 2141 which only points to the URI syntax with a
refinement; and likewise for the URL definitions, etc. etc, I would still
like to keep 1630, as it gives a lot of 'architecture' information which
should not be lost.

i.e.
	urI Syntax	 'scheme:path'
			escaping
	.urL = urI + meaning of the hash, ?, etc, relative stuff, 
		protcol name registry
	..HTTP = urL + naming segments, query string, etc
	..FTP = urL + way to encode username passwd, etc, etc
	.urN = urI + naming schemes, etc. 

as most is perceived to be defined this way anyway, the split up
over the defining documents is jsut a bit awkward.

Just my 200 lire's worth,

Dw.

From: Keith Moore <[email-masked]>
To: Dan Connolly <[email-masked]>
cc: Larry Masinter <[email-masked]>, Leslie Daigle <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Date: Fri, 24 Oct 1997 20:10:20 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> But meanwhile, I seem to be getting a "no" answer from
> Leslie and Keith.

I'm not sure what the specific question is, but I would
certainly like to see a brief RFC that defined the term 
URI in relation to URNs and URLs, with appropriate
references to the latter two.  

Alternatively, it would be fine to define the term URI 
in the URL syntax document, perhaps with a title change
e.g. "syntax of uniform resource identifiers" -- 
It should briefly define URL and URN and refer to the 
URN syntax document for the specifics of URN syntax.  

either way would create a suitable reference for the term URI.

Date: Fri, 24 Oct 1997 18:27:58 -0500
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: Larry Masinter <[email-masked]>
CC: Leslie Daigle <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Larry Masinter wrote:
> > Can I please have an IETF standards-track
> > document that specifies
> > the union of the URL and URN syntaxes?
> 
> Yes, absolutely, you can. Here's what you need to do to get it:
> 
> a) propose a specific set of edits you'd like to see in the
> draft-fielding-url-syntax-09.txt document to make it cover URIs
> and URNs (changing the title, if you like). Please address the
> relationship with the existing URN RFCs, if you intent to
> subsume them.

I wanted to get a sense from the document editors and area
directors what the odds are that my changes would be integrated
if I did that.

It's fair for you to say "I can't tell you until you show
me the edits."

But meanwhile, I seem to be getting a "no" answer from
Leslie and Keith.

-- 
Dan Connolly, W3C Architecture Domain Lead
http://www.w3.org/People/Connolly/

Date: Fri, 24 Oct 1997 16:03:19 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Dan Connolly <[email-masked]>
CC: Leslie Daigle <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Dan,

The IETF is an open organization.

> Can I please have an IETF standards-track 
> document that specifies
> the union of the URL and URN syntaxes?

Yes, absolutely, you can. Here's what you need to do to get it:

a) propose a specific set of edits you'd like to see in the
draft-fielding-url-syntax-09.txt document to make it cover URIs
and URNs (changing the title, if you like). Please address the
relationship with the existing URN RFCs, if you intent to
subsume them.

- OR - 
b) Write an internet draft "URIs are URNs or URLs", and send it to
[email-masked]'. There's a recent RFC on 'instructions for RFC
authors' which gives guidelines.

In either case, we can propose these for standards track, and
follow the simple IETF process for moving things along that way.

You need it, you got it!

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

Date: Fri, 24 Oct 1997 17:46:14 -0500
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: Leslie Daigle <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Short version:

Leslie Daigle wrote:
> >      Syntax draft says "URIs are covered by other specs".
> >      What other specs?
> 
> RFC2141

Hmmm.... checking...
The term URI does not occur in RFC2141.
So that's no help.

Details...

> I think you can address some of your concerns/questions with a visit
> to the IETF's URN working group homepage:
> 
>         http://www.ietf.org/html.charters/urn-charter.html

Thanks for the reminder... I looked there in April[1],
but not since

[1] http://www.w3.org/Addressing/9704ietf38-notes

> One specific document you don't seem to have been aware of is the URN syntax
> standards-track RFC (RFC2141).

I'm aware of it (I read some of the earlier drafts.) It specifies
a syntax where all the strings start with urn: . I got
the impression urn: would go in the list along with http:
and ftp: and all the rest in places like the IANA registry,
the Java APIs, the Address/Location field in browsers etc.

Not so?

> I won't speak directly to the issue of whether or not the W3C documents
> should refer to URIs or URLs,

:-{
I wish you would.

> but there are some specific issues about
> URNs that you brought up that I would like to address.
> 
> On Thu, 23 Oct 1997, Dan Connolly wrote:
> 
> > don't reflect that. The IANA registry[1] claims to be
> > a URL scheme registry, rather than a URI scheme
> > registry. So I wonder... is it expected that urn: will
> > appear in that registry?
> 
> Not necessarily.

Can I please have a clear "yes" or "no" from your
own personal perspective? Do you expect it to
go in that list or not?

>  URNs as they are currently being discussed will have
> need for scheme registration procedures that are different than those of
> URLs -- specifically because URNs aim to (attempt to) provide uniqueness
> and longevity, and also incur some overhead in maintaining registries.
> This is a very key issue, brought up at the Munich URN meeting, and
> hopefully we'll have concrete proposals on the table by Washington.

I'm not talking about the identifers that follow "urn:"
in URNs, but just the one identifier "urn:" itself.

> > And the terms URN and URI either invoke warm fuzzies, cold
> > pricklies, or blank stares, but no hands-on understanding.
> 
> By the way, I think this depends on who you talk to.  Various people
> in publishing and national libraries around the world are clamouring
> for URNs.

Right: the term URN invokes warm fuzzies from those folks.

But I haven't run into one that told me how they're
currently using them (except for PURLs, which use the http:
scheme, and some folks using hdl: . Will hdl: go in the
existin IANA registry?).

> >      Does the process draft cover all URIs or just some?
> >      ("URLs" as of Aug 97) (See Roy's page for latest
> >      process/syntax draft)
> 
> URLs only.
> 
> It has been developed for URLs, and independently of the needs of URNs,
> so if it wants to become the URI process draft, further discussion is
> needed.

I'm game for that. (but I realized a few minutes ago that
I might be on the wrong list. Should I be on [email-masked]?

> >      Does the syntax draft cover all URIs or just some? (
> >      "URLs" as of Aug 97)
> 
> URLs.  URNs are discussed in RFC2141.  The syntaxes are intended to be
> compatible.

I keep hearing that, but I look at the standards-track documents,
and I don't see it in black-and-white.

Can I please have an IETF standards-track 
document that specifies
the union of the URL and URN syntaxes?

Larry writes:
>I think that's a good summary of the situation. HTML and XML
>can say they use URIs, and then point to a W3C note that
>says "A URI is defined by IETF, currently it points to URLs,
>and there is some work on URNs".

I'll do that if I have to. But I don't want to.

Back to Leslie...
> >      Syntax draft says "URIs are covered by other specs".
> >      What other specs?
> 
> RFC2141

The term URI does not occur in RFC2141.

> >       spec about URLs, URIs, and URNs, and we
> >       cite RFC1738 and RFC1808 normatively,
> >       and RFC1630 informatively.
> 
> Throw in RFC2141.

Hmm... that's a possibility. I don't really see how
it helps. I still have to define a term for the
union of the RFC2141 syntax and the RFC1808-as-revised
syntax.

> > I request clear guidance on whether
> >       (1) we can expect the IANA registry to become
> >       known as a URI registry, with the corresponding
> >       change in the syntax and process documents.
> 
> I don't think this is appropriate, as these documents are truly URL
> documents, and haven't been developed in conjunction with the URN
> material.

Can you provide some evidence why it's not appropriate?

> Whether or not there should eventually _be_ umbrella documents is
> a separate question.

I need them. Yesterday.

> >       (2) we can expect the IANA registry to continue
> >       to be known as a URL registry, in which case I
> >       request that the term URI be declared historical
> >       in the syntax/process drafts,
> >       and that any mention of URN set an expectation
> >       that the urn scheme (or schemes) will go in
> >       the URL registry.
> 
> I don't think it would be appropriate to declare this at this time; the
> URN work is real,

I don't dispute that.

> and it has different needs than the URL registry/process.

Would you please be more specific?

> As I said -- check out the URN WG page and the associated RFCs.  We
> are working on sorting out what _should_ be appropriate registration
> processes for URN namespaces (analoguous to but different than URL schemes)
> as that is one outstanding issue that stops URNs from going live.
> 
> Leslie.
> IETF URN WG Co-Chair

-- 
Dan Connolly, W3C Architecture Domain Lead
http://www.w3.org/People/Connolly/

Date: Fri, 24 Oct 1997 14:06:12 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Leslie Daigle <[email-masked]>
CC: Keith Moore <[email-masked]>, [email-masked], Al Gilman <[email-masked]>, Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Some URLs don't accept relative references, e.g., 'cid:' and
'mid:'. Maybe these should be URNs, too, but they're used
to locate a resource in a message, not to name it. So it's
fuzzy.

I think fragment identifiers that are used for *named* fragments
are useful in URNs and URLs equally. If fragments
were used as locators with some syntax "#bytes:1-47", we'd
have more of a problem.

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

Date: Fri, 24 Oct 1997 16:53:14 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked], Larry Masinter <[email-masked]>, Al Gilman <[email-masked]>, Dan Connolly <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On the subject of "URNs are URLs", 

On Fri, 24 Oct 1997, Keith Moore wrote:
> While I agree that this is one way to name something,
> it doesn't fit with the *definition* of URNs, which
> says that they're location-independent.
> 
> Again, it doesn't matter to the average Joe, but it does 
> matter to an expert.

It is also the case, for example,  that URLs can be relative, and have 
fragment identifiers applied to them (e.g., http://whatever.com/someURL#frag1). 
It hasn't yet been conclusively demonstrated that these concepts roll over
reasonably into URNs, so it would be detrimental to simply sweep URNs
under the URL umbrella, no matter what it did for the terminology.  

URNs _are_ not URLs; I think it's only important that developers continue
to understand that, although it really should not ever matter to the 
average Joe, as Keith says.

Leslie. 

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

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

Date: Fri, 24 Oct 1997 10:55:25 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Dan Connolly <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: The UR* scheme registry, Citing URL/URI specs
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Dan,

I think you can address some of your concerns/questions with a visit
to the IETF's URN working group homepage:

	http://www.ietf.org/html.charters/urn-charter.html

One specific document you don't seem to have been aware of is the URN syntax 
standards-track RFC (RFC2141).

I won't speak directly to the issue of whether or not the W3C documents
should refer to URIs or URLs, but there are some specific issues about
URNs that you brought up that I would like to address.

On Thu, 23 Oct 1997, Dan Connolly wrote:

> don't reflect that. The IANA registry[1] claims to be
> a URL scheme registry, rather than a URI scheme
> registry. So I wonder... is it expected that urn: will
> appear in that registry?

Not necessarily.  URNs as they are currently being discussed will have
need for scheme registration procedures that are different than those of
URLs -- specifically because URNs aim to (attempt to) provide uniqueness
and longevity, and also incur some overhead in maintaining registries.
This is a very key issue, brought up at the Munich URN meeting, and 
hopefully we'll have concrete proposals on the table by Washington.

> And the terms URN and URI either invoke warm fuzzies, cold
> pricklies, or blank stares, but no hands-on understanding.

By the way, I think this depends on who you talk to.  Various people
in publishing and national libraries around the world are clamouring
for URNs.

>      Iana maintains a registry of schemes which includes mid:
>      and cid:. If those are URL schemes, then everything is a
>      URL. Else, what IANA maintains is a UR*I* registry 

IANA currently maintains a URL registry.

>      Does the process draft cover all URIs or just some?
>      ("URLs" as of Aug 97) (See Roy's page for latest
>      process/syntax draft) 

URLs only.

It has been developed for URLs, and independently of the needs of URNs,
so if it wants to become the URI process draft, further discussion is
needed.  

>      Does the syntax draft cover all URIs or just some? (
>      "URLs" as of Aug 97) 

URLs.  URNs are discussed in RFC2141.  The syntaxes are intended to be
compatible.

>      Syntax draft says "URIs are covered by other specs".
>      What other specs? 

RFC2141

> 	spec about URLs, URIs, and URNs, and we
> 	cite RFC1738 and RFC1808 normatively,
> 	and RFC1630 informatively.

Throw in RFC2141.

> I request clear guidance on whether
> 	(1) we can expect the IANA registry to become
> 	known as a URI registry, with the corresponding
> 	change in the syntax and process documents.

I don't think this is appropriate, as these documents are truly URL
documents, and haven't been developed in conjunction with the URN
material. 

Whether or not there should eventually _be_ umbrella documents is
a separate question.

> 	(2) we can expect the IANA registry to continue
> 	to be known as a URL registry, in which case I
> 	request that the term URI be declared historical
> 	in the syntax/process drafts,
> 	and that any mention of URN set an expectation
> 	that the urn scheme (or schemes) will go in
> 	the URL registry.

I don't think it would be appropriate to declare this at this time; the
URN work is real, and it has different needs than the URL registry/process.

As I said -- check out the URN WG page and the associated RFCs.  We
are working on sorting out what _should_ be appropriate registration
processes for URN namespaces (analoguous to but different than URL schemes)
as that is one outstanding issue that stops URNs from going live.

Leslie.
IETF URN WG Co-Chair

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

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

Date: Tue, 21 Oct 1997 17:03:04 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked]
Subject: [URN] Document proposed for Informational RFC
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

We've last-called & circulated the edited version on the WG mailing list, and
the URN working group is ready to recommend that 

	draft-ietf-urn-req-frame-04.txt
	(Architectural Principles of Uniform Resource Name Resolution)

be put forward as an informational RFC.

Thanks!
Leslie.

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

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

From: [email-masked]
Date: Mon, 13 Oct 97 09:18:29 EST
To: [email-masked]
Subject: [URN] Free Internet Software!
Sender: [email-masked]
Reply-To: [email-masked]

Learn how to plan, develop create and manage successful web sites. If we
can't teach you in two days, it's free.

Attend one of our two-day workshops in sunny Florida and receive the brand
new Microsoft Internet Explorer 4.0 on CD, plus four powerful Internet
tools, shareware, evaluation software and discounts of up to 80% on software
packages from Microsoft, Macromedia and others.

Orlando, FL: October 22 & 23 (Wed-Thu)
West Palm Beach, FL: October 29 & 30 (Wed-Thu)
Ft. Lauderdale, FL: November 3 & 4 (Mon-Tue)
Coral Gables (Miami) FL: November 6 & 7 (Thu-Fri)
Tampa, FL: November 17 & 18 (Mon-Tue)

It's 80 degrees and sunny here in Florida. Come bask in the warm sunshine
and learn to turn the Internet into your company's most cost effective
selling tool! (Special airfares and hotel rates are available.)

For more information visit our Web site: www.exitnow.com

For QUICK response, simply press reply, or email us at [email-masked]

<<<In the subject line, please specify how you want your workshop agenda
information delivered (email, fax, usmail, telephone). Then be sure to
include the applicable contact information in your response.>>>

Or call us at (888)456-EXIT [3948]

To remove your name from our emailing list, simply press reply and type
REMOVE in the subject line.

Thank you.

ExitNow Team

From: Keith Moore <[email-masked]>
To: Leslie Daigle <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: Bibliographic Identifiers draft to move forward 
Date: Wed, 01 Oct 1997 15:59:33 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

sounds good to me.  
I've asked the secretariat to last call it for Informational.

thanks!

Keith

Date: Wed, 1 Oct 1997 14:55:09 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Bibliographic Identifiers draft to move forward
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Howdy!

We've done the WG last call on the URN Bibliographic Identifiers 
(grandfathering) draft. The editors have made the necessary changes and 
submitted it to the Internet-Drafts editor.   So, the URN working group is 
ready to recommend that 

	draft-ietf-urn-biblio-02.txt

be put forward as an informational RFC.

Anything else I should do at this point?

Leslie.

-- 

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

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