Subject: RE: [URN] URN NID requirements paper
From: Fisher Mark <[email-masked]>
To: "'Patrik Faltstrom'" <[email-masked]>, "'Larry Masinter'" <[email-masked]>
Cc: "'The URN List'" <[email-masked]>, "'Renato Iannella'" <[email-masked]>
Date: Wed, 28 May 1997 12:41:27 -0500

Larry, you wrote:
>At each design question, ask yourself "how would this work
>if the organization that generated the name disappears, merges,
>changes its name, gets sued for trademark infringement, or
>decides to disclaim material that was otherwise circulated
>with the previous name".
>[...]
>Why would IANA accept such a task? Perhaps "namespaces must
>be standards track".

Unfortunately, what we (IMHO) are limited to doing with URNs is to set
up a framework that will help (and I hope help immensely) in creating
persistent, unique, location-independent names.  But the framework can
only assist in this -- there will always be ways in which the system can
be exploited and mismanaged (witness the re-use of ISBN numbers).

One of the reasons the Web took off the way it did was that anyone with
a TCP/IP network could create and use a Website, whether they were
connected to the Internet or not (TCE did just that).  If an
organization wanted to create an Internet Web site, all they needed was
a domain name registration (a relatively low-overhead process).  URNs
could end up supplanting many current uses of URLs, if the namespace
registration process is similarly low-overhead.  If URN namespaces all
require "standards track", I would expect to see URNs end up as a very
minor # of the URIs in use, quite probably unknown to most Internet
users because they will be of little use to them.

The questions you raise are extremely important to the eventual success
of our URN efforts -- but there are political and legal aspects that any
framework this group approves can only aid in resolving, not resolve
strictly by a technical solution.  I think that requiring namespaces to
be "standards track" would result in a URN framework that is extremely
inflexible while still not solving the problems you present.
==========================================================
Mark Leighton Fisher          Thomson Consumer Electronics
[email-masked]          Indianapolis, IN
"ViaCrypt?  Vhy not!"

Date: Tue, 27 May 1997 22:08:40 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Patrik Faltstrom <[email-masked]>
CC: The URN List <[email-masked]>, Renato Iannella <[email-masked]>
Subject: Re: [URN] URN NID requirements paper
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> Any input on these issues will help me and Renato in our work...

At each design question, ask yourself "how would this work
if the organization that generated the name disappears, merges,
changes its name, gets sued for trademark infringement, or
decides to disclaim material that was otherwise circulated
with the previous name".

> We see a namespace as "A Collection of persistent identifiers for
> Resources". I.e. one namespace names a collection of identifiers.

It's circular (an 'identifier' is defined relative to a namespace)
but that's OK. Some of the best definitions are circular.

> How do we handle local Public NS?
> 
> Example 1 -- Geographical supspaces:

Yes, and what happens with the license places for the Soviet
Union and Ukraine and Georgia?

Suggestion: don't allow geographical subspaces

> Example 2 -- Organizational subspaces:

Yes, and what happens when organizations merge, divest (AT&T?
Lucent?), or change their names?

Suggestion: don't allow organizational subspaces

> I.e. should we force all namespaces to be publically resolvable?

And if the company goes bankrupt, how will you sue them
for no longer resolving their namespaces?

> Should IANA handle the namespace registrations? Do we end
> up in a new IAHC battle?

Why would IANA accept such a task? Perhaps "namespaces must
be standards track".

> Can we create a form that they should fill out?

What would you ask on the form, and what would you do if
someone didn't fill it out right or put in invalid information?

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

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: [URN] Document Action: Resolution of Uniform Resource Identifiers using the Domain Name System to Experimental
Date: Tue, 27 May 1997 17:42:23 -0400
Sender: [email-masked]
Reply-To: The IESG <[email-masked]>

  The IESG has reviewed the Internet-Draft "Resolution of Uniform Resource
  Identifiers using the Domain Name System" <draft-ietf-urn-naptr-05.txt>
  and recommends that it be published by the RFC Editor as an Experimental
  RFC. This document is the product of the Uniform Resource Names Working
  Group. The IESG contact persons are Keith Moore and Harald Alvestrand.

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: [URN] Document Action: A Trivial Convention for using HTTP in URN Resolution to Experimental
Date: Tue, 27 May 1997 17:26:58 -0400
Sender: [email-masked]
Reply-To: The IESG <[email-masked]>

  The IESG has reviewed the Internet-Draft "A Trivial Convention for using
  HTTP in URN Resolution" <draft-ietf-urn-http-conv-01.txt> and recommends
  that it be published by the RFC Editor as an Experimental RFC. This
  document is the product of the Uniform Resource Names Working Group. The
  IESG contact persons are Keith Moore and Harald Alvestrand.

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re: URN NID Requirements
Date: Tue, 27 May 1997 15:23:13 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_01BC6AB1.E49BC260
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ron Daniel wrote:
No, I said what I meant. UPCs are Uniform Product Codes. Almost anything
you buy now has a barcode on it. That barcode will have a number
below it, such as 42709 10150 (which identifies a 1GB Jaz drive =
cartridge).
The barcode is an encoding of that number, which is the Uniform Product
Code. I haven't got any car parts laying aroun dmy office to check, but
I imagine that several auto manufacturers use UPCs for identifying their
parts. I think UPCs will make a fine URN namespace - although a little
challenging to resolve given the scale of the system. They would look
something like urn:upc:42709-10150. (I need to recheck my UPC syntax
because I may be leaving out the check digit in that example).

Auto manufacturers may also use a different naming system for their
parts. The first thing to do is see if there is a trivial mapping from
their own namespace to UPCs.
>>>>
Thank you Ron for the clarification. You are right about Uniform Product =
Codes, that would be a ideal part number system (in fact it is, as you =
know,  a standard). However, most of car manufacturer already have =
legacy (yes that again) part numbers based on their relational DB or =
mainframe ISAM keys. It would be a good thing for them to move to UPCs =
but most of them are still with their current system. To change their =
parts number system means a lot of adaptation for the whole car =
infrastructure (car mechanics, auto parts dealers, etc..) this is not an =
easy task. Some parts are labeled with UPCs but most of them are =
referred with the auto maker parts number system. Some, are moving =
slowly toward UPCs but there is still a lot to do. Then, we can say that =
for some years, they will still have proprietary part number systems and =
cannot afford UPCs for their whole system.

------=_NextPart_000_01BC6AB1.E49BC260
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR>

</HEAD>
<BODY>
<P><FONT face=3DArial size=3D2>Ron Daniel wrote:</FONT>

<P><FONT face=3DArial size=3D2>No, I said what I meant. UPCs are Uniform =
Product=20
Codes. Almost anything<BR>
you buy now has a barcode on it. That barcode will have a number<BR>
below it, such as 42709 10150 (which identifies a 1GB Jaz drive =
cartridge).<BR>
The barcode is an encoding of that number, which is the Uniform =
Product<BR>
Code. I haven't got any car parts laying aroun dmy office to check, =
but<BR>
I imagine that several auto manufacturers use UPCs for identifying =
their<BR>
parts. I think UPCs will make a fine URN namespace - although a =
little<BR>
challenging to resolve given the scale of the system. They would =
look<BR>
something like urn:upc:42709-10150. (I need to recheck my UPC syntax<BR>
because I may be leaving out the check digit in that example).<BR>&nbsp;
<BR>
Auto manufacturers may also use a different naming system for their<BR>
parts. The first thing to do is see if there is a trivial mapping =
from<BR>
their own namespace to UPCs.</FONT>

<P><FONT face=3DArial size=3D2>&gt;&gt;&gt;&gt;</FONT>

<P><FONT face=3DArial size=3D2>Thank you Ron for the clarification. You =
are right=20
about Uniform Product Codes, that would be a ideal part number system =
(in fact=20
it is, as you know,  a standard). However, most of car manufacturer =
already have=20
legacy (yes that again) part numbers based on their relational DB or =
mainframe=20
ISAM keys. It would be a good thing for them to move to UPCs but most of =
them=20
are still with their current system. To change their parts number system =
means a=20
lot of adaptation for the whole car infrastructure (car mechanics, auto =
parts=20
dealers, etc..) this is not an easy task. Some parts are labeled with =
UPCs but=20
most of them are referred with the auto maker parts number system. Some, =
are=20
moving slowly toward UPCs but there is still a lot to do. Then, we can =
say that=20
for some years, they will still have proprietary part number systems and =
cannot=20
afford UPCs for their whole system.</FONT></P>

</BODY></HTML>

------=_NextPart_000_01BC6AB1.E49BC260--

Date: Tue, 27 May 1997 13:02:52 -0600
To: "didier ph martin" <[email-masked]>, "URN Workgroup" <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] Re: URN NID Requirements
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 02:27 PM 5/27/97 -0400, didier ph martin wrote: 
>>>>

Ron Daniel Wrote: 

For the case of part numbers, the first thing I would  ask them is
why don't they use UPCs?" 

Daniel, do you mean URCs? If yes, it is very useful  to define a set a URCs
by uniquely identifying each element by a URN, and their  location with a
URL.  
<<<<

No, I said what I meant. UPCs are Uniform Product Codes. Almost anything
you buy now has a barcode on it. That barcode will have a number
below it, such as 42709 10150 (which identifies a 1GB Jaz drive cartridge).
The barcode is an encoding of that number, which is the Uniform Product
Code. I haven't got any car parts laying aroun dmy office to check, but
I imagine that several auto manufacturers use UPCs for identifying their
parts. I think UPCs will make a fine URN namespace - although a little
challenging to resolve given the scale of the system. They would look
something like urn:upc:42709-10150. (I need to recheck my UPC syntax
because I may be leaving out the check digit in that example).

Auto manufacturers may also use a different naming system for their
parts. The first thing to do is see if there is a trivial mapping from
their own namespace to UPCs.

Regards,

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: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re: URN NID Requirements
Date: Tue, 27 May 1997 14:27:43 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_01BC6AAA.23EC3B00
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ron Daniel Wrote:
For the case of part numbers, the first thing I would ask them is
why don't they use UPCs?"
Daniel, do you mean URCs? If yes, it is very useful to define a set a =
URCs by uniquely identifying each element by a URN, and their location =
with a URL.=20
On the other side, there is no clear URCs definition yet.=20
Also, imagine that people use their borwser to get info about a parts =
(take a Volvo part like the example stated earlier in this workgroup. =
The first step to would do is simply to write the parts number URN to =
get the parts record (could be images, data, etc..). You have here a =
clear advantage of URNs compared to URLs. They dont have to translate =
from one world to an other. They just type the parts number instead of a =
URL address.
So you have to consider two contexts:
a) within a browser
b) trough a directory system, in this last case a URC is useful =
especially to record the attribute set attached to a name.
An other usage of URNs could also be to get an attribute set or a =
particular attribute from a name server, relational database or =
directory server.
But maybe I don't see clearly what you mean, can you be more specific on =
why not use URNs for parts number systems?=20
Didier PH Martin
mailto:martindnetfolder.com
http://www.netfolder.com

------=_NextPart_000_01BC6AAA.23EC3B00
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML 3.2//EN">
<HTML>
<HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META content=3D'"Trident 4.71.0544.0"' name=3DGENERATOR>

</HEAD>
<BODY>
<P><FONT face=3DArial size=3D2><BR>
Ron Daniel Wrote:</FONT>

<P><FONT face=3DArial size=3D2>For the case of part numbers, the first =
thing I would=20
ask them is<BR>
</FONT><FONT face=3DArial size=3D2>why don't they use UPCs?&quot;</FONT>

<P><FONT face=3DArial size=3D2>Daniel, do you mean URCs? If yes, it is =
very useful=20
to define a set a URCs by uniquely identifying each element by a URN, =
and their=20
location with a URL. </FONT>

<P><FONT face=3DArial size=3D2>On the other side, there is no clear URCs =
definition=20
yet. </FONT>

<P><FONT face=3DArial size=3D2>Also, imagine that people use their =
borwser to get=20
info about a parts (take a Volvo part like the example stated earlier in =
this=20
workgroup. The first step to would do is simply to write the parts =
number URN to=20
get the parts record (could be images, data, etc..). You have here a =
clear=20
advantage of URNs compared to URLs. They dont have to translate from one =
world=20
to an other. They just type the parts number instead of a URL =
address.</FONT>

<P><FONT face=3DArial size=3D2>So you have to consider two =
contexts:</FONT>

<P><FONT face=3DArial size=3D2>a) within a browser</FONT>

<P><FONT face=3DArial size=3D2>b) trough a directory system, in this =
last case a URC=20
is useful especially to record the attribute set attached to a =
name.</FONT>

<P><FONT face=3DArial size=3D2>An other usage of URNs could also be to =
get an=20
attribute set or a particular attribute from a name server, relational =
database=20
or directory server.</FONT>

<P><FONT face=3DArial size=3D2>But maybe I don't see clearly what you =
mean, can you=20
be more specific on why not use URNs for parts number systems? </FONT>

<P><FONT face=3DArial size=3D2>Didier PH Martin</FONT>

<P><FONT face=3DArial size=3D2><A=20
href=3D"mailto:martindnetfolder.com">mailto:martindnetfolder.com</A></FON=
T>

<P><FONT face=3DArial size=3D2><A=20
href=3D"http://www.netfolder.com">http://www.netfolder.com</A></FONT>

<P><FONT face=3DArial size=3D2></FONT>&nbsp;

<P><FONT face=3DArial size=3D2></FONT>&nbsp;</P>

</BODY></HTML>

------=_NextPart_000_01BC6AAA.23EC3B00--

Date: Tue, 27 May 1997 09:15:00 -0600
To: Ted Wolf Jr <[email-masked]>, <[email-masked]>, <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] URN NID requirements paper
Cc: <[email-masked]>
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 06:44 PM 5/25/97, Ted Wolf Jr wrote:
>	Does anyone see a problem with global URN namespaces for SIC 
>and Commidity codes? We currently maintain these for free on behalf of the 
>government and I would like to add them to the namespaces list.

Don't know anything about them. Can you provide more info?

Regards,

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  

Date: Tue, 27 May 1997 09:14:59 -0600
To: Patrik Faltstrom <[email-masked]>, The URN List <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] URN NID requirements paper
Cc: Renato Iannella <[email-masked]>
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 08:32 PM 5/25/97 +0200, Patrik Faltstrom wrote:
>(1) Defintion of a NameSpace...
>
>We see a namespace as "A Collection of persistent identifiers for
>Resources". I.e. one namespace names a collection of identifiers.

How about something like "A Namespace is a system for assigning
persistent identifiers to resources according to some defined approach".
The point is that a namespace is not just a set of identifiers, but
typically names a domain of resources and sets forth a syntax.

>(2) Private VS Public NameSpace
>
>How do we handle local Public NS?
>
>Example 1 -- Geographical supspaces:
>
>In Queensland, Australia, one organisation want to have a namespace for
>the license plate numbers. What to do? Our suggestion is that they do
>_not_ get a separate namespace for those license numbers, because they do
>not cover the whole world. I.e. they have to come back with a plan for how
>to handle "License Plate Numbers in the world" which probably is a
>hierarichal namespace, and they take care of the Australia/QLD part.

Although this imposes a large burden on the first group to want to
register such a namespace, it seems prudent to plan for growth.

>Suggestion: Do not allow grandfathering of geographical subparts of an
>existing namespace (like license plate id's).

I'm not quite ready to accept this generalization, although I'm coming
closer to seeing the need for it.

>Example 2 -- Organizational subspaces:
>
>Our guess is that every company want to have a namespace for their part
>numbers.

For the case of part numbers, the first thing I would ask them is
why don't they use UPCs?

>Suggestion: Create a specific namespace where organization-specific
>namespaces reside.

This is still a good suggestion, but where reasonable we should encourage
the use of existing namespaces rather than the widespread creation of
new namespaces.

>Last question on local namespaces:
>
>Should they be publically-resolvable, but get you nowhere?

This is a decision for the namespace managers. They may wish to
reserve a namespace ID, but not allow any unauthenticated resolutions.
I don't see a need to preclude that, although we should have a caveat
about reserving namespaces in the hope of selling them off later.

>I.e. should we force all namespaces to be publically resolvable?

No.

>Suggestion: Define what operations do exist on a URN. The only responses
>allowed are "Here is the answer" (and you get back the correct one), "URN
>is not allocated" or "URN does exist, is valid, but resource is gone or
>not accessible". I.e. it doesn't matter if the result is not accessible
>all over the world as long as the responses are one of these three.

"Access denied" is a perfectly resonable (though not very friendly) response.
Seriously, even telling someone that the identifer they are presenting
for resolution is a valid identifier leaks too much information in
some situations. This is really a pretty important point for my site.

>3 - Registration Process.
>
>Should IANA handle the namespace registrations?

Absolutely.

> Do we end up in a new IAHC
>battle?

Several months ago Harald said that there is a legal firm that does pro-bono
work for the IETF. We need to draft the rules and then have them look them
over.

>Can we create a form that they should fill out?

Yes. Good idea.

>Who makes the decision on what is a new namespace? I guess a group of
>experienced people have to know if the correct descision is made --
>especially when grandfathering some more obscure namespaces. Maybe have
>an announcement like new MIME-types?

Sounds reasonable.

>Do they suggest the NS, or do "we" ? I.e. should they ask for a specific
>NID, or do they get an NID? How to go around the problem with vanity
>namespaces?

For legacy namespaces there are very resonable grounds for asking
for a specific NID instead of an assigned one. Maybe we make the
procedure for getting a new vanity namespace very protracted, but
a new assigned NID very quick and easy. The procedure for getting a NID
for a legacy namespace will end up being somewhat protracted anyway due
to the need to verify that the person registering the NID has the
authority to do so.

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: Ted Wolf Jr <[email-masked]>
To: <[email-masked]>, <[email-masked]>
CC: <[email-masked]>
Date: Sun, 25 May 1997 18:44:32
Subject:  Re: [URN] URN NID requirements paper
Sender: [email-masked]
Reply-To: Ted Wolf Jr <[email-masked]>

Patrik,

Question 1. I feel that a namspce in the realm of URN's should be defined as a 
collection of identifiers that resolve to very persistant resources.

Question 2. I think they all should be publically resolvable but you should have 
the option of returning a reply that indicated that while the identifier is valid in the 
namespace you either might be restricted from accessing it or similar responses. 
We will need this in order to support for charge or commercial implementations.

Question 3. Without a doubt this should reside with the IANA. Their purpose is 
to be the repository and control issuance of Internet wide identifiers(even if they 
delegate the operations to others.).

	Does anyone see a problem with global URN namespaces for SIC 
and Commidity codes? We currently maintain these for free on behalf of the 
government and I would like to add them to the namespaces list.

Ted Wolf Jr
Sr. Strategist Electronic Commerce
Dun & Bradstreet

Date: Sun, 25 May 1997 20:32:25 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: The URN List <[email-masked]>
cc: Renato Iannella <[email-masked]>
Subject: [URN] URN NID requirements paper
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

I and Renato have been working another round on the document on NID
requirements, but we have found a couple of issues which we want to know
what you say about them. Some of them can be ratholes (duck-ponds...:-)
with enormous gravity -- so please help us identify these aswell.

Issues:

(1) Defintion of a NameSpace...

We see a namespace as "A Collection of persistent identifiers for
Resources". I.e. one namespace names a collection of identifiers.

(2) Private VS Public NameSpace

How do we handle local Public NS?

Example 1 -- Geographical supspaces:

In Queensland, Australia, one organisation want to have a namespace for
the license plate numbers. What to do? Our suggestion is that they do
_not_ get a separate namespace for those license numbers, because they do
not cover the whole world. I.e. they have to come back with a plan for how
to handle "License Plate Numbers in the world" which probably is a
hierarichal namespace, and they take care of the Australia/QLD part.

I.e. instead of 

  URN:QLDLicensePlate:

...we want them to take care of

  URN:LicencePlate:au:qld:

(or something like that)

We will get the same kind of problem with several other examples where
grandfathering geographically local namespaces. Like Social Security
numbers, street addresses, organization numbers, governmental document ids
etc etc...

Suggestion: Do not allow grandfathering of geographical subparts of an
existing namespace (like license plate id's).

Example 2 -- Organizational subspaces:

Our guess is that every company want to have a namespace for their part
numbers. For example, Volvo (you know, the swedish car company that make
cars that are boxy :-) want to have a namespace. Should they get that, or
should we have a specific namespace covering these issues?

  URN:volvo:1238987123

or

  URN:org:volvo.se:1238987123 

I did choose volvo.se as an example that the org namespace might force the
NSS to be divided in two parts, first the domainname of the company and
then the company-specific string.

Suggestion: Create a specific namespace where organization-specific
namespaces reside.

Last question on local namespaces:

Should they be publically-resolvable, but get you nowhere?

I.e. should we force all namespaces to be publically resolvable?

Suggestion: Define what operations do exist on a URN. The only responses
allowed are "Here is the answer" (and you get back the correct one), "URN
is not allocated" or "URN does exist, is valid, but resource is gone or
not accessible". I.e. it doesn't matter if the result is not accessible
all over the world as long as the responses are one of these three.

3 - Registration Process.

Should IANA handle the namespace registrations? Do we end up in a new IAHC
battle?

Can we create a form that they should fill out?

Who makes the decision on what is a new namespace? I guess a group of
experienced people have to know if the correct descision is made --
especially when grandfathering some more obscure namespaces. Maybe have
an announcement like new MIME-types?

Do they suggest the NS, or do "we" ? I.e. should they ask for a specific
NID, or do they get an NID? How to go around the problem with vanity
namespaces?

Arbitration? Can we end up in trouble here? Probably... Just look at the
MoU, or talk with Mark Kosters....

Any input on these issues will help me and Renato in our work...

    Patrik

Date: Fri, 23 May 1997 08:22:12 -0600
To: [email-masked]
From: "Ron Daniel, Jr." <[email-masked]>
Subject: [URN] NAPTR revisions
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

Hi,

By now you have probably seen the annoucement of the -05 version of the
NAPTR draft. This version corrects a small error in the regular expressions
for the CID namespace examples.

Regards,
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  

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-naptr-05.txt
Date: Fri, 23 May 1997 09:30:40 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

 A Revised 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     : Resolution of Uniform Resource Identifiers 
                   using the Domain Name System                                      
       Author(s) : R. Daniel, M. Mealling
       Filename  : draft-ietf-urn-naptr-05.txt
       Pages     : 13
       Date      : 05/22/1997

Uniform Resource Locators (URLs) are the foundation of the World Wide Web, 
and are a vital Internet technology. However, they have proven to be 
brittle in practice. The basic problem is that URLs typically identify a 
particular path to a file on a particular host. There is no graceful way of
changing the path or host once the URL has been assigned. Neither is there 
a graceful way of replicating the resource located by the URL to achieve 
better network utilization and/or fault tolerance. Uniform Resource Names 
(URNs) have been hypothesized as a adjunct to URLs that would overcome such
problems. URNs and URLs are both instances of a broader class of 
identifiers known as Uniform Resource Identifiers (URIs). 

The requirements document for URN resolution systems[15] defines the 
concept of a "resolver discovery service". This document describes the 
first, experimental, RDS. It is implemented by a new DNS Resource Record, 
NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts 
of URIs to domain names.  By changing the mapping rules, we can change 
the host that is contacted to resolve a URI. This will allow a 
more graceful handling of URLs over long time periods, and forms the 
foundation for a new proposal for Uniform Resource Names.                             

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-naptr-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-05.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  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-naptr-05.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-naptr-05.txt

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

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

--OtherAccess--

--NextPart--

Date: Fri, 23 May 1997 11:44:38 +0200 (MET DST)
From: "Martin J. Duerst" <[email-masked]>
To: didier ph martin <[email-masked]>
cc: URN Workgroup <[email-masked]>
Subject: Re: [URN] RE: Relative URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Thu, 15 May 1997, didier ph martin wrote:

[Long and detailled explanations about URI input heuristics,
name spaces, and concatenation as a relativity mechanism.]

> We separated the URN resolution mechanism from the URN syntax as a human
> would write it. We made the assumption that the actual draft is intended
> for a machine having to send a URN to an other machine for resolution. We
> deduced that a <NSS> could be written like it is and don't require encoding
> (for human of course).

The URN draft, as the URL draft and RFCs, are intended both for computer
and for human use. The URL documents say so very clearly.
What a browser does when it completes "apple" to "http://www.apple.com/"
is called a heuristic. Depending on context, heuristics may differ widely.
For example, a browser customized for Japan could expand "apple" to
"http://www.apple.co.jp", a browser customized for a library in the US
could expand "201-48345" to "urn:isbn:0-201-48345-9", and so on.
There is no limit in inventiveness and adaption of such heuristics.

However, this does not mean that "apple" or "201-48345" are URLs/URNs,
or that they are suitable for broad human use. The full form is guaranteed
to work on any browser (and otherwise just a bug), some short form is
extremely dependent on local heuristics that change over space and
time (with the IAHC work progressing, browsers might become suspected
of unfair trade practices if they silently add ".com" to an entry).
Therefore:
	- Always change the "Location" display of the browser to the
		full URI.
	- Always print the full URIs (for a list of part numbers,
		at least add a global instruction of how to expand
		them to correct URIs).

> With one exception, they often
> forget to write "urn:gm:" (a gm parts catalog). this is overhead for them.
> Most of actual browsers add "http://" in front of a URL. People have just
> to type the "www.something.xxx" address and the system convert that to
> "http://www.something.xxx". We have an issue here. How can we still provide
> this feature for URLs and URNs. Both naming conventions have to live in the
> *user experience
> sphere" at the same time or for a certain time. How can we known the person
> just typed a URN or a URL if the string is not complete?

The solution is heuristics. I don't know how GM parts numbers look, but
I suppose it's easy to distinguish them from domain names. And in the cases
you can't distinguish, you could just put up a small dialog box saying:

Sorry, couldn't guess what you want. Is it:
	- a GM part number (urn:gm:xxx.yyy)
	- a Web page address (http://www.xxx.yyy)
	- something else (please specify: [xxx.yyy     ])

Note that this is carefully designed to speak in the user's language
("page address") and to give the full and correct URIs to strengthen
the user's understanding that what he is inputing are just abbreviations
and not the real thing.

> Even with that, people have a lot of difficulties to
> adapt to "url:www.something.xxx" but most of them could as soon as they saw
> the benefits to get things the way they where doing before the URL
> everywhere area.

"url:www.something.xxx" is a non-starter. If people have difficulties
with it and it's totally wrong according to syntax, why insist on it?

> Thus, there is no clear separation of how a human write a URN (humans
> doesn't like to convert into octal) and how a machine transfer that URN to
> an other one to be resolved.

Well, for URIs, it's hexadecimal, not octal. And it's clear that
this is a problem not of "liking" but of the availability of resouces
(coversion tables,...). And this problem is actually been worked on.
With UTF-8 as the only character encoding scheme for URNs and the
preferred one for URLs, we are moving towards a very nice solution.

But character encoding and %HH escaping, with UTF-8 and except for
the reserved characters in the ASCII range, can be done deterministically
in both ways.
On the other hand, conversion from a short local name to a full URI
is in no way deterministic, and full URIs should therefore always
be used outside places where the context is very clear.

Regards,	Martin.

Date: Wed, 21 May 1997 11:52:56 +0200
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked], [email-masked]
Subject: [URN] whois++
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>
Abort: /usr/tmp full

Date: Thu, 15 May 1997 14:15:41 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: [URN] Re:  Relative URNs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

<...text removed for brevity...>
   I always prefer to say that the URI working group closed because
   we had completed all of the work in our charter, and had no
   consensus for what additional work we were going to pursue.

   You might think this is revisionist history, but I think that
   the example of closing working groups when they are done and
   spawning new groups when there's some clearer grounds for it
   is a good model, and we're trying to follow it with HTTP, too.

You're right that that is revisionist history and although it should
not be the topic of discussion on this mailing list, I can't just let
that pass by, for the sake of those who were not there.

The IETF process does not always work as one might wish (or as spelled
out).  In this case, one person was on a power trip and closed the
group.  The work was NOT completed.  The group was in a productive
period with 3 RFCs published in the preceeding 6 months and drafts of
3 more on the table, in addition to significant work on a revised
agenda, because the group had previously moved more slowly than one
(or many!) might have wished.  The closing down of the group in fact
slowed the process severely.  The URN group was not formed for about a
year, although some work proceeded anyway, in a much less open forum.
The work on URCs still has not recovered.  The revision of the URL
documents is only coming out now, but could have come out of the URI
group much more quickly.  In all, the process did NOT work as one
might hope in the ideal.  In fact, it gave the efforts in this area
even more of a cloud to work under because of the additional delays in
recovering from that one person's power trip.  It is quite possible
that forming more specific working groups or subgroups is more
effective, but the power play that was used on the URI group left the
community reeling out of control.  From my perspective it was handled
EXTREMELY poorly with insult and lying as part of the mechanism.  The
IESG meeting in which the action was reported back to the whole IESG
was unintentionally much more public than it should have been, in a
room without one wall, open to the whole front lobby of the Grand
Hotel in Stockholm.  The action was reported as a power play and a
joke with a great deal of derogatory laughter and jolity.  I cannot in
anyway condone, explain away or support what was done or how it was
done.  But, you are right that it is past history and we need to move
forward from here, trying to avoid such pitfalls and individuals in
the future.

I applaud the efforts of the working group chairs, area directors and
others taking leadership supportive roles in the recovery from the
damage done.

			Karen

From: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Date: Thu, 15 May 97 09:42:05 
Priority: Normal
Subject: Re: [URN] I-D ACTION:draft-ietf-urn-ietf-00.txt
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Under the heading of discussion implementations, there is an implementation
of a resolver for the namespace below.  It's documentation page is

http://dsm0.ds.internic.net/urn/ 

which shows how to submit URN resolution requests for the namespace in
the i-d.

Ryan

P.S.  This isn't one of our production machines, so please be patient if it
isn't there.

=======================================================
On Thu, 15 May 1997 09:44:13 -0400, [email-masked] wrote:

> 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     : URN Namespace for RFC series documents                  
>       Author(s) : R. Moats
>       Filename  : draft-ietf-urn-ietf-00.txt
>       Pages     : 4
>       Date      : 05/14/1997
>
>A system for Uniform Resource Names (URNs) must be capable of supporting 
>new naming systems.  As an example of the sort of information that needs to
>be supplied when proposing new namepsaces, this document presents a naming 
>system based on the RFC family of documents (RFCs, STDs, and FYIs) 
>developed by the IETF and published by the RFC editor.  This namespace can 
>be supported within the URN framework and the currently proposed syntax 
>for URNs.                                                                      
>
>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-ietf-00.txt".
>A URL for the Internet-Draft is:
>ftp://ds.internic.net/internet-drafts/draft-ietf-urn-ietf-00.txt
> 
>Internet-Drafts directories are located at:	
>	                                                
>     o  Africa:  ftp.is.co.za                    
>	                                                
>     o  Europe:  ftp.nordu.net            	
>                 ftp.nis.garr.it                 
>	                                                
>     o  Pacific Rim: munnari.oz.au               
>	                                                
>     o  US East Coast: ds.internic.net           
>	                                                
>     o  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-ietf-00.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.
>

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-ietf-00.txt
Date: Thu, 15 May 1997 09:44:13 -0400
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     : URN Namespace for RFC series documents                  
       Author(s) : R. Moats
       Filename  : draft-ietf-urn-ietf-00.txt
       Pages     : 4
       Date      : 05/14/1997

A system for Uniform Resource Names (URNs) must be capable of supporting 
new naming systems.  As an example of the sort of information that needs to
be supplied when proposing new namepsaces, this document presents a naming 
system based on the RFC family of documents (RFCs, STDs, and FYIs) 
developed by the IETF and published by the RFC editor.  This namespace can 
be supported within the URN framework and the currently proposed syntax 
for URNs.                                                                      

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-ietf-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-ietf-00.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  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-ietf-00.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-ietf-00.txt

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

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

--OtherAccess--

--NextPart--

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] RE:  Relative URNs
Date: Thu, 15 May 1997 08:27:45 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

"There is now a Proposed Standard for URNs. URNs will progress
if there are interoperable implementations. I suggest,
rather than continuing to debate the points that went into
the preparation of the Proposed Standard again, continuously,
that you go off and see if you can build an interoperable
implementation. That is, continued discussion is completly
moot, and there's no point in continuing to fill our mailboxes
with the discussion of ":" vs "/" since, as far as I can
tell, no one is actually changing their mind about this, and
in that situation, the only question is whether the Proposed
Standard is actually implementable. But discussing it in
the abstract ("X would be easier to implement") isn't
getting us anywhere.

Normally I just delete the [URN] messages that cross
my mailbox because of the irrelevance of the continued
speculation, but it's a little tiresome. Clearly there
were *some* people in the URN group who were in the
process of building what they hoped would be interoperable
implementations, and what we need to hear from them is
the results of their experiments and some experience-based
discussion of how their software deals with the complex
issues we're raising, e.g., how one would give a URN
(several URNs? URNs for each slide?) for the powerpoint
presentation converted to HTML. Do you use relative URNs?
Is there only one "top-level URN" which resolves to
URLs for the individual components?"

Thank you Larry. Yes there are people working on *practical* things. And
yes
there is some issues that result from *practical* work. 

a) we just finished implementing a custom protocol on IE 4.0. Sorry we
couldn't do it with Netscape, it's a closed system. We will probably try
with the Sun's Java Bowser which is open. The problems we encountered,
except technical ones are mostly  difficulties for users to adapt
to a new naming scheme. So, we can say that the urn scheme has human
interface problems or the legacy of habits. However, preliminary test
indicates that it may not be the case for name spaces people are used with,
like for instance automotive parts number, social security numbers etc...
in these cases, people prefer to write URNs. With one exception, they often
forget to write "urn:gm:" (a gm parts catalog). this is overhead for them.
Most of actual browsers add "http://" in front of a URL. People have just
to type the "www.something.xxx" address and the system convert that to
"http://www.something.xxx". We have an issue here. How can we still provide
this feature for URLs and URNs. Both naming conventions have to live in the
*user experience
sphere" at the same time or for a certain time. How can we known the person
just typed a URN or a URL if the string is not complete? Because browser
offer this feature, a lot of
users just type the parts number expecting that the repetitive part will be
appended by the machine.So we resolved this *practical issue* by reducing
URLs to URNs and always append the "urn:" stuff at the beginning. We treat
URLs as a name space. then internally branch to different name spaces like
"url", "gm", "isdn". Even with that, people have a lot of difficulties to
adapt to "url:www.something.xxx" but most of them could as soon as they saw
the benefits to get things the way they where doing before the URL
everywhere area. To keep, the same feature as the actual browsers have we
parse to see if there is an other "xxx:" pattern, if yes it is a urn. If
no, it is a URL. This way people don't have to type "urn:url", they keep
the same notation they are used with today. However, they still have to
type the <NID> if this not the URL <NID>. Our solution is maybe not optimum
but, from this
experiment we can say that in order to  have a certain coherency with
actual browsers, 
we had to reduce URLs as name spaces or subset of URNs. This way
the *mental model* of users where more *coherent*. To prevent
*cognitive dissonance" they have to synthesize URLs and URNs in some ways.
This is a issue to resolve. How do we integrate in a coherent model URLs
and URNs not from the machine point of view but from the human point of
view. Don't forget that for people, a URL is a kind of name even if it is
an imperfect one. 

b) Most of Web catalogs or index exchange systems use languages like SOIF,
IATA,
etc... to encode a collection of items. Most of them use URLs to uniquely
identify these items within a collection. We experimented with an other
language and changed with Guha (ex: from Apple Research now at Netscape)
the item identification from URLs to URNs. We use a specific <NSS> inspired
from
Daniel Laliberte work on "Path". Because we move part of a hierarchical
name space from one place to an other, we came with a relative URN scheme.
For two reasons: 1- less typos. It is long and tedious to rewrite again and
again the same URN. We created the notion of a base URN and a concatenation
rule to obtain an absolute URN. 2- the second reason is because we move a
branch of a hierarchical name space. So, it means that all elements have to
keep the same relationship. This mini hierarchy is inserted at an insertion
point within a target hierarchical name space. Fact (2) forced us to use a
relative scheme and therefore invent a relative URN scheme. As you surely
noticed
the URN is then relative to the insertion point within the target name
space. We tried this simple algorithm with other name spaces like flat name
spaces (like the ones you find in parts catalog). We saw that this
algorithm offers no gain especially if the name space has no implicit
hierarchy pattern. The issue here is: some target name space use a
delimiter different from "/". It could be "!" (we encountered that with
objects contained within apps like words or excel or more generally in apps
supporting the OLE container scheme), it could be "\" in the Windows
universe, it could be "/" in the XFN universe. Thus, the issue is that
these name spaces have all hierarchical delimiters and are candidates for
relative naming from a base. So we decided to implement a relative scheme
base on a base URN with its the original syntax like for example
"urn:shell32:Desktop\MyComputer\c:\" and include all items from there or
(because shell32 has a name space scheme independent of the file system)
"urn:shell32:Desktop\" and append all relative URN to this base. Anyway, we
had to convert most of hierarchical delimiters to the target name space.
Why? because people get used to a certain delimiter and have a lot of
difficulties to change their habits. Thus, if the hierarchical name space
delimiter is "\" we don't force the nottion to be transformed into "/", we
just keep the original name space notation. We just provide translation
from one name space with, for example, a delimiter of type "\" to a target
one with delimiter of type "/" by tranforming the hierarchy delimitation
from "\" to "/". Same process for other kinds of delimiters

As you see, when we talk about *diversity* we talk about *name spaces*.

Overall experience about URN:

We separated the URN resolution mechanism from the URN syntax as a human
would write it. We made the assumption that the actual draft is intended
for
a machine having to send a URN to an other machine for resolution. We
deduced that a <NSS> could be written like it is and don't require encoding
(for human of course).
Thus, there is no clear separation of how a human write a URN (humans
doesn't like to convert into octal) and how a machine transfer that URN to
an other one to be resolved. As I said we made the assumption that a name
space could be written as it is. We also made the assumption that if a name
space use "." ,for instance, to express a hierarchy, we can deduce that
having to include
part of a name space into an other (at an insertion point) we could have a
base like "urn:dot:one.two.three" and insert a that point (relative to)
relative URNs of type: "one", "two" to obtain respectively :
urn:dot:one.two.three.one
urn:dot:one.two.three.two
Thus, we thought this would be OK and made the assumption that the group
meant that octal or %xxx scheme is for machines only not for humans having
to
write a name.

Issue not resolved:

How do we integrate URLs and URNs in the same world. Do we include URLs as
a name space? We reduced URL as a URN <NID>  to resolve the "cognitive
dissonance" introduced
by the clash of these two world. Here we made the assumption (and a lot of
testers did) that URLs are just an other URN name space.

Thus, if we want sometime to speak of *practical* experiments or of
*practical* problems and issues induced by the URN scheme, we would be more
than happy
to ear and see how people starting to put neurotic energy on these down to
earth problems like:

 - URL, URNs integration.
 - What, as a user, do I type in the address box of my browser
 - How can we use URNs in the context of UNC or directory/catalog exchange
mechanism

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 14 May 1997 12:56:08 -0500 (CDT)
To: Larry Masinter <[email-masked]>
Cc: URN Workgroup <[email-masked]>
Subject: [URN] urn:// syntax (was: Relative URNs)
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Larry Masinter writes:
 > [...] That is, continued discussion is completly
 > moot, and there's no point in continuing to fill our mailboxes
 > with the discussion of ":" vs "/" since, as far as I can
 > tell, no one is actually changing their mind about this,

One more try.  I apologize for not jumping on this particular issue
when it was time to consider it.  But there is always time, really,
if you factor in implementability and deployment of a brand new
technology.

The "urn:" prefix was agreed on with the argument that no one at the
IETF meeting had sufficient reason *not* to require it.  Once that
decision had been made, then the next decision should be about what
follows.  Without the "urn:" prefix, it makes sense to think about the
syntax as "<nid>:<opaque-string>", but with the "urn:" prefix, it is a
different story.  (I was still assuming that the "urn:" question was
open, so I didnt pursue the rest.  My mistake.  I also had assumed that
the IESG would be more questioning.  ...nevertheless...)

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

Given the "urn:" prefix, then the syntax *should* have been

  urn://<nid>/<opaque-string>

because that fits in with the generic URI syntax.  If we can use the
same kind of argument made for the "urn:" prefix, I would argue that
no one has given sufficient reason why the syntax should *not* be as
given above, and there is sufficient reason for why that *should* be
the syntax.

I don't really care about the "urn:" prefix.  I *do* care about
fitting in with the generic URI syntax.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

From: Hallam-Baker <[email-masked]>
Subject: Re: [URN] Re:  Relative URNs
To: [email-masked] (Jon Knight)
Date: Wed, 14 May 1997 13:17:48 -0400 (EDT)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Hallam-Baker <[email-masked]>

> > Those tools are not going to be rewritten at the behest of an
> > IETF working group. They are the installed base which the 
> > group has to work arround and interface to.
> 
> Did I miss something?  When did the URN group ask people to rewrite URL
> processing tools?  There are precious few URN tools available at the
> moment - its those that discussions and outcomes from this WG will affect.

I wouldn't spend too long waiting for URN processing tools. There won't
be any unless people can start by using the tools they have.

We had to swallow SGML to get HTML accepted.

I've been arround the IETF long enough to know that working groups don't
necessarily have any effect. At the moment I don't see anyone with
industry influence supporting the proposal. I don't see Microsoft,
Netscape or any other main player. 

> I was under the misapprehension that the URI working group was killed off
> due to lack of progress on the other UR* apart from URLs.  I don't even
> recall the gopher URL being particularly contentious compared to
> URNs/URCs/et al. 

It was contentious to the HTTP folks like myself because it did not support
hierarchy. The gopher people thought it was just perfect the way it is.
They were warned but didn't take any notice. As a result gopher URLs are
practically extinct.

> That's what the group has been trying to do for ages.  Unfortunately
> reality is rarely clean and tidy and there are lots of "gotchas" to
> consider.  Relative URNs may well be a nasty gotcha and if the group comes
> to a consensus that this is the case then not including provision for them
> in the URN specs sounds like a good idea to me.

Relative URNs may also turn out to be essential to allowing people to
use the infrastructure.

I'm not particularly interested in the consensus the group comes to. It
is the consensus the IETF generally and the market comes to that interests
me.

Phill

Date: Wed, 14 May 1997 19:10:25 +0200 (MET DST)
From: "Martin J. Duerst" <[email-masked]>
To: Ryan Moats <[email-masked]>
cc: "[email-masked]" <[email-masked]>, "Kent Karlsson (edv EDV exf EXF iI)" <[email-masked]>, URN mailing list <[email-masked]>
Subject: Re: [URN] Re: URNs and encoding
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Wed, 14 May 1997, Ryan Moats wrote:

> On Tue, 13 May 1997 18:02:47 +0200, Kent Karlsson wrote:
> 
> >This only adds to the character encoding mess: yet another way of
> >encoding characters.  There are too many already and adding yet
> >another one does not solve anything. Replace the above quote with:

> >No further encoding please!  The mess created with Quoted-printable
> >still haunts us, making some e-mail messages unreadable when the
> >decoding fails (which it still often and easily does).

> 2.  The text as it reads in the RFC was the product of a LOT of discussion
> in the Working Group and on the Mailing List.  "%<hex><hex>" encoding is
> not adding a "new" encoding scheme, it is borrowing from the URL syntax
> and was a fundamental part of the compromise reached on internationalization.
> Removing this language would break the compromise, which would not result
> in any progress (but rather regress) so I am EXTREMELY loath to do it (especially
> given the history that resulted in the original compromise).  Of course, if rough
> consensus appears that such a modification is a good thing, then my position (as
> editor) will change.

This is a good account of how things went. The main argument of those
insisting on something such as %HH was that handling of beyond-ASCII
characters in Unicode/UTF-8 and otherwise was not yet well developped.
This will definitiely change overtime. Currently, there is work going
on related to the URL syntax draft, in the otherwise defunct uri
mailing list, that will probably go one or two steps further.
So I am sure that time will come when the %HH will be removed.

Of course, as I was on the other side of the compromize, I wouldn't
mind if we could move ahead now or even earlier :-).

Regards,	Martin.

Date: Wed, 14 May 1997 10:10:21 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: URN Workgroup <[email-masked]>
Subject: Re: [URN] Re:  Relative URNs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> I was under the misapprehension that the URI working group was killed off
> due to lack of progress on the other UR* apart from URLs.  I don't even
> recall the gopher URL being particularly contentious compared to
> URNs/URCs/et al. 

I always prefer to say that the URI working group closed because
we had completed all of the work in our charter, and had no
consensus for what additional work we were going to pursue.

You might think this is revisionist history, but I think that
the example of closing working groups when they are done and
spawning new groups when there's some clearer grounds for it
is a good model, and we're trying to follow it with HTTP, too.

There is now a Proposed Standard for URNs. URNs will progress
if there are interoperable implementations. I suggest,
rather than continuing to debate the points that went into
the preparation of the Proposed Standard again, continuously,
that you go off and see if you can build an interoperable
implementation. That is, continued discussion is completly
moot, and there's no point in continuing to fill our mailboxes
with the discussion of ":" vs "/" since, as far as I can
tell, no one is actually changing their mind about this, and
in that situation, the only question is whether the Proposed
Standard is actually implementable. But discussing it in
the abstract ("X would be easier to implement") isn't
getting us anywhere.

Normally I just delete the [URN] messages that cross
my mailbox because of the irrelevance of the continued
speculation, but it's a little tiresome. Clearly there
were *some* people in the URN group who were in the
process of building what they hoped would be interoperable
implementations, and what we need to hear from them is
the results of their experiments and some experience-based
discussion of how their software deals with the complex
issues we're raising, e.g., how one would give a URN
(several URNs? URNs for each slide?) for the powerpoint
presentation converted to HTML. Do you use relative URNs?
Is there only one "top-level URN" which resolves to
URLs for the individual components?

Regards,

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

Date: Wed, 14 May 1997 17:42:36 +0100 (BST)
From: Jon Knight <[email-masked]>
To: "Phillip M. Hallam-Baker" <[email-masked]>
cc: didier ph martin <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re:  Relative URNs
Sender: [email-masked]
Reply-To: Jon Knight <[email-masked]>

On Wed, 14 May 1997, Phillip M. Hallam-Baker wrote:
> There is a large business selling Web tools that already uses
> URLs and relative URLs. My powerpoint slide converter for
> example Powerpoint goes in, HTML comes out complete with
> relative URLs.
> 
> Those tools are not going to be rewritten at the behest of an
> IETF working group. They are the installed base which the 
> group has to work arround and interface to.

Did I miss something?  When did the URN group ask people to rewrite URL
processing tools?  There are precious few URN tools available at the
moment - its those that discussions and outcomes from this WG will affect.
 
> I've heard the arguments about "relativity" and how / should not
> be defined to be hierarchical before - indeed by certain people
> on this group. At the time they were calling themselves the 
> gopher group. The last time I sent a working group on names a 
> flame of this nature was to tell the URI working group that the
> spec for the gopher URL would kill it. I was right that time.

I was under the misapprehension that the URI working group was killed off
due to lack of progress on the other UR* apart from URLs.  I don't even
recall the gopher URL being particularly contentious compared to
URNs/URCs/et al. 
 
> IF you want people to use the design then make the effort to fit 
> into the world the rest of us inhabit.

That's what the group has been trying to do for ages.  Unfortunately
reality is rarely clean and tidy and there are lots of "gotchas" to
consider.  Relative URNs may well be a nasty gotcha and if the group comes
to a consensus that this is the case then not including provision for them
in the URN specs sounds like a good idea to me.
 
> IF you are more committed to purity do not provide for relative 
> URLs, make the scheme incompatible with the rest of the 
> architecture of the Web and watch it be ignored.

Erm, relative URLs already exist.  The URN group doesn't have anything to
do with URLs (other than having URNs resolve into them).  Relative URNs
are a different matter entirely - URNs aren't just glorifed URLs
(otherwise we might as well just use PURLs and packup our bags and go off
for a nice walk or a beer).
 
> This group does not have a monopoly on the idea of a DNS 
> indirection pointer to allow host independent resolution of
> URLs. Now the hard part has been done its a simple matter
> to take the current draft and rewrite it to fit in with the rest
> of reality. Then the authors have to decide if they want
> the name on the alternative RFC.

Well volunteered that man! :-)

Tatty bye,

Jim'll

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
* I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *

From: "Phillip M. Hallam-Baker" <[email-masked]>
To: "didier ph martin" <[email-masked]>, "URN Workgroup" <[email-masked]>
Subject: Re: [URN] Re:  Relative URNs
Date: Wed, 14 May 1997 11:57:15 -0400
Sender: [email-masked]
Reply-To: "Phillip M. Hallam-Baker" <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_01BC605D.F7FED7B0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

 >It may be completely reasonable for a user interface to deal in
>partial (relative) URNs, if there is some way for the user to know
>what the base is, to the extent one wants users to deal directly with
>URNs at all.  

If you want people to ever use the things you will need to 
allow for relative URNs and replace the colons with slashes.

There is a large business selling Web tools that already uses
URLs and relative URLs. My powerpoint slide converter for
example Powerpoint goes in, HTML comes out complete with
relative URLs.

Those tools are not going to be rewritten at the behest of an
IETF working group. They are the installed base which the 
group has to work arround and interface to.

The decision to use colons where the rest of the Web uses
slashes seems to be one of those ideological commitments
that groups take up from time to time. 

I've heard the arguments about "relativity" and how / should not
be defined to be hierarchical before - indeed by certain people
on this group. At the time they were calling themselves the 
gopher group. The last time I sent a working group on names a 
flame of this nature was to tell the URI working group that the
spec for the gopher URL would kill it. I was right that time.

What this group has come up with is a URL with a level of
indirection. That is a usefull thing *IF* you ignore the pretensions
to grander designs. If the purpose of a label is to retrieve
an object it is a locator end of story. If the purpose is to 
identify a concept (as in PEP or PICS) then it is a name
but the meaning is given by usage and resolution is irrelevant.

IF you want people to use the design then make the effort to fit 
into the world the rest of us inhabit.

IF you are more committed to purity do not provide for relative 
URLs, make the scheme incompatible with the rest of the 
architecture of the Web and watch it be ignored.

This group does not have a monopoly on the idea of a DNS 
indirection pointer to allow host independent resolution of
URLs. Now the hard part has been done its a simple matter
to take the current draft and rewrite it to fit in with the rest
of reality. Then the authors have to decide if they want
the name on the alternative RFC.

Phill

------=_NextPart_000_01BC605D.F7FED7B0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIIBCwYJKoZIhvcNAQcCoIH9MIH6AgEBMQswCQYFKw4DAhoFADALBgkqhkiG9w0BBwExgdowgdcC
AQEwdjBiMREwDwYDVQQHEwhJbnRlcm5ldDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNDAyBgNV
BAsTK1ZlcmlTaWduIENsYXNzIDEgQ0EgLSBJbmRpdmlkdWFsIFN1YnNjcmliZXICEGFDFWiEgdTV
ot4rXibJq8UwCQYFKw4DAhoFADANBgkqhkiG9w0BAQEFAARASrJRyBeXh/HBS3nljTod8ZlKHqvG
SP/YG2yEsakEOjFqkfdq9R+ksysYcOwC2P8BDjw1GlZXUddpIjPkSw9ilw==

------=_NextPart_000_01BC605D.F7FED7B0--

Date: Wed, 14 May 1997 09:04:48 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
CC: [email-masked]
Subject: [URN] draft-ietf-urn-ietf-00.txt
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

--------------2F667DBB48B4
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached is a new internet draft submission (draft-ietf-urn-ietf-00.txt)
"A URN Namespace for RFC Family Documents"

--------------2F667DBB48B4
Content-Type: text/plain; charset=us-ascii; name="urn.ietf.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="urn.ietf.txt"

Internet-Draft                                                Ryan Moats
draft-ietf-urn-ietf-00.txt                                          AT&T
Expires in six months                                           May 1997

                 URN Namespace for RFC series documents
                  Filename: draft-ietf-urn-ietf-00.txt

Status of This Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its
      areas, and its working groups.  Note that other groups may also
      distribute working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time.  It is inappropriate to use Internet-
      Drafts as reference material or to cite them other than as ``work
      in progress.''

      To learn the current status of any Internet-Draft, please check
      the ``1id-abstracts.txt'' listing contained in the Internet-
      Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
      Coast), or ftp.isi.edu (US West Coast).

Abstract

   A system for Uniform Resource Names (URNs) must be capable of
   supporting new naming systems.  As an example of the sort of
   information that needs to be supplied when proposing new namepsaces,
   this document presents a naming system based on the RFC family of
   documents (RFCs, STDs, and FYIs) developed by the IETF and published
   by the RFC editor.  This namespace can be supported within the URN
   framework and the currently proposed syntax for URNs.

0. Document History and Status

   With the first draft of this document, the only issue that has
   occured on the list is the discussion on functional equivalence for
   this namespace (see section 1.5).  There are currently two positions
   on this:  the first is what is specified here, and the second is that
   there is no equivalency for this namespace, e.g. a resolver receiving
   a request must return ONLY the resource named by that request.

Expires 11/97                                                   [Page 1]

INTERNET DRAFT   URN Namespace for RFC series documents         May 1997

1. Namespace Syntax

   Consistent with the URN syntax specification [1], each namespace must
   specify syntax related information that is specific to that
   namespace.  This section covers these specifications.

1.1. Namespace Identifier (NID)

   The namespace identifier for this namespace is "ietf".

1.2. Namespace Specific String (NSS)

   The Namespace Specific String has the following ABNF [2]
   specification:
           NSS = family ":" number

           family = "rfc" | "std" | "fyi"

           number = 1*DIGIT

           DIGIT = %x30..%x39

   The ABNF specification for "family" above is based on the current
   documents in the RFC family.  As new document series are added to the
   IETF family by the IESG (or its successor), this ABNF specification
   will need to be updated.  Any system intended to resolve names for
   this namespace should be written with the awareness that a new
   document series may be introduced at any time.

1.3. Additional Reserved Characters

   No characters in addition to those specified in [1] are reserved by
   this namespace.

1.4. Additional Lexical Equivalence Relations

   Note that the entire URN is case-insensitive, because of the
   defintion of the NSS.

1.5. Functional Equivalence Relations

   Rules for equivalence in this namespace are embedded in the document
   mappings maintained by the RFC Editor (the index files "rfc-
   index.txt", "fyi-index.txt", "std-index.txt").  A resource is
   equivalent to the set of resources implied by the "(Also...)"
   construct in these mappings.  As an example, the URN
   "urn:ietf:rfc:1661" is equivalent to th URN "urn:ietf:std:51" because
   the "rfc-index.txt" map shows that RFC 1661 is also STD 51.  However,

Expires 11/97                                                   [Page 2]

INTERNET DRAFT   URN Namespace for RFC series documents         May 1997

   the URN "urn:ietf:std:51" is equivalent to the SET of URNs
   "urn:ietf:rfc:1661" and "urn:ietf:rfc:1662" since the "std-index.txt"
   shows that STD 51 is also RFC 1661 and RFC 1662.  Therefore, a
   resolver receiving a N2R request for "urn:ietf:std:51" MUST return
   either STD 51 or BOTH RFC 1661 and RFC 1662.

2. Security Considerations

   Because this namespace defines no additional reserved characters, it
   does not add any security considerations beyond those inherent from
   the existence of the reserved characters from [1].  Further, the
   definition of the NSS above does not use any of the reserved
   characters from [1], which means that resolvers for this namespace
   may be considered "secure" in the sense that any escaping of
   characters in the NSS MUST result in the resolver indicating that the
   URN has incorrect syntax.

3. Acknowledgments

   Thanks to various members of the URN working group for comments on
   earlier drafts of this document.  This document is partially
   supported by the National Science Foundation, Cooperative Agreement
   NCR-9218179.

4. References

   Request For Comments (RFC) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

         [1]         R. Moats, "URN Syntax," RFC 2141, May 5, 1997.

         [2]         D. Crocker, P. Overell, "Augmented BNF for Syntax
                     Specifications: ABNF," Internet Draft (work in pro-
                     gress), January 1997.

5. Author's Address

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   USA

   Phone:  +1 402 894-9456
   EMail:  [email-masked]

              This Internet Draft expires November 30, 1997.

Expires 11/97                                                   [Page 3]

INTERNET DRAFT   URN Namespace for RFC series documents         May 1997

Expires 11/97                                                   [Page 4]

--------------2F667DBB48B4--

From: "Ryan Moats" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Kent Karlsson (\e\d\v \E\D\V \e\x\f \E\X\F \i\I)" <[email-masked]>
Cc: "URN mailing list" <[email-masked]>
Date: Wed, 14 May 97 08:33:46 
Priority: Normal
Subject: [URN] Re: URNs and encoding
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Tue, 13 May 1997 18:02:47 +0200, Kent Karlsson (\e\d\v \E\D\V \e\x\f \E\X\F \i\I) wrote:

>This is sent to the e-mail address at the end of the rfc 2141 (URNs).
>
>		URNs and coding of characters
>
>   Translation is done
>   by encoding each character outside the URN character set as a
>   sequence of one to six octets using UTF-8 encoding [5], and the
>   encoding of each of those octets as "%" followed by two characters
>   from the <hex> character set above. The two characters give the
>   hexadecimal representation of that octet.
>
>This only adds to the character encoding mess: yet another way of
>encoding characters.  There are too many already and adding yet
>another one does not solve anything. Replace the above quote with:
>
>   Translation is done
>   by encoding each character outside the URN character set as a
>   sequence of one to six octets using the UTF-8 encoding [5].
>
>No further encoding please!  The mess created with Quoted-printable
>still haunts us, making some e-mail messages unreadable when the
>decoding fails (which it still often and easily does).
>
>			/kent karlsson

I am sending this both do the original sender and the URN mailing
list (because it is relevant that the whole list (and the archives) "see"
it.

1. Please check the archives for the history of URN encoding.
The archives are located at ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive/
with a mirror at ftp://ds.internic.net/ietf/urn/urn-archives/.  The archives
are also searchable using WAIS from http://www.internic.net/ds/urnwais.html.

2.  The text as it reads in the RFC was the product of a LOT of discussion
in the Working Group and on the Mailing List.  "%<hex><hex>" encoding is
not adding a "new" encoding scheme, it is borrowing from the URL syntax
and was a fundamental part of the compromise reached on internationalization.
Removing this language would break the compromise, which would not result
in any progress (but rather regress) so I am EXTREMELY loath to do it (especially
given the history that resulted in the original compromise).  Of course, if rough
consensus appears that such a modification is a good thing, then my position (as
editor) will change.

Ryan Moats

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re:  Relative URNs
Date: Fri, 9 May 1997 17:07:31 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

Karen Sollins wrote:

* If relative URNs are bound in only one namespace (ever), then there
is no point to them other than to save typing for humans.  That is
really a matter of user interface, not underlying representation and
storage.

It may be completely reasonable for a user interface to deal in
partial (relative) URNs, if there is some way for the user to know
what the base is, to the extent one wants users to deal directly with
URNs at all.  This may shorten the text presented to or typed by the
user.  In fact, what someone does privately inside his or her machine
about representing URNs may also vary.  It still should be the case
that if and when URNs leave private space, they should be absolute.
Given the namespace assignment and base problems, I haven't yet been
convinced by the arguments that we can or should want to try to
overcome these problems.  There is a benefit for URLs, but I just
don't see it for URNs.  In fact, it may be impossible to legislate
against relative URNs, but I think we should warn against using them
with a clear statement of the pitfalls."

-> Your point about separation of private space(UI) and public space is
interesting. Yes this is true that relative URNs save typos for humans.
Obviously machine don't care. I agree with that fact that to be adequately
resolved URNs should be absolute. 

I guess that now we will have to work on the private space problems when
people read a listing or document containing relative URNs. Or for
different interpreters to resolve ambiguities within a document using
relative URNs.

However, it is clear that between a client and a server an absolute URN has
to be exchanged to be adequately resolved.

Didier PH Martin
[email-masked]

From: [email-masked]
Date: Fri, 9 May 1997 16:11:41 -0400
Subject: [URN] Returned mail: Service unavailable
To: <[email-masked]>
To: [email-masked]
To: [email-masked] (: [email-masked]"@Bunyip.Com)
Sender: [email-masked]
Reply-To: [email-masked]

The original message was received at Fri, 9 May 1997 16:11:27 -0400
from [199.191.146.41]

   ----- The following addresses had delivery problems -----
<[email-masked]>  (unrecoverable error)

   ----- Transcript of session follows -----
... while talking to qsun.ho.att.com.:
>>> DATA
<<< 554 [email-masked] (,        ""'URN Workgroup'" <[email-masked]>   Date":) (07 May 1997 14:"09:44 -0400   Sender: owner-urn-ietf... Unbalanced '('
554 <[email-masked]>... Service unavailable

   ----- Original message follows -----
Date: Fri, 09 May 1997 15:46:20 -0400
From: [email-masked] (Karen R. Sollins)
Auto-Forwarded-From: [email-masked] (Richard V. Huber)
Sender: [email-masked]
Subject: Re: [URN] Re: About realtive URNs
Reply-To: [email-masked] (Karen R. Sollins)
To: [email-masked]
Original-CC: [email-masked], [email-masked], [email-masked],
        [email-masked], [email-masked], [email-masked]
content-length: 2164

   > If relative URIs for URNs are allowed but not required in all cases,
   > then we have left the door open for any applications that can use 
   >  "relative URNs".

   This is missing the point.  Relative URNs are harmful to URNs.

   Keith

I agree.  So far, I have not been convinced by the arguments that
there is a benefit to allowing support for relative URNs.  It does NOT
follow from the benefit of using relative URLs.  The underlying
difference is that URNs are not reassignable (intentionally so)
whereas URLs are (also intentionally so).  The problems are:

* If relative URNs can be bound to absolute URNs in more than one
namespace, the two (or more) namespaces in which they will be made
absolute will need to coordinate carefully, to avoid duplicate
assignment.  At this point the namespaces have lost their independence
- not a great idea.

* Ron has made the valid point that it may be impossible to know which
URN is the base unless it is always explicit, using a mechanism similar
to that for URLs, and even then there are possibilities for ambiguity.

* If relative URNs are bound in only one namespace (ever), then there
is no point to them other than to save typing for humans.  That is
really a matter of user interface, not underlying representation and
storage.

It may be completely reasonable for a user interface to deal in
partial (relative) URNs, if there is some way for the user to know
what the base is, to the extent one wants users to deal directly with
URNs at all.  This may shorten the text presented to or typed by the
user.  In fact, what someone does privately inside his or her machine
about representing URNs may also vary.  It still should be the case
that if and when URNs leave private space, they should be absolute.
Given the namespace assignment and base problems, I haven't yet been
convinced by the arguments that we can or should want to try to
overcome these problems.  There is a benefit for URLs, but I just
don't see it for URNs.  In fact, it may be impossible to legislate
against relative URNs, but I think we should warn against using them
with a clear statement of the pitfalls.

			Karen Sollins

From: "Ryan Moats" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "URN mailing list" <[email-masked]>
Date: Fri, 09 May 97 14:52:50 
Priority: Normal
Subject: Re: [URN] Zeroth draft of IETF namespace doc (-00)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Fri, 09 May 1997 13:33:22 -0600, [email-masked] wrote:

>At 03:38 PM 5/5/97, Ryan Moats wrote:
>> my opinion is that if a resolver is asked for 
>>a document in the STD and FYI family, it may return EITHER the std/fyi
>document
>>or ALL of the RFCs that map to the requested document based on the RFC
>Editor's
>>citation index (std-index.txt for STD and fyi-index.txt for FYI).  As
>additional family series
>>are introduced, the rules for the new series must be added.
>>
>>What I haven't answered (as yet) is "Can a request for a RFC result in an
>STD or FYI
>>being returned?" .  This is the first step to "Can a request for a RFC
>result in the STD or FYI
>>(or RFC for that matter) that has superceded that document. I'll answer
>these two questions
>>in two parts, and I'm sure we'll discuss my proposal ;-).
>
>Gee Ryan, what ever gave you *that* idea?  :-)
>
>>1) I don't have a problem with a RFC request resulting in a FYI or STD
>being returned
>>that is a superset of the request RFC.  Therefore, I have no problem with
>a request
>>for RFC 1661 resulting in STD 51 being returned
>
>Hmmm. Personally I am less than thrilled with the idea of asking for
>"X" and getting "X plus all this other cruft". However, more on that
>in a minute.
>
>>( I do have a problem with a STD 51 request
>>resulting in RFC 1661 ALONE being returned).
>
>Right, that would clearly be an unacceptable loss of information.
>
>>2) I don't think that a request for an obsoleted RFC should result in
>anything other than the
>>obsoleted RFC being returned.  The server doesn't know whether the user is
>actually looking for
>> the STD or FYI and not the obsoleted RFC for historical (histerical?)
>reasons.
>
>I agree with this as well. It is also current practice at the RFC archives.
>
>>Finally, a point of opinion.  I view N2N requests as a method of revealing
>functional equivalence.
>>The way N2N works in the current implementation of this namespace may help
>reveal how
>>I view functional equivalence in this namespace.
>
>N2N may be one way, or N2C can provide more detailed information on
>equivalances.
>
>Now for my summary of the rules:
>  Ever since the URI-WG discussions long ago, we have agreed that resolving
>  a URN should result in "the same" resource being returned, where the
>  judgement of similarity was in the eye of the name assigner. "Cool site
>  of the day" is an example where the content is going to vary quite a bit
>  depending on when you resolve it, but that is OK given the intention for
>  that particular name. Therefore, if we ask for resource x, the resolver is
>  free to return any damn thing it wants as long as that follows the rules
>  of the name assigner.
>
>  For the particular case of IETF STDs, FYIs, and RFCs, the rules of the
>  name assigner are given in the std-index.txt, fyi-index.txt, and
>  rfc-index.txt files. Looking at those, RFC1661 says "(Also STD0051)"
>  while std-index.txt says "(Also RFC1661 and RFC1662)". From this I
>  conclude that it is ok to answer a request for 1661 with std51, or
>  to answer a query for 51 with 1661 and 1662 together. What is nasty
>  about this train of thought is that those files also say things like
>  RFC1548: "(Updated by RFC1661)". Were I a person who believes in total
>  consistency of action, this might be interpreted as never allowing me
>  to get obsolete documents. Fortunately, that particular hobgoblin has
>  never troubled me. We also have the demonstrated behavior of the various
>  RFC sites where we can get obsolete versions. So, I think your rules are
>  OK  ***for this particular namespace***.
>
>  Other namespaces may take a different stand on the question of equivalance.
>  They might, for example, not allow returning a superset of a requested
>  resource. Just because the IETF namespace allows it, people should not
>  interpret that as meaning it is the accepted practice in all namespaces.

Agreed.  All I'm talking about are the equivalency relations specified "for this namespace"
alone.

I propose the text of Section 1.5 should read:

Rules for equivalence in this namespace are embedded in the document mappings
maintained by the RFC Editor (the index files "rfc-index.txt", "fyi-index.txt", "std-index.txt").
A resource is equivalent to the set of resources implied by the "(Also" construct in these
mappings.  As an example, the URN "urn:ietf:rfc:1661" is equivalent to "urn:ietf:std:51" because
the "rfc-index.txt" map indicates that RFC 1661 is also STD 51.  However, STD 51 is 
equivalent to the SET of URNs "urn:ietf:rfc:1661" AND "urn:ietf:rfc:1662" since the "std-index.txt"
indicates that STD 51 is also RFC 1661 and RFC 1662.  Therefore, a resolver receiving
a N2R request for "urn:ietf:std:51" MUST return either STD 51 or BOTH RFC 1661 and RFC 1662.

I think this covers all the points here...

Ryan

Date: Fri, 9 May 1997 15:46:20 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: About realtive URNs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

   > If relative URIs for URNs are allowed but not required in all cases,
   > then we have left the door open for any applications that can use 
   >  "relative URNs".

   This is missing the point.  Relative URNs are harmful to URNs.

   Keith

I agree.  So far, I have not been convinced by the arguments that
there is a benefit to allowing support for relative URNs.  It does NOT
follow from the benefit of using relative URLs.  The underlying
difference is that URNs are not reassignable (intentionally so)
whereas URLs are (also intentionally so).  The problems are:

* If relative URNs can be bound to absolute URNs in more than one
namespace, the two (or more) namespaces in which they will be made
absolute will need to coordinate carefully, to avoid duplicate
assignment.  At this point the namespaces have lost their independence
- not a great idea.

* Ron has made the valid point that it may be impossible to know which
URN is the base unless it is always explicit, using a mechanism similar
to that for URLs, and even then there are possibilities for ambiguity.

* If relative URNs are bound in only one namespace (ever), then there
is no point to them other than to save typing for humans.  That is
really a matter of user interface, not underlying representation and
storage.

It may be completely reasonable for a user interface to deal in
partial (relative) URNs, if there is some way for the user to know
what the base is, to the extent one wants users to deal directly with
URNs at all.  This may shorten the text presented to or typed by the
user.  In fact, what someone does privately inside his or her machine
about representing URNs may also vary.  It still should be the case
that if and when URNs leave private space, they should be absolute.
Given the namespace assignment and base problems, I haven't yet been
convinced by the arguments that we can or should want to try to
overcome these problems.  There is a benefit for URLs, but I just
don't see it for URNs.  In fact, it may be impossible to legislate
against relative URNs, but I think we should warn against using them
with a clear statement of the pitfalls.

			Karen Sollins

Date: Fri, 09 May 1997 13:33:22 -0600
To: "Ryan Moats" <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] Zeroth draft of IETF namespace doc (-00)
Cc: "URN mailing list" <[email-masked]>
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 03:38 PM 5/5/97, Ryan Moats wrote:
> my opinion is that if a resolver is asked for 
>a document in the STD and FYI family, it may return EITHER the std/fyi
document
>or ALL of the RFCs that map to the requested document based on the RFC
Editor's
>citation index (std-index.txt for STD and fyi-index.txt for FYI).  As
additional family series
>are introduced, the rules for the new series must be added.
>
>What I haven't answered (as yet) is "Can a request for a RFC result in an
STD or FYI
>being returned?" .  This is the first step to "Can a request for a RFC
result in the STD or FYI
>(or RFC for that matter) that has superceded that document. I'll answer
these two questions
>in two parts, and I'm sure we'll discuss my proposal ;-).

Gee Ryan, what ever gave you *that* idea?  :-)

>1) I don't have a problem with a RFC request resulting in a FYI or STD
being returned
>that is a superset of the request RFC.  Therefore, I have no problem with
a request
>for RFC 1661 resulting in STD 51 being returned

Hmmm. Personally I am less than thrilled with the idea of asking for
"X" and getting "X plus all this other cruft". However, more on that
in a minute.

>( I do have a problem with a STD 51 request
>resulting in RFC 1661 ALONE being returned).

Right, that would clearly be an unacceptable loss of information.

>2) I don't think that a request for an obsoleted RFC should result in
anything other than the
>obsoleted RFC being returned.  The server doesn't know whether the user is
actually looking for
> the STD or FYI and not the obsoleted RFC for historical (histerical?)
reasons.

I agree with this as well. It is also current practice at the RFC archives.

>Finally, a point of opinion.  I view N2N requests as a method of revealing
functional equivalence.
>The way N2N works in the current implementation of this namespace may help
reveal how
>I view functional equivalence in this namespace.

N2N may be one way, or N2C can provide more detailed information on
equivalances.

Now for my summary of the rules:
  Ever since the URI-WG discussions long ago, we have agreed that resolving
  a URN should result in "the same" resource being returned, where the
  judgement of similarity was in the eye of the name assigner. "Cool site
  of the day" is an example where the content is going to vary quite a bit
  depending on when you resolve it, but that is OK given the intention for
  that particular name. Therefore, if we ask for resource x, the resolver is
  free to return any damn thing it wants as long as that follows the rules
  of the name assigner.

  For the particular case of IETF STDs, FYIs, and RFCs, the rules of the
  name assigner are given in the std-index.txt, fyi-index.txt, and
  rfc-index.txt files. Looking at those, RFC1661 says "(Also STD0051)"
  while std-index.txt says "(Also RFC1661 and RFC1662)". From this I
  conclude that it is ok to answer a request for 1661 with std51, or
  to answer a query for 51 with 1661 and 1662 together. What is nasty
  about this train of thought is that those files also say things like
  RFC1548: "(Updated by RFC1661)". Were I a person who believes in total
  consistency of action, this might be interpreted as never allowing me
  to get obsolete documents. Fortunately, that particular hobgoblin has
  never troubled me. We also have the demonstrated behavior of the various
  RFC sites where we can get obsolete versions. So, I think your rules are
  OK  ***for this particular namespace***.

  Other namespaces may take a different stand on the question of equivalance.
  They might, for example, not allow returning a superset of a requested
  resource. Just because the IETF namespace allows it, people should not
  interpret that as meaning it is the accepted practice in all namespaces.

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: "Ryan Moats" <[email-masked]>
To: "Ron Daniel, Jr." <[email-masked]>, "Sukanta Ganguly" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Fri, 09 May 97 14:08:42 
Priority: Normal
Subject: Re: [URN] Re: RFC 2141 on URN Syntax
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Fri, 09 May 1997 10:08:42 -0600, Ron Daniel, Jr. wrote:

>>I have a similar concern regarding the usage of "%" character within the
>><NSS> subsection. This is what the rule resolution says 
>><NSS> ::= 1*<URN chars>
>><URN chars> ::= <trans> | "%" <hex> <hex>
>><trans> ::= <upper> | <lower> | <number> | <other> | <reserved>
>><reserved> ::= '%" | "/" | "?" | "#"
>>
>>Here we observe that 
>>
>>  <NSS> ::= %    could be a valid rule according to the  rule definition. At
>>the same time the system has another defination that says wheneever "%" is
>>used two  <hex> characters should be used.
>>
>>  <NSS> ::=%%12  -> could also be a valid syntax for NSS.  
>>
>>My suggestion here is to remove "%" from the <reserved> subsection of <NSS>
>>rules.
>>
>>Please let me know if my thinking is along the lines of what the group has
>>in mind or am I way out of wack.
>
>Single occurances of '%' are disallowed. '%' is supposed to ALWAYS mean
>that the next two characters will be hex digits that are taken to
>form an octet.

This is a case of the RFC being ahead of an ABNF specification.
draft-ietf-urn-syntax-05.txt has the ABNF specification "aligned"
with draft-ietf-drums-abnf-02.txt.  There, the definition is

URN chars = trans | ( "%" hex hex)

Otherwise Ron is right.  There is text in RFC 2141 that specifically
says "%" by itself is not allowed and that a "%" character MUST
be followed by two "hex" characters so both NSS containing "%" above
are incorrect syntax.

Ryan

Date: Fri, 09 May 1997 10:08:42 -0600
To: Sukanta Ganguly <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: [URN] Re: RFC 2141 on URN Syntax
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 08:54 AM 5/9/97 -0600, Sukanta Ganguly wrote:
>Hi,
>  I wanted to mention some things about the rfc 2141 that I found confusing.

You should bring these questions up on the URN-WG list, not the
Web DAV list. The URN list is [email-masked]. I have added it
to the CC list on this reply.

>The syntax for a URN is specified as
><URN> ::= "urn:" <NID> ":" <NSS>
>and NSS also has ":" as a characters recognized within the <others> rule.
>Based on this
>    URN:foo::      -> Is this a valid URN ??

That will depend on the rules for the namespace foo. The URN syntax
is an attempt to be as liberal as possible so as to allow many
different namespaces to exist. The rules for particular namespaces
are intended to be much stricter. As an example, take a look at
the URN-WG's internet draft on using bibliographic identifiers as URNs.
Two of the namespaces in that document (ISBN and ISSN) disallow the use
of ':' and many other characters. The third (SICI) has much more
liberal rules because SICIs use lots of funny characters.

>I feel that is ":" is used as a reserved terminator of a subsection of a
>rule then it should not be used in the recognized character sets for the
>other sub-sections of the rule. So I would imagine that ":" is not present
>as a recognizable character within the <other> rule of NSS subsection.

The URN sytnax RFC takes a strong position on the first two occurances
of ':'. After that, it is up to particular namespaces how ':' is or is not
used.

>It just adds an extra amount of parsing effort for the applications to have
>this feature in their parsing mechanisms. I don't say that it is impossible
>to have it, but as a application developer, it  would be a much messy
>approach for me to write code that has this feature in it. I hope this not
>taken as a negative criticism. 

No, it is not taken as a negative criticism. However, one of the requirements
on URNs was the ability to grandfather legacy naming systems (such as SICIs).
If allowing ':' makes it easier to accomodate some naming schemes, then we
thought it would be worth some additional implementation difficulty. The
additional difficulty seems very small. The first two ':' characters are
required, so once one has stripped off the "urn:" prefix and the NID
field with its colon, no more special treatment of ':' is required for
a general URN parser. You will probably want to use the NID to lookup
special parsing rules for the namespace, but that is another story.

>I have a similar concern regarding the usage of "%" character within the
><NSS> subsection. This is what the rule resolution says 
><NSS> ::= 1*<URN chars>
><URN chars> ::= <trans> | "%" <hex> <hex>
><trans> ::= <upper> | <lower> | <number> | <other> | <reserved>
><reserved> ::= '%" | "/" | "?" | "#"
>
>Here we observe that 
>
>  <NSS> ::= %    could be a valid rule according to the  rule definition. At
>the same time the system has another defination that says wheneever "%" is
>used two  <hex> characters should be used.
>
>  <NSS> ::=%%12  -> could also be a valid syntax for NSS.  
>
>My suggestion here is to remove "%" from the <reserved> subsection of <NSS>
>rules.
>
>Please let me know if my thinking is along the lines of what the group has
>in mind or am I way out of wack.

Single occurances of '%' are disallowed. '%' is supposed to ALWAYS mean
that the next two characters will be hex digits that are taken to
form an octet.

>I appreciate your acceptance of my
>participation in the group.
>
>Thank You
>Sukanta Ganguly
>
>>>> Jim Whitehead <[email-masked]> 05/06/97 12:07PM >>>
>
>Of potential interest to participants of this WG.
>
>- Jim
>
>>To: IETF-Announce: ;
>>Subject: RFC 2141 on URN Syntax
>>Cc: [email-masked] 
>>Mime-Version: 1.0
>>Date: Mon, 05 May 97 13:53:28 PDT
>>Sender:[email-masked] 
>>From: RFC Editor <[email-masked]>
>>
>>
>>A new Request for Comments is now available in online RFC libraries.
>>
>>
>>        RFC 2141:
>>
>>        Title:      URN Syntax
>>        Author:     R. Moats
>>        Date:       May 1997
>>        Mailbox:    [email-masked] 
>>        Pages:      8
>>        Characters: 14077
>>        Updates/Obsoletes: None
>>
>>        URL:        ftp://ds.internic.net/rfc/rfc2141.txt 
>>
>>
>>Uniform Resource Names (URNs) are intended to serve as persistent,
>>location-independent, resource identifiers. This document sets
>>forward the canonical syntax for URNs.  A discussion of both existing
>>legacy and new namespaces and requirements for URN presentation and
>>transmission are presented.  Finally, there is a discussion of URN
>>equivalence and how to determine it. This document is the product of
>>the Uniform Resource Names Working Group of the IETF.
>>
>>This is now a Proposed Standard Protocol.
>>
>>This document specifies an Internet standards track protocol for the
>>Internet community, and requests discussion and suggestions for
>>improvements.  Please refer to the current edition of the "Internet
>>Official Protocol Standards" (STD 1) for the standardization state and
>>status of this protocol.  Distribution of this memo is unlimited.
>>
>>This announcement is sent to the IETF list and the RFC-DIST list.
>>Requests to be added to or deleted from the IETF distribution list
>>should be sent to [email-masked].  Requests to be
>>added to or deleted from the RFC-DIST distribution list should
>>be sent to [email-masked].
>>
>>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>>an EMAIL message to [email-masked] with the message body
>>help: ways_to_get_rfcs.  For example:
>>
>>        To: [email-masked] 
>>        Subject: getting rfcs
>>
>>        help: ways_to_get_rfcs
>>
>>Requests for special distribution should be addressed to either the
>>author of the RFC in question, or to [email-masked].  Unless
>>specifically noted otherwise on the RFC itself, all RFCs are for
>>unlimited distribution.
>>
>>Submissions for Requests for Comments should be sent to
>>[email-masked].  Please consult RFC 1543, Instructions to RFC
>>Authors, for further information.
>>
>>
>>Joyce K. Reynolds and Mary Kennedy
>>USC/Information Sciences Institute
>>
>
>
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                                                            
>                                               
>
>
>
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: "Ryan Moats" <[email-masked]>
To: "didier ph martin" <[email-masked]>, "URN Workgroup" <[email-masked]>
Date: Thu, 08 May 97 14:16:41 
Priority: Normal
Subject: Re: [URN] Re: Relative URNs, URLs, URIs????
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 8 May 1997 14:31:50 -0400, didier ph martin wrote:

>        Leslie Daigle wrote:
>
>    >1. individual namespaces can define whatever relational rules are
>           appropriate to their needs   (and those needs will be many and
>           varied)"
>
>OK for that. I totally agree. 
>
>  >     2. the current syntax does include the "/" as a potential hierarchy
>           delimiter for those namespaces that choose to permit a
>           hierarchy to be thus exposed
>
>Too bad, that now  the draft is going for a RFC, its a bit late... But,
>nonetheless it remains that the inclusion within a name space of a "/"
>delimiter is changing the name space characteristics and contradict the
>point (1). And, as a name space server designer, I have problems with that.
>It simply change the meaning and rules of existing name spaces where for
>example a hierarchical name space could be defined with delimiters like ".
>/ \ : , ; etc. This is imposing a delimiter within a name space and
>therefore changing the name space conventions. My point is:
>
>Imposing the "/" to name spaces to express relativity or hierarchy is
>reducing them to a single name space convention, a kind of super name space
>convention. At least this should be said. If I have the "\" or "-" as a
>delimiter to indicate a hierarchy, this is changed for "/" and therefore my
>name space convention is changed. Thus, this proposal impose name space
>syntax modifications when used within the context of URNs.  If the "/" is
>just used to say that it is a relative something, It may bring confusion
>with relative URLs. More than that, a concrete implementation may attach a
>relative URI to a base URL when in fact this relative URI to be associated
>to a URN base. Don't we have a certain ambiguity here by saying URI?

I believe Leslie means that "/" is the only RESERVED character across all URNs
for exposing hierachy.  However, any namespace may reserve additional characters
(see Section 2.3.1 of RFC 2141].  The point is that such a move is NAMESPACE SPECIFIC
and therefore agrees with point 1 completely.

Ryan

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re: Relative URNs, URLs, URIs???? 
Date: Thu, 8 May 1997 14:31:50 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

        Leslie Daigle wrote:

    >1. individual namespaces can define whatever relational rules are
           appropriate to their needs   (and those needs will be many and
           varied)"

OK for that. I totally agree. 

  >     2. the current syntax does include the "/" as a potential hierarchy
           delimiter for those namespaces that choose to permit a
           hierarchy to be thus exposed

Too bad, that now  the draft is going for a RFC, its a bit late... But,
nonetheless it remains that the inclusion within a name space of a "/"
delimiter is changing the name space characteristics and contradict the
point (1). And, as a name space server designer, I have problems with that.
It simply change the meaning and rules of existing name spaces where for
example a hierarchical name space could be defined with delimiters like ".
/ \ : , ; etc. This is imposing a delimiter within a name space and
therefore changing the name space conventions. My point is:

Imposing the "/" to name spaces to express relativity or hierarchy is
reducing them to a single name space convention, a kind of super name space
convention. At least this should be said. If I have the "\" or "-" as a
delimiter to indicate a hierarchy, this is changed for "/" and therefore my
name space convention is changed. Thus, this proposal impose name space
syntax modifications when used within the context of URNs.  If the "/" is
just used to say that it is a relative something, It may bring confusion
with relative URLs. More than that, a concrete implementation may attach a
relative URI to a base URL when in fact this relative URI to be associated
to a URN base. Don't we have a certain ambiguity here by saying URI?

The problem will be for parsers, they will have to know, that "/" has to be
translated in the "%_" scheme in certain circumstances and the "/" doesn't
have to be translated in other times. Don't forget that we start from a
Display name. How can this ambiguity resolved? By knowing all name space
rules in order to sort when to change a "/" to a "%_" and when to keep it.
If this is allowed only for relativity how to sort the name space
ownership, is it a relative URL? or a relative URN? and to which name space
is it associated?

        > 3. there is a strong feeling that URNs value as persistent and
           authoritative identifiers is undercut by explicitly shedding
           absolute components (hence the proposal that a URN is always
           absolute, and _derived_ relative fragments are relative URIs)

The problem is not resolved. If I allows a relative URI to be derived from
an absolute URN how can I know that this relative URI is attached to this
URN parent? There is no problems if this URI is in fact a relative URL
attached to a URL parent or if there is an implied rule that only a single
name space could be used within a scope (a document, a context, etc.).
However, it is a problem if more than one URN, used as a base are allowed
within a scope. Again, how can we attach a relative URI to a base URN's
parent? And to say a URI isn't that a bit too general? a URL is a URI, am I
wrong?

As long as we have absolute URNs, no problems, URNs are self sufficient.
The problem is for relative URIs (or relative something if the word
relative URN is prohibited). The actual specified mechanism are for URLs
and all relative URLs are relative to a homogeneous name space, the URL
name space. We may say that this name space has problems, that it is
unstable, that it is too location dependant, etc.. all this is true. It
remains that it is a homogeneous name space with certain rules already
specified. And that URLs are URI, Again_ am I wrong?

If we introduce URNs, by definition, we allow heterogeneous naming
conventions schemes, which is even better than the URL notation which is
taking the "reduction" approach. However this diversity brings some
problems, especially if relative URIs are allowed. URIs are as you know
URNs and URLs superset. When you scan the specs, you find specs for
relative URLs....

So, the problem statement is:

If we allow more than one URN within a certain scope, a relative URI cannot
adequately be associated to its parent name space. This problem doesn't
occurs for relative URLs because they are implicitly attached to the
single, homogeneous URL name space. 

Then, as we all know, a URI is supposed to be the URN, UNC, URL superset. I
mean a URI is something more general than a URN or a URL because it is the
set which contains the latters. URLs have a spec for relative URLs. All
ambiguities are resolved by this spec. This last name space is homogeneous
and therefore the ownership of a relative URL to its base name space is
resolved. Now_ again_ there is a problem to associate - if we allow this -
a relative URN to a specific name space. This problem occurs because, more
than one name space can be present within a certain scope.

If everybody tells me that, no way Jose, this is not a problem or_ we don't
want to address this issue, fine. If I am wrong and see an issue where
there is none, please, that someone give an honest answer to the problem
stated. If it is too soon to talk about relativity for URNs, its fine too,
I'll wait.

If we call that a relative URI, then what is it concretely? a relative URN?
a relative URL? or something new that we will have to define later?

Thus issues still not resolved about relativity for URNs are:
a- Can we define a common scheme to express relativity for URNs. It seems
that the group says no. I am wrong?
b- The issue that a relative URI can be associated to a base URN is not
resolved. The problem nay reside in the fact that we say relative URIs
which by definition encompass URNs and URLs.
c- We all agree (me included) about the actual absolute URN scheme. I have
reserves about the relative URNs. We are still too general and not yet
there.
d- Can we say that URNs are more linked to the concept of location
independence than to the concept of permanency which is more under the
control of name spaces owners? Or, is the concept of permanency mandatory?
If yes, it has to be defined. To the concept of permanency, is underlying
the concept of life time. How do we precisely define that? Location
independence can be defined if we say that location has to be expressed
with a URL and that for a certain URN, one or more URLs are associated.
permanency is more intangible if we don't express the life cycle mechanism
and therefore it is let to any interpretation or misunderstanding.

Didier PH Martin
[email-masked]

Date: Thu, 8 May 1997 10:29:56 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: didier ph martin <[email-masked]>
cc: URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: Relative Name spaces
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Wed, 7 May 1997, didier ph martin wrote:
> If we have strong restrictions that only absolute URNs could be used we
> simply skipped  concrete needs that name spaces implementors will have.

Stop right there.

Let me recap one last time what is on the table in this working group:

	1. individual namespaces can define whatever relational rules are
	   appropriate to their needs   (and those needs will be many and
	   varied)

	2. the current syntax does include the "/" as a potential hierarchy
	   delimeter for those namespaces that choose to permit a
	   hierarchy to be thus exposed

	3. there is a strong feeling that URNs value as persistent and
	   authoritative identifiers is undercut by explicitly shedding
	   absolute components (hence the proposal that a URN is always
	   absolute, and _derived_ relative fragments are relative URIs)
	   
This is not saying that defined relationships between long-lived and
location-independent identifiers will not be useful for many _applications_..

What this _is_ saying is that there are many possible ways of expressing
the necessary relationships between resources, and the currently-proposed
structure allows at least many of them.  But the discussion of how to
_use_ those references is _not_ part of our work of defining Uniform 
Resource Names.

My _name_ is Leslie Daigle.  Different pockets of societal conventions
have adopted rules for whether I can be simply referred to as Leslie,
Madame Daigle, ma'am, Mrs. Snow, etc.  _Those_ conventions do not affect my 
name, and are particular to different environments.

Your point is that, without a concrete system to follow, implementors
(of namespaces, of URN-carrying software) will define and use a variety
of non-interoperable mechanisms.  Fair enough -- and when the work
of this working group is complete, if there is sufficient support for
the idea, and belief that there is a _single_ mechanism that can be
proposed, you are free to propose a working group to address that question.

The URN WG has enough on its plate, and has defined its boundaries.

Leslie.

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

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

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re: Relative Name spaces
Date: Wed, 7 May 1997 15:59:08 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

Fisher Mark wrote

"If we are talking long-term, I don't recall anyone proposing a new
structure for Shakespeare's plays, or the Bible, or the Koran, or the
Odyssey, or ...   Some document organizations can last a long time --
others are as ephemeral as the mayfly.  "Permitting" relative URIs for
URNs is not the same as "requiring" relative URIs for URNs in each URN
namespace (or even most)."

Yes , yes and yes.

I think that we cannot take as a premise that a name space has to be
perpetual. Maybe in dreams...
Yes some name spaces will support the attacks of time, other will simply
dye or evolve. But to take the premise that name space is perpetual is
impossible or even to think that a name space is without evolution is
doomed to failure.

If we have strong restrictions that only absolute URNs could be used we
simply skipped  concrete needs that name spaces implementors will have.
Therefore, without any rules, these implementors will create their own. We
will end up with the situation that they will define their own relative
name space rules. This will bring other problems for these implementors
when more than one name space is used in the same document or context. How
can we attach a relative URN to a name space in order to be resolved
properly and not mixed with an other name space member?

Yes, we cannot interfere with name space structures because they are all
different and designed with a certain purpose in mind that their structure
fulfill. But, if we can state or specify some basic rules to ease the
coexistence of name spaces (when relative URN are used), this will resolve
some problems.

So, to my knowledge, a name or a pattern located within a name space could
be structured with either the navigation rule like URLs or concatenation
rule. There is, with a strong probability, more than these rules. So to
base relative URNs on a specific rule could potentially be too restrictive.
Then, we still have the problem, for a relative URN, how can we be sure
that a relative URN is properly associated to the right name space and not
be confounded or resolved with the wrong base name space.

To permit relative URNs won't necessarily destroy the URN scheme. We have
only to resolve ambiguities like relative URNS name space ownership and not
necessarily relative name space resolution rules like for instance (as
example) the concatenation rule or the URL navigation rule.

So, I understand that some of us are afraid that to introduce relative URNs
may destroy the URN purpose. Some see the intend as permanency, some even
perpetual permanency (impossible). We have to remember that objects
structured within name spaces are simply independent of their location.
They can be moved and still keep their name. This is the main advantage of
URNs : for objects to keep their names even if they are moved from one
place to an other. A name space provider can only and realistically offer a
certain stability, and we should underline only a certain stability for a
certain period of time. But,  the main advantage that this provider will
offer to the population, is that even if we move an object from on place to
an other, the object can still be referred the same way. URLs don't  offer
today the same advantage.

In conclusion, a URN offers location independence not perpetual existence.

From: Keith Moore <[email-masked]>
To: Fisher Mark <[email-masked]>
cc: "'Keith Moore'" <[email-masked]>, "'Leslie Daigle'" <[email-masked]>, "'David W. Morris'" <[email-masked]>, "'Larry Masinter'" <[email-masked]>, "'URN Workgroup'" <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs 
Date: Wed, 07 May 1997 14:09:44 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> If relative URIs for URNs are allowed but not required in all cases,
> then we have left the door open for any applications that can use 
>  "relative URNs".

This is missing the point.  Relative URNs are harmful to URNs.

Keith

From: Fisher Mark <[email-masked]>
To: "'Keith Moore'" <[email-masked]>, "'Leslie Daigle'" <[email-masked]>
Cc: "'David W. Morris'" <[email-masked]>, "'Larry Masinter'" <[email-masked]>, "'URN Workgroup'" <[email-masked]>
Subject: RE: [URN] Re: About realtive URNs 
Date: Wed, 7 May 1997 11:59:46 -0500
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

>Leslie, you wrote (">>" Keith wrote) : 
>> So maybe what we need is a "URN + internal-reference" syntax, which is
>> treated much like a URL in that it can be referenced, but which can
>> easily be distinguished from an ordinary URN so that it won't be taken
>> as a long-term stable reference.
>
>I believe this takes us way out of URN WG space -- and this is why
>I suggested, last week, that we can have _URNs_, and relative _URIs_
>which some clever group of people can build that are _derived from_
>or _applied to_ URNs.

We can (and I trust will) design a URN architecture that will last for
many years.  That does not mean that we can anticipate every single use
of that architecture (how many of predicted trademark fights over DNS
names back in 1993?).  If relative URIs for URNs are allowed but not
required in all cases, then we have left the door open for any
applications that can use "relative URNs".

If we are talking long-term, I don't recall anyone proposing a new
structure for Shakespeare's plays, or the Bible, or the Koran, or the
Odyssey, or ...   Some document organizations can last a long time --
others are as ephemeral as the mayfly.  "Permitting" relative URIs for
URNs is not the same as "requiring" relative URIs for URNs in each URN
namespace (or even most).
==========================================================
Mark Leighton Fisher          Thomson Consumer Electronics
[email-masked]          Indianapolis, IN
"ViaCrypt?  Vhy not!"

Date: Tue, 6 May 1997 22:04:52 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Keith Moore <[email-masked]>
cc: "David W. Morris" <[email-masked]>, Larry Masinter <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs 
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

[Keith Moore wrote:]
> However, it does seem like we're going to need some kind of internal
> reference: some way to assign a URN to a (dynamically changing) "book"
> and allowing an external reference to a "page number" or "chapter" or
> "section" of that "book".  The resource name of the "book" might meet
> all of the URN requirements for long-term stability.  On the other
> hand, the organization of that "book" may change over time,
> invalidating the old references to particular portions of the book.

Indubitably, there are reasons for which people will want to make and
assign such references -- likely also for geospatial data,  temporally
organized data, and data of other structural formats altogether.

> So maybe what we need is a "URN + internal-reference" syntax, which is
> treated much like a URL in that it can be referenced, but which can
> easily be distinguished from an ordinary URN so that it won't be taken
> as a long-term stable reference.

I believe this takes us way out of URN WG space -- and this is why
I suggested, last week, that we can have _URNs_, and relative _URIs_
which some clever group of people can build that are _derived from_
or _applied to_ URNs.

> On the other hand, we could accomplish the much the same thing by
> having each edition of the "book" define full URNs for its internal
> chapters and sections.  Then those references would also be stable.  A
> reader does of course need to be discover the relationships between

Again, this is an implementation that could be sought to solve a particular
problem.  I'd like to think that some book-reference-namespace can be
build to accommodate just this sort of thing (capturing the relationships
between independent URNs).  I don't believe it is part of the URN
basic architecture.

Leslie.

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

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

From: Keith Moore <[email-masked]>
To: "David W. Morris" <[email-masked]>
cc: Keith Moore <[email-masked]>, Larry Masinter <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs 
Date: Tue, 06 May 1997 15:54:15 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> > Back to your example.  I don't see how it's useful to have relative
> > URNs for things like "the portion of the map that corresponds to Ohio"
> > unless you can take *multiple* base URNs A, B, C and in each case,
> > get the URN that means "the portion of this resource that corresponds
> > to Ohio" by appending "/Ohio" or "#Ohio" or whatever to A, B, C etc..
> > (Otherwise, you could just use absolute URNs.  You don't need relative
> > URNs to build a table of contents.)
> 
> Relative URNs, URIs, relative machine code, etc. all have value based on
> the experience that there are a significant number of cases are A, B, ...
> are valid with a common relative part. 

Experience also indicates that relative name constructions have poor
long-term stability.

URNs exist to allow long-term stable references to resources.
They are emphatically not intended as a resource discovery mechanism.

Relative names are indeed useful, but they are not URNs.

> For example, when Michigan is reorganized finally to
> attach the UP to Wisconson, the map folks will be glad they used
> relative URNs for the counties as they will find it much easier to
> relocate the content into new URNs.  

In other words, you would require URNs to be able to work *in advance
of* the actual binding of some <base URN, suffix> combinations to an
actual resource.  

In the long term, this doesn't work.  People will want to mix and
match base URNs and suffix schemes in unanticipated ways.  (e.g. given
your example of Michigan and Wisconsin: assume each state uses two
letter abbreviations for its counties, and some of the names conflict.
What happens when the states redefine their boundaries?  Far better to
assign a unique URN for each county in the US -- then there is never a
need to change the names.)

If a name space encodes relationships between objects, the
relationships between those objects will change over time in ways that
adversely impact the stability of the name space.  

The Tennessee Department of Transportation used to use numbers to
identify counties, the numbers assigned according to population:
1=Shelby (Memphis), 2=Davidson (Nashville), etc.  This was handy for
license plates of the form county#-suffix (e.g. 2-71828 for a Davidson
county plate), because it allowed the suffixes to be longer for the
more populated counties.  Eventually a new census was taken, the
relative populations changed, and the next series of license plates
reflected that change.  This wasn't a problem for license plate
numbers, which had to be unique strings anyway, but it was a problem
for the other state agencies who had borrowed the numbering plan from
the DoT.

> Being able to express a base URN and a collection of relative URNs
> will be expected and useful.  The method of expression should not
> preclude reasonable differentiation between a relative URN in
> content and a relative URI and what I would guess would be the
> common case desired, a relative URN which == the relative URI.

Relative resource names are useful, but the intersection of relative
names and long-term stable names is close to the null set.  People may
expect to use URNs in this way, but this kind of usage is damaging to
the intended purpose of URNs.

				 ***

However, it does seem like we're going to need some kind of internal
reference: some way to assign a URN to a (dynamically changing) "book"
and allowing an external reference to a "page number" or "chapter" or
"section" of that "book".  The resource name of the "book" might meet
all of the URN requirements for long-term stability.  On the other
hand, the organization of that "book" may change over time,
invalidating the old references to particular portions of the book.

We want to be able to assign a stable reference to the "book" even if
we can't assign stable references to portions of that book.  And we
want to be able to refer others to a particular chapter of that book.
The reference to the chapter is not a stable reference, and therefore,
strictly speaking, not a URN.  But it needs to be derived from a URN.

So maybe what we need is a "URN + internal-reference" syntax, which is
treated much like a URL in that it can be referenced, but which can
easily be distinguished from an ordinary URN so that it won't be taken
as a long-term stable reference.

On the other hand, we could accomplish the much the same thing by
having each edition of the "book" define full URNs for its internal
chapters and sections.  Then those references would also be stable.  A
reader does of course need to be discover the relationships between
URNs for the book and its sections (e.g. he needs to be able to find
the URNs for sections of a book, or to be able to find the URN of the
current book or chapter or section he is reading, or given the URN of
a chapter to be able to find the URN of the entire book...though of
course the chapter may appear in multiple books) 

But as long as the relationships between URNs are available to users,
it seems far better to use real URNs.

So I keep coming back to the same conclusion: the relationships
between resources named by URNs should not be encoded in the URNs
themselves.

(But if even the URN working group has trouble understanding that, how
can we ensure that the masses make proper use of URNs?)

Keith

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-syntax-05.txt
Date: Tue, 06 May 1997 09:43:49 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

 A Revised 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     : URN Syntax                                              
       Author(s) : R. Moats
       Filename  : draft-ietf-urn-syntax-05.txt
       Pages     : 7
       Date      : 05/05/1997

Uniform Resource Names (URNs) are intended to serve as persistent, 
location-independent, resource identifiers. This document sets forward the 
canonical syntax for URNs.  A discussion of both existing legacy and new 
namespaces and requirements for URN presentation and transmission are 
presented.  Finally, there is a discussion of URN equivalence and how to 
determine it.                                                              

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-syntax-05.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-05.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  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-syntax-05.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-syntax-05.txt

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

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

--OtherAccess--

--NextPart--

From: "Ryan Moats" <[email-masked]>
To: "Ron Daniel, Jr." <[email-masked]>, "URN mailing list" <[email-masked]>
Date: Mon, 05 May 97 15:38:51 
Priority: Normal
Subject: Re: [URN] Zeroth draft of IETF namespace doc (-00)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Mon, 05 May 1997 09:35:31 -0600, Ron Daniel, Jr. wrote:

>You might add a sentence to the abstract stating that this
>document will serve as an example of the sort of information that needs
>to be supplied when proposing new namespaces.

I like this!! Have rewritten the draft...

>Currently the ABNF says  family = "rfc" | "std" | "fyi"
>It is quite likely that the ietf will, over time, add new document
>series. How will this namespace cope with that (or do you suggest that
>any new document series be put into an "ietf2" namespace?  (I would
>say that the IESG, or its successor, is the sole body with authority to
>add new document series to the IETF namespace. Any software that is
>intended to resolve names from the IETF namespace should be written
>with the awareness that a new document series may be introduced at
>any time).

I like this as well and have added it.

>>   As specified by the ABNF in section 1.2, this namespace defines the
>>   additional lexical equivalence that the entire NSS is case-
>>   insensitive.
>
>You might rephrase this to something like:
>Note that the entire URN is case-insensitive, due to the definition of
>ABNF.

Ok, I can live with this...

>Section 1.5 has an occurance of "the the".

and this...

>Assuming we have functionally equivalent URNs - then what? Is the resolver
>free to return STD 51 if I ask for RFC 1661? If 1661 and 1662 are not
>functionally equivalent, but I answer queries for either with STD 51,
>haven't I just made them equivalent? I think you need to state what
>resolvers are allowed to do with requests for documents that have been
>updated, supplanted, or standardized by other documents. Then we can argue
>about those rules. :-)

Now the fun begins...

My language in the draft is admittedly vague and/or misleading, so let's discuss where I'm trying
to reach, and see if we can craft language to get there (or move there to "someplace
else" and then craft language for that "somplace else").

Various documents in the RFC/STD/FYI series have multiple identifiers (for example
STD1 is also RFCxxxx).  The gotcha is that at least STD 51 maps to 2 RFCs (1661 and
1662).  Therefore, when you retrieve STD 51 you get both RFC 1661 and 1662.
However, RFC 1661 or 1662 alone are only subsets of STD 51.  Thus if you answer
a request for RFC 1661 with STD 51 you haven't declared RFC 1661 and 1662 equivalent,
you've just returned a superset of the RFC 1661 specification.

Hmmm, the above looks like I'm arguing that functional equivalence here is not reflective
(RFC 1661 = STD 51 but STD 51 != RFC 1661) and possibly not transitive (no example
as yet).

As to the second question Ron asks...  my opinion is that if a resolver is asked for 
a document in the STD and FYI family, it may return EITHER the std/fyi document
or ALL of the RFCs that map to the requested document based on the RFC Editor's
citation index (std-index.txt for STD and fyi-index.txt for FYI).  As additional family series
are introduced, the rules for the new series must be added.

What I haven't answered (as yet) is "Can a request for a RFC result in an STD or FYI
being returned?" .  This is the first step to "Can a request for a RFC result in the STD or FYI
(or RFC for that matter) that has superceded that document. I'll answer these two questions
in two parts, and I'm sure we'll discuss my proposal ;-).

1) I don't have a problem with a RFC request resulting in a FYI or STD being returned
that is a superset of the request RFC.  Therefore, I have no problem with a request
for RFC 1661 resulting in STD 51 being returned ( I do have a problem with a STD 51 request
resulting in RFC 1661 ALONE being returned).

2) I don't think that a request for an obsoleted RFC should result in anything other than the
obsoleted RFC being returned.  The server doesn't know whether the user is actually looking for
 the STD or FYI and not the obsoleted RFC for historical (histerical?) reasons.

Finally, a point of opinion.  I view N2N requests as a method of revealing functional equivalence.
The way N2N works in the current implementation of this namespace may help reveal how
I view functional equivalence in this namespace.

Look forward to the comments...

Ryan Moats

Date: Mon, 05 May 1997 09:35:31 -0600
To: "Ryan Moats" <[email-masked]>, "URN mailing list" <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] Zeroth draft of IETF namespace doc (-00)
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

You might add a sentence to the abstract stating that this
document will serve as an example of the sort of information that needs
to be supplied when proposing new namespaces.

Currently the ABNF says  family = "rfc" | "std" | "fyi"
It is quite likely that the ietf will, over time, add new document
series. How will this namespace cope with that (or do you suggest that
any new document series be put into an "ietf2" namespace?  (I would
say that the IESG, or its successor, is the sole body with authority to
add new document series to the IETF namespace. Any software that is
intended to resolve names from the IETF namespace should be written
with the awareness that a new document series may be introduced at
any time).

>   As specified by the ABNF in section 1.2, this namespace defines the
>   additional lexical equivalence that the entire NSS is case-
>   insensitive.

You might rephrase this to something like:
Note that the entire URN is case-insensitive, due to the definition of
ABNF.

Section 1.5 has an occurance of "the the".

Assuming we have functionally equivalent URNs - then what? Is the resolver
free to return STD 51 if I ask for RFC 1661? If 1661 and 1662 are not
functionally equivalent, but I answer queries for either with STD 51,
haven't I just made them equivalent? I think you need to state what
resolvers are allowed to do with requests for documents that have been
updated, supplanted, or standardized by other documents. Then we can argue
about those rules. :-)

Regards,

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: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Date: Sun, 04 May 97 09:58:51 
Priority: Normal
Subject: [URN] Zeroth draft of IETF namespace doc (-00)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

--_=_=_=IMA.BOUNDARY.E9NTI3138764=_=_=_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Well, the schedule says the first draft of these needs to be out in May, and since I'm going to
be busy tomorrow morning, I thought I'd post this today.  (Besides, it provides a small change
of subject from the relative URN discussion)...

Attached is the zeroth draft of the i-d (-00) that will document the new namespace introduced
in Memphis.

Ryan Moats

--_=_=_=IMA.BOUNDARY.E9NTI3138764=_=_=_
Content-Type: application/octet-stream; name="urn.ietf.txt"
Content-Transfer-Encoding: base64

ICAgIFtQYWdlIDNdCgoK

--_=_=_=IMA.BOUNDARY.E9NTI3138764=_=_=_--

Date: Fri, 2 May 1997 19:45:48 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Didier PH Martin <[email-masked]>
CC: didier ph martin <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About URNs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Please review section 5.1. Establishing a Base URL of
draft-fielding-url-syntax-05.txt to see if the explanation
for how a "base URL" might be determined is adequate even
if the "base" is a URN.

I just sent it to internet-drafts yesterday, so it might
take a few days to show up. If there are no further corrections,
it's going to IESG as Draft Standard.

Larry

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re: Relative URNs
Date: Fri, 2 May 1997 22:08:45 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

        Keith Moore wrote:

"Back to your example.  I don't see how it's useful to have relative
URNs for things like "the portion of the map that corresponds to Ohio"
unless you can take *multiple* base URNs A, B, C and in each case,
get the URN that means "the portion of this resource that corresponds
to Ohio" by appending "/Ohio" or "#Ohio" or whatever to A, B, C etc..
(Otherwise, you could just use absolute URNs.  You don't need relative
URNs to build a table of contents.)"

I am sorry, relative URNs are useful to write a table of content. Lets say
that you want to exchange between to name servers part of their name
spaces, you will need an exchange format. Here, no problem, you can choose
an efficient machine format. Now let's say that you want an exchange from a
person writing a table of content for a document and send that to a
machine. The table of content has to be integrated into a name space server
and the content included in the storage system.. In that case you need
relative URNs or a way to reduce what users have to write in the <name
space, location> definition (a simple name server record with just one
attribute). 
For this example. I won't take SOIF which is too difficult to write by
hand, I will take MCF which is easier. We have objects defined in a name
space, this is a hierarchical name space for a set of HTML documents that
won't change (for a certain life time - i.e until the user throw that in
the recycle bin). I want to use MCF to express a mini name space to express
the table of content. I will then have

destination:"urn:path:Desktop/References/Technical manuals/LDAP protocol"
<---- the last name in the path is the insertion point in the target name
space. The other part of the name space is the hierarchy already in place.
The scope of this base is the entire document or is valid until there is an
other destination declaration. This is an absolute URN.

Then the objects definition:

unit:"chapter1/How to do a request"
location:"chapt1.html" <--- this URL is relative to a base that the user
defined with a dialog. The base for the exercise is: "file://my docs/LDAP"

unit:chapter2/The X500 scheme"
location:"chapt2.html"

etc...

So it depends of the context where you use them, URNs are not necessarily
useful only in the browsers' address text box , or within HTML documents,
they could be used in other contexts. Like URLs that can be used to
identify file in a file system and this, in a different context than in a
browser.

"This assumes that the organization of each of these resources stays
the same for the lifetime of the URNs.  What if the resources are 
regional maps, and at some point it is deemed useful to re-organize them
so that Ohio is in a different region?  What if some of the resources
are regional maps and others are tables for the entire USA, and the 
maps get re-organized and the tables don't?  What if Ohio splits into
two states? (after all, it happened to Virginia)."

Nothing is really permanent Keith, it only gets a longer life time. It is
also possible that a particular collection maintain its name space, even
can be inserted into an other one and keep that same relationship, not
based on location but name relationship. Off course some name space cannot
absorb new elements and keep their name relationship. Yes, within a certain
collection, elements will disappear or move. So a completely static name
space is hard to achieve. Even phone numbers are changing, not their name
but what they mean, which in this case is their owner. Same thing for USSR,
it meant something at a certain time, the name still remain, the meaning
attached to it is different. this is the usual syntax/semantic thing.

Date: Fri, 02 May 1997 22:19:26 -0400
From: Didier PH Martin <[email-masked]>
Organization: Talva
To: Larry Masinter <[email-masked]>
CC: didier ph martin <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About URNs
Sender: [email-masked]
Reply-To: Didier PH Martin <[email-masked]>

Larry Masinter wrote:

> Actually, I don't think it is useful to define a "base scope" as a
> standard.
>
> It's a property of individual media types and protocols to define
> how
> URIs are represented or transmitted in them, and part of their
> definition -- if they allow a 'relative URI' within them -- is
> to define, for each relative URI, how the base is computed.

 So Larry, you mean that the determination of a base scope is the
responsability of the media or document handler. This latter has to
resolve relative URNs ambiguity not from the URNs standard but by other
means.

Date: Fri, 2 May 1997 18:51:22 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: didier ph martin <[email-masked]>
CC: URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About URNs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Actually, I don't think it is useful to define a "base scope" as a
standard. 

It's a property of individual media types and protocols to define how
URIs are represented or transmitted in them, and part of their
definition -- if they allow a 'relative URI' within them -- is
to define, for each relative URI, how the base is computed.

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re: About URNs
Date: Fri, 2 May 1997 21:30:56 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

Larry Masinter wrote:

" the thing to keep in mind
is that it is useful to separate "the definition of the base" from
"the meaning of the relative pointer". The problem with "relative URN"
is that they don't work very well when actually embedded in content,
since you might think it would be ambiguous whether the "base"
was the URN used to identify the item or the URL used to locate
the particular instance.

Perhaps relative URNs are not useful when embedded in an instance
of the identified resource, but they still have a meaning outside.

Relative pointers are useful in other contexts, e.g., within
a listing:
   "For this base <URI> consider the following resources:
       <relative URI>
       <relative URI>
       <relative URI>"

If I understand you well, the trick is to have a mechanism to specify the
scope of the base. 
So, the problem is twofold: 
a) We should have a way to define an unambiguous base scope
b) Also to get a way to define an unambiguous way to relate a relative URI
to its base URI.

Didier PH Martin
[email-masked]

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re:  About relative URNs
Date: Fri, 2 May 1997 21:08:48 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

       Mark Fisher  wrote:

" I guess I agree and disagree with you simultaneously.  For some URN
namespaces, there can be no notion of hierarchy (and therefore
relativity), because either the hierarchy does not exist (flat or matrix
namespaces) or it is not exposed (I suspect this will be the case for
ISBNs).  But for other URNs, it will make perfect sense to permit or
even encourage relativity (I can imagine an IETF document namespace that
lets you go from <URN:ietf://rfc/1945.txt> to <URN:ietf://rfc/2068.txt>
through a base URN of <URN:ietf://rfc/> and a relative URI for that URN
of "2068.txt").

So, yes -- there is no general notion of relativity for URNs -- but no
-- there can be useful URN namespaces that permit relative URNs."

I totally agree with that Mark

Didier PH Martin
[email-masked]

Date: Fri, 2 May 1997 12:08:21 -0700 (PDT)
From: "David W. Morris" <[email-masked]>
To: Keith Moore <[email-masked]>
cc: Larry Masinter <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs 
Sender: [email-masked]
Reply-To: "David W. Morris" <[email-masked]>

On Fri, 2 May 1997, Keith Moore wrote:

> Back to your example.  I don't see how it's useful to have relative
> URNs for things like "the portion of the map that corresponds to Ohio"
> unless you can take *multiple* base URNs A, B, C and in each case,
> get the URN that means "the portion of this resource that corresponds
> to Ohio" by appending "/Ohio" or "#Ohio" or whatever to A, B, C etc..
> (Otherwise, you could just use absolute URNs.  You don't need relative
> URNs to build a table of contents.)

Relative URNs, URIs, relative machine code, etc. all have value based on
the experience that there are a significant number of cases are A, B, ...
are valid with a common relative part. It isn't necessary that relative
URNs work for every URN, only that relative URNs will be useful for some
percentage of cases.  For example, when Michigan is reorganized finally to
attach the UP to Wisconson, the map folks will be glad they used
relative URNs for the counties as they will find it much easier to
relocate the content into new URNs.  Being able to express a base
URN and a collection of relative URNs will be expected and useful.
The method of expression should not preclude reasonable differentiation
between a relative URN in content and a relative URI and what I would
guess would be the common case desired, a relative URN which == the
relative URI.

Dave Morris

From: Keith Moore <[email-masked]>
To: Larry Masinter <[email-masked]>
cc: Keith Moore <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs 
Date: Fri, 02 May 1997 14:31:49 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Even for resources with dynamic content ("today's weather map" being the
> canonical example"), in reality, stable identifiers are not useful as a
> way of identifying items whose structure is totally dynamic, and
> relative names are only useful as a way of naming subparts of the
> structure that are presumed to be static.
> 
> For "today's weather map", you might want to be able to name
> "the part that shows Ohio".

Bad example :)

For the map of Europe, you might want to be able to
name "the part that shows the Soviet Union".  (oops)

IMHO, it's naive to presume that even political boundaries are static.  
(though the leaders of nations persist in that belief, we shouldn't
encourage them!)

Back to your example.  I don't see how it's useful to have relative
URNs for things like "the portion of the map that corresponds to Ohio"
unless you can take *multiple* base URNs A, B, C and in each case,
get the URN that means "the portion of this resource that corresponds
to Ohio" by appending "/Ohio" or "#Ohio" or whatever to A, B, C etc..
(Otherwise, you could just use absolute URNs.  You don't need relative
URNs to build a table of contents.)

This assumes that the organization of each of these resources stays
the same for the lifetime of the URNs.  What if the resources are 
regional maps, and at some point it is deemed useful to re-organize them
so that Ohio is in a different region?  What if some of the resources
are regional maps and others are tables for the entire USA, and the 
maps get re-organized and the tables don't?  What if Ohio splits into
two states? (after all, it happened to Virginia).

Keith

Date: Fri, 2 May 1997 10:52:58 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: didier ph martin <[email-masked]>
CC: URN Workgroup <[email-masked]>
Subject: Re: [URN] Re; relative URNs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I won't quote all of your message, but the thing to keep in mind
is that it is useful to separate "the definition of the base" from
"the meaning of the relative pointer". The problem with "relative URN"
is that they don't work very well when actually embedded in content,
since you might think it would be ambiguous whether the "base"
was the URN used to identify the item or the URL used to locate
the particular instance.

Perhaps relative URNs are not useful when embedded in an instance
of the identified resource, but they still have a meaning outside.

Relative pointers are useful in other contexts, e.g., within
a listing:
   "For this base <URI> consider the following resources:
       <relative URI>
       <relative URI>
       <relative URI>"

Date: Fri, 2 May 1997 10:01:37 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Keith Moore <[email-masked]>
CC: URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Although publishers can get away with using the same ISBN number for a
reprinting -- even if it corrects a few typos, I suppose -- and some
might even foolishly use the same ISBN for the paperback and hardback,
it would be foolish to reuse an ISBN number for a new edition in which
an entire chapter is omitted.

Even for resources with dynamic content ("today's weather map" being the
canonical example"), in reality, stable identifiers are not useful as a
way of identifying items whose structure is totally dynamic, and
relative names are only useful as a way of naming subparts of the
structure that are presumed to be static.

For "today's weather map", you might want to be able to name
"the part that shows Ohio".

From: Keith Moore <[email-masked]>
To: "Martin J. Duerst" <[email-masked]>
cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: [URN] Protocol Action: URN Syntax to Proposed Standard 
Date: Fri, 02 May 1997 12:43:58 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> While I agree that there was indeed a good working group consensus,
> the above explanation, in particular the phrase "Internationalization
> was also left undefined" is not very fortunate. 

This was a poor choice of words on my part, for which I apologize.
However, I don't think it will have much consequence, as it only
appears in the IESG's records (and in the IETF mailing list archives),
not in the RFC itself.

I'd prefer not to re-ballot the URN syntax document just to change
this text.

Keith

From: Keith Moore <[email-masked]>
To: Fisher Mark <[email-masked]>
cc: "'didier ph martin'" <[email-masked]>, "'Keith Moore'" <[email-masked]>, "'URN Workgroup'" <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs 
Date: Fri, 02 May 1997 11:21:53 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >I am still firmly convinced that relative URNs are a non-starter.
> >That is, encoding inter-document relationships into the structure
> >of a URN, unless those URNs name static entities which never change,
> >impairs the longevity of URN-space.
> 
> I guess I agree and disagree with you simultaneously.  For some URN
> namespaces, there can be no notion of hierarchy (and therefore
> relativity), because either the hierarchy does not exist (flat or matrix
> namespaces) or it is not exposed (I suspect this will be the case for
> ISBNs).  But for other URNs, it will make perfect sense to permit or
> even encourage relativity (I can imagine an IETF document namespace that
> lets you go from <URN:ietf://rfc/1945.txt> to <URN:ietf://rfc/2068.txt>
> through a base URN of <URN:ietf://rfc/> and a relative URI for that URN
> of "2068.txt").

This works for RFCs because RFCs never change.  (Note the exeption
above: "unless those URNs name static entities which never change").

> So, yes -- there is no general notion of relativity for URNs -- but no
> -- there can be useful URN namespaces that permit relative URNs.

and as I said in the message you were responding to:

> >Existing schemes which are grandfathered into URN-space might have
> >such relationships, but that's a property of a particular name space,
> >not one of URNs in general.

Keith

From: Fisher Mark <[email-masked]>
To: "'didier ph martin'" <[email-masked]>, "'Keith Moore'" <[email-masked]>
Cc: "'URN Workgroup'" <[email-masked]>
Subject: RE: [URN] Re: About realtive URNs 
Date: Fri, 2 May 1997 10:08:06 -0500
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

Keith, you wrote:

>I am still firmly convinced that relative URNs are a non-starter.
>That is, encoding inter-document relationships into the structure
>of a URN, unless those URNs name static entities which never change,
>impairs the longevity of URN-space.
>
>Existing schemes which are grandfathered into URN-space might have
>such relationships, but that's a property of a particular name space,
>not one of URNs in general.

I guess I agree and disagree with you simultaneously.  For some URN
namespaces, there can be no notion of hierarchy (and therefore
relativity), because either the hierarchy does not exist (flat or matrix
namespaces) or it is not exposed (I suspect this will be the case for
ISBNs).  But for other URNs, it will make perfect sense to permit or
even encourage relativity (I can imagine an IETF document namespace that
lets you go from <URN:ietf://rfc/1945.txt> to <URN:ietf://rfc/2068.txt>
through a base URN of <URN:ietf://rfc/> and a relative URI for that URN
of "2068.txt").

So, yes -- there is no general notion of relativity for URNs -- but no
-- there can be useful URN namespaces that permit relative URNs.
==========================================================
Mark Leighton Fisher          Thomson Consumer Electronics
[email-masked]          Indianapolis, IN
"ViaCrypt?  Vhy not!"

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] Re; relative URNs
Date: Fri, 2 May 1997 09:47:18 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

Larry Masinter wrote: 

  Think of

  "Chapter 1 of ISBN nn-nnnnnnnnn-nn".

  Then there's "Chapter 2". And "Chapter 3". The table of contents
  might even list the URNs of the chapters as relative.

  Maybe they're relative URLs, where the "base" is a URN. So the
  hierarchy exists but only below the point where you have
  location-independent naming.

  If you hold to the view that "URNs are just a set of URL schemes
  that seem more permanent and location independent", then
  there aren't "relative URNs" but there are "relative URLs that
  are relative to a URN base".

You get a very good point here about chapters. It is true that we may have
a mix naming convention: one 
dealing at the book level (isbn) an other one at the book's content level.
This is confusing but may happen 
when a naming scheme doesn't have any provision for organizing a sub level
of content. The best thing would 
be to expand isbn to include the content, but this is not something we may
envision for the moment in the 
case of isbn. Yes, your point is well taken and yes we may have to mix
different schemes when one is not 
providing what we want. this means practically to use more than one name
space.

The problem then occurs  if the sub level schema is organized with an other
urn name space. I'll explain. The 
first level of the hierarchy: books/table of content is organized with a
isbn naming scheme, and the table of 
content level with an other naming scheme named, lets say " Toc" With that
scheme we have absolute urn 
expressions like urn:toc:1, urn:toc:1.1, etc.. We have here, problems
inherent when two naming schemes are 
mixed. In the same document I may refer to books with the isbn scheme and
their content with the Toc scheme. 
the Toc scheme being re-used with different books naming conventions aka
classification conventions like, for instance, the dewey system .

If we choose the relative URL system, the problem will be to differentiate,
not only from which base we start 
but from which name space also. I think that a relative scheme has to keep
information about which name 
space it is part of. A general relative URL scheme won't work. Keep in mind
that URL scheme is 
homogeneous (always expressing hierarchies with /) namespaces are
different, there may be flat name 
spaces or hierarchical ones. You can say that the former is just a sub
category of the latter and you would 
be right, an array is just a tree with one level (only). So far so good.
The question is: is relativity something 
absolute or something related to a name space? If it is absolute what do we
do if in the same document we 
have to different urns name spaces? relative URLs have a premise that the
universe is homogeneous i.e. 
URL, so they have no problem, everything is attached to a single "name
space" the URL name space. We 
don't have this homogeneous world with urns.

Also, URLs are by definition hierarchical. Namespaces are either
hierarchical or flat (one level) could be 
potentially an other structure but statistically we cover the big majority
of naming schemes created 
by indexed files and relational db indexes (some, even if implemented with
flat indexes may reveal a 
hierarchical structure). We shouldn't forget that most of actual name
spaces:social security card number, credit card number, isbn are most of
the time implemented with db indexes or indexed files.

Relative URLs are based on the navigation rule, more specifically on a
navigation rule within a hierarchy. 
This rules has operators like "." = stay at this level, or ".." = move up
one level. It don't have any array 
operators like move right or move left within a level, aka, an array ,aka,
a flat name space.

This said, can I express that I move right or left in a flat name space?
surely not with relative URL scheme.

If I use relative URL scheme to express move up or stay at this level, how
can I specify that this is for a 
certain name space when more than one is present in the same document?
Think of parsers here, how can 
they resolve the ambiguity? Again, relative URLs don't have this problem,
they deal with a homogeneous 
universe (i.e. a single name space). Do we keep a reference to the
namespace in relative notations? (i.e. like 
isbn:.. or isbn:. read here isbn move up one level, isbn stay at this
level. Do that expression make sense for 
isbn? I have doubts. maybe move right or move left would be more
appropriate? this is a question not an 
implicit affirmation).

PURL system has some great advantages and weakness. Strength: assure some
permanency. Weakness, 
doesn't allow the inclusion of other name space notations; it is still URL,
 permanent URLs. Are URNs 
like PURLs? PURL was assuring permanency (the goal you stated), but is
still in the URL naming scheme...

From: Keith Moore <[email-masked]>
To: Larry Masinter <[email-masked]>
cc: Keith Moore <[email-masked]>, didier ph martin <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs 
Date: Fri, 02 May 1997 09:23:10 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Think of
> 
> "Chapter 1 of ISBN nn-nnnnnnnnn-nn".
> 
> Then there's "Chapter 2". And "Chapter 3". 

Yep.  That's very much like the example I had in mind.

Now consider that the book is revised, and Chapter 3 is no longer
the chapter it used to be.  If the URN for that book remains the
same, all of the old references to chapter 3 become invalid.
So either you assign a completely new URN for that book, or you
lose the longevity that URNs were supposed to provide.

Even if the URNs for the chapters are assigned according to content,
you still lose, because the old chapter on "foobar" is eventually
split into separate chapters on "foo" and "bar".

> Maybe they're relative URLs, where the "base" is a URN. So the
> hierarchy exists but only below the point where you have 
> location-independent naming.

But location-independence isn't the only quality you need
to have long-term stable resource names.

> If you hold to the view that "URNs are just a set of URL schemes
> that seem more permanent and location independent", 

While that's a useful explanation in certain contexts, it's
not a definition of URNs.

> then there aren't "relative URNs" but there are "relative URLs that
> are relative to a URN base".

It doesn't really matter what you call the relative thingys.  
If they depend on the structure of the URNs for the components, 
and the resources named by the component URNs are subject to change, 
the relative resource names aren't stable.

I won't pretend that people won't create such relative thingys,
or even that they aren't useful in short-term contexts,
but they should be clearly distinguished from URNs.

Keith

Date: Fri, 2 May 1997 12:00:36 +0200 (MET DST)
From: "Martin J. Duerst" <[email-masked]>
To: Keith Moore <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] Protocol Action: URN Syntax to Proposed Standard
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Thu, 1 May 1997, The IESG wrote:

[This mail is currently only addressed to the URN group.
I will write to the IESG if the need to do so arises from
our discussion.]

>   The IESG has approved the Internet-Draft "URN Syntax"
>   <draft-ietf-urn-syntax-04.txt> as a Proposed Standard.

> Working Group Summary
> 
>    There has been considerable discussion in the working group,
>    regarding the compatibility of URNs with URLs (including the
>    notion of relative URNs) and the possible internationalization
>    of URNs.  This document leaves relative URNs (with syntax
>    compatible with that of URLs) for future study, by reserving
>    the '/' character.  Internationalization is also left undefined,
>    but this document specifies that URNs must be transmitted in
>    a pure-ASCII representation, and that all URN aware applications
>    must make URNs available for display in the pure-ASCII form
>    to enable reliable transcription by humans.
> 
>    With these compromises, there is strong working group consensus
>    on the document.

While I agree that there was indeed a good working group consensus,
the above explanation, in particular the phrase "Internationalization
was also left undefined" is not very fortunate. It had me fear that
the consensus about UTF-8 was actually thrown out at the last minute,
or whatever. It also gives a bad impression to other protocol writers
in that it seems to say that it is okay to not address internatio-
nalization issues. This is not what we have done. We indeed have
addressed internationalization issues in a way suitable for URNs.

I would therefore suggest that we ask the above text, from the
word "Internationalization", to be rewritten as follows:

Internationalization was addressed by specifying that URNs must
be transmitted in a pure-ASCII representation and by defining an
encoding based on UTF-8 for characters outside ASCII for legacy
namespaces. User interface issues were not addressed but for the
requirement that URN aware applications must make URNs available
for display in the pure-ASCII form to enable reliable transcription
by humans.

Regards,	Martin.

Date: Fri, 2 May 1997 00:39:24 PDT
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: Keith Moore <[email-masked]>
CC: didier ph martin <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] Re: About realtive URNs
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Think of

"Chapter 1 of ISBN nn-nnnnnnnnn-nn".

Then there's "Chapter 2". And "Chapter 3". The table of contents
might even list the URNs of the chapters as relative.

Maybe they're relative URLs, where the "base" is a URN. So the
hierarchy exists but only below the point where you have 
location-independent naming.

If you hold to the view that "URNs are just a set of URL schemes
that seem more permanent and location independent", then
there aren't "relative URNs" but there are "relative URLs that
are relative to a URN base".

Larry

From: Keith Moore <[email-masked]>
To: "didier ph martin" <[email-masked]>
cc: "URN Workgroup" <[email-masked]>, [email-masked]
Subject: [URN] Re: About realtive URNs 
Date: Thu, 01 May 1997 17:30:29 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

I am still firmly convinced that relative URNs are a non-starter.
That is, encoding inter-document relationships into the structure
of a URN, unless those URNs name static entities which never change,
impairs the longevity of URN-space.

Existing schemes which are grandfathered into URN-space might have
such relationships, but that's a property of a particular name space,
not one of URNs in general.

Keith

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 1 May 1997 16:30:06 -0500 (CDT)
To: Leslie Daigle <[email-masked]>
Cc: [email-masked]
Subject: [URN] URN WG & Relative URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Leslie Daigle writes:
 > Hierarchy across the board in URNs:
 > 
 >   Most of the proposals for using hierarchy in URNs are application-
 >   specific (e.g., short-hand expression of identifier within an
 >   HTML document link).
 >   
 >   Most of the concerns about having a namespace-independent 
 >   mechanism for denoting hierarchy have been on the level of
 >   usage in relative URI expression,

It is true that relative URIs that are relative to base URNs require
visible hierarchy in the base URN.

But another, perhaps larger, concern that is independent of relative
URIs is scalable resolution of URNs.  Scalable resolution is not a
single application concern - it is a network architecture concern
because *most* applications that do resolution must do so in a
scalable way in order to accrue the benefits for the network.
Fortunately, it is also to the advantage of the users of applications
to do scalable resolution, but the network infrastructure must support
it.

 >   particularl as concerns the
 >   ability to consistently recreate the absolute URN with confidence
 >   and accuracy -- concerns that are specific to URNs, as opposed
 >   to other URIs, because these are issues URNs are specifically
 >   created to address.

There are no concerns that I know of regarding relative URIs that are
specific to URNs.  (Ron Daniel brings up concerns that are actually
independent of URNs.)

 > There is no such thing as a relative URN.

If you can say that there is no such thing as a relative URN, then
there is also no such thing as a relative URL.  I'm fine with the term
"relative URI".  The meaning of "relative URN" is obviously a
relative URI that is relative to a base URN.

 > There may be application shortcuts for using URNs to generate
 > relative references, but buyer beware.

I don't quite understand this.  One uses relative URIs with base URNs
to generate other URNs.  Where is there any generation of relative
references in the process?

dan

Date: Thu, 1 May 1997 16:30:01 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] URN WG & Relative URNs
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

At this point, I'd like to attempt to summarize the issue as we currently
understand it, and see what the overall position of the URN working group
is on this particular point.

The following is proposed text for this issue in the nascent "URN WG FAQ"
 -- please comment/critique it in that light.

Cheers!
Leslie.

========================================

As I understand this issue, from discussions in the last few days, along
with previous threads, we have the following:

	. Relative URNs
	. Hierarchical URNs

The two are related although not necessarily the same.  Relative URNs 
may include the notion references to fragments of information objects.  
Hierarchical URNs are proposed (in part) for the purpose of being able to 
refer to whole objects relative to some collection of objects -- either 
generically across URNs, or for the individual purposes of a specific URN 
namespace.  

The merits/problems and possible implementations of fragment references in 
URNs are specifically outside the scope of this working group.  The issue of 
relative URNs can be considered as in-scope insofar as we need to determine if 
there are things that can/should be done in the syntax or support structures 
to enable/disable them.

Hierarchy in specific namespaces:
	
  Any namespace is free to define rules of expressing/interpreting
  hierarchy, and may choose to publish those as part of the
  namespace spec.  These rules may or may not conform to existing
  URI hierarchy notations.
  
  This is a specific instance of the fact that namespaces may
  have their own "equivalence" relations defined.  Beyond using
  different characters to denote hierarchy, a specific namespace
  may write it front to back, back to front, or using "()"-delimited
  clusters.  
  
  There have already been specific indications that there are 
  applications and namespaces that would make use of hierarchy
  for specific reasons.

Hierarchy across the board in URNs:

  Most of the proposals for using hierarchy in URNs are application-
  specific (e.g., short-hand expression of identifier within an
  HTML document link).
  
  Most of the concerns about having a namespace-independent 
  mechanism for denoting hierarchy have been on the level of
  usage in relative URI expression, particularl as concerns the
  ability to consistently recreate the absolute URN with confidence
  and accuracy -- concerns that are specific to URNs, as opposed
  to other URIs, because these are issues URNs are specifically
  created to address.

Proposed stance:

  URN syntax is already slated to use the "/" URI hierarchy denoter
  as a reserved character.  Namespaces that elect to permit the
  use of this to expose the hierarchy may therefore have URNs
  that include non-escaped "/" characters.  Applications may choose
  to make use of this -- perhaps for resolution shortcuts, or
  perhaps other things.
  
  As such, HTML and other object-referencing applications may 
  use short-form notations for objects, based on the exposed
  structure in the URN.  These references are _not_ URNs -- they
  may be considered relative URIs, but they are _not_ URNs.  Whatever
  any application software may reconstitute, in whatever manner,
  _may_ be a valid URN, but that is the application's problem
  to ensure.

Summary/conclusion:  

There is no such thing as a relative URN.  There may be application shortcuts 
for using URNs to generate relative references, but buyer beware.

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] RE: Relative URNs
Date: Thu, 1 May 1997 16:13:56 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

"The URN syntax (just approved for Proposed Standard) has only
one character reserved in general for this purpose: "/".  This was done
ON PURPOSE to align with the URL syntax.  If you want to introduce
different delimiters, then it is namespace specific and doesn't apply to
URNs
in general."

You are right I just got he message from IETF. Sorry, if I lost a big part
of the discussion even if I did my research in the archives. If  I
understand well, you only favor the navigation rule. It means that relative
URNs are applied to hierarchical name spaces and are based on the
navigation rule not the concatenation rule. Is that right?
       
 "Ryan Moats" wrote about example on the concatenation rule and the
navigation rule
"Maybe there's a typo in this example, but I don't the relationship
mentioned..."

Sorry, if I wasn't clear, but this was there to show the differences
between the concatenation rule and the navigation rule. There is more than
one way to express relative URNs except if the term is strictly reserved to
the navigation rule with the implicit operator "move to". The concatenation
rule is more like "append to". Thus,am I right to conclude that you exclude
the concatenation rule to exclusively favor the navigation rule? and
therefore can apply to strict hierarchical namespaces? 

""Ryan Moats" 
"Fine.  This is all NAMESPACE specific.  What we want (at least what I
think
we want) is general considerations for relative URNs.  Additional
considerations
may be defined by Namespaces, but I remain unconvinced that any of this
is general (yet)."

I won't say that is there is a typo, I fully understood. There are
implications to that: hierarchical name spaces, where a namespace path is
defined with different delimiters, don't fit into this frame. They will
have to be transformed into "name/name/" name scheme and therefore loose
their original identity. Do we really want this? are we making an other
PURL? (I guess you know the Permanent URL project). don't forget that these
name spaces, especially if they are hierarchical in nature, have a possible
navigation rule. Thus to move within their hierarchy, they will be
transformed into a  /name/name" scheme sooner or later. If that is the
goal, it should be stated. I say sooner or later because the limits imposed
by the URN naming convention will force their writing with "/" in documents
using relative URN within the same name space. Using absolute URN don't
pose any problems, their nature is preserved. If you choose a strict scheme
based on "/" there will be a certain mismatch between the original name
space and its URN notation like for example:

"urn:isbn: 1-57870-000-0" stated as an absolute URN and "../57870" as
relative. For convenience of consistency, it will be easier on the long run
to transform isbn into : 1/57870/000/0". It will be simply more consistent.
LIke URLs are in fact.
For URL the "/" mechanism works well because URLs themselves have "/" in
their absolute form. We stay simply in the same universe. This is not the
case between "1-57870-000-0" and "../57870". I hope you won't see there a
typo.

Again, sorry if I wasn't clear enough 

Didier PH Martin
mailto:[email-masked]
http://www.netfolder.com

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 1 May 1997 13:07:31 -0500 (CDT)
To: "Ron Daniel, Jr." <[email-masked]>
Cc: "URN Workgroup" <[email-masked]>, [email-masked]
Subject: Re: [URN] About realtive URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > I wish I shared your faith on this Dan. However, I'm uneasy about
 > it.

There is not any problem (I am aware of) that is specific to URNs.
There are interesting problems having to do with splitting collections
and replication, as you mention.  But these problems are orthogonal to
URNs.  And there are solutions in any event.

 > >the default
 > >base URI for a document, if not specified by the document or the
 > >delivery package of the document, is the last URI known by the client
 > >in accessing the document,
 > 
 > But this only works if resources that refer to each other using relative
 > links are migrated together.

Indeed, relative URIs depend on being used in the context of their
base URI.  This is an advantage if the relative URIs stay in
the correct context and a disadvantage if not.  But all is not lost.
(And again, this is independent of URNs.)

 > There are several reasonable scenarios where
 > this will not hold:
 > 1)  The owner of a set of such resources sells 1/2 of them to another
 >     party, who takes charge of their storage. Now, 1/2 of the relative
 >     links will have the wrong base if it is determined using the "last
 >     URI known by the client" rule.

In the case of splitting resources that refer to each other by
relative URIs, it will be necessary to make some changes, not
necessarily to the documents themselves.  We can change some of the
relative URIs into absolute URIs.  Or we can designate one of the
locations of the split resources as the base for all the resources and
any requests for resources that are actually at another location will
get a redirect.  (Each such redirect can be remembered by clients to
avoid returning to the base server each time a resource needs to
be requested.)

One must ask how likely it is that resources that refer to each other
by relative URIs will be split up.  Relative URIs ought not be used
generally except when resources are likely to stay together.

 > 2)  Automated replication mechanisms spring up, and the most popular
 >     resource in an interlinked set gets widely replicated while less
 >     frequently used ones are not replicated.

The same kinds of solutions I described for the problem of splitting
resources can apply here too.  Replicas of collections may be full or
partial, and the replicas should probably know which kind they are.  A
partial replica probably needs to work via redirections from the full
base replica, whereas a full replica can let relative URIs use the
replica directly.

Another kind of solution is to dynamically, automatically rewrite
the appropriate relative URIs as the replica is created.   Rewriting
is generally to be avoided though.

 > >If a URN is redirected to a URL, and the URL is
 > >resolved to a document containing relative URIs, then they are
 > >relative to the URL (if the base is not otherwise specified), not the
 > >URN.
 > 
 > Right, and this can break in the two scenarios I mentioned above.

So you are really pointing out the problems of relative URIs.  URNs
have nothing to do with it, once you have a way of deciding what the
base URI is.

 > I'm more in favor of explicit determination of the base URI, either
 > by the BASE tag in HTML or the "destination" field mentioned in the
 > message yesterday.

Even a single explicit base URI is not sufficient if some of the relative
URIs in a document are relative to one base and some are relative to
another base.  This occurs in the splitting and partial replica cases.

 > But here I think we have to be very careful to
 > say that only one BASE tag is allowed. People may associate any
 > number of identifiers with a work, only one of which will make the
 > relative URNs function correctly.

It is possible that muliple base URIs will in fact work
simultaneously.  This will work as long as the neighborhoods of the
name spaces used by all the relative URIs are all the same.

Another kind of multiple base URI that I am interested in is nested
base URIs.  For example, at the top level of a document one base URI
would apply.  But in one particular section that uses lots of icons,
say, another base URI could be designated (e.g. /my/cool/icons).
Nested base URIs will be even more valuable when embedded documents
are supported.  So the relative URIs in a document that is embedded in
another can be specified as relative to their own base URI.  At every
point in the document, only one base URI applies, but it can be a
different base URI at each point.

Furthermore, while I'm at it, instead of only one base URI applying at
any one point in a document, I'd like to see multiple named base URIs
available simultaneously so that several contexts could be mixed.

And then there is the "root" which is always the same for documents on
a server.  A relative URI starting with '/' is rooted relative to that
one server, and there is no way to specify a different root that might
be elsewhere.  This would be useful when replicating a collection of
documents on another server but not relative to the same root. (One
might put each replica in a directory named after the server it came
from.)  Or I might want to say that all the documents under
/groups/sdg/people/liberte/ are "rooted" at that prefix, so
'/resume.html' would be in that directory rather than all the way back
at the server root.  This is much like the Unix chroot.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

From: "Ryan Moats" <[email-masked]>
To: "didier ph martin" <[email-masked]>, "URN Workgroup" <[email-masked]>
Date: Thu, 01 May 97 12:34:36 
Priority: Normal
Subject: Re: [URN] RE: About relative URNs
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 1 May 1997 12:49:53 -0400, didier ph martin wrote:

>Ron and Daniel expressed their concerns about URNs and I agree that we have
>to be very cautious with that. 
>
>I will expand a little bit more to clarify the subject:
>
>First just a recall that we all know from the relative URL RFC, then I will
>explain the implicit rule of this RFC : the navigation rule. Further, how a
>relative URNs should differ from the relative URL scheme to support any
>hierarchical system using different delimiters.

The URN syntax (just approved for Proposed Standard) has only
one character reserved in general for this purpose: "/".  This was done
ON PURPOSE to align with the URL syntax.  If you want to introduce
different delimiters, then it is namespace specific and doesn't apply to URNs
in general.

[snip]
>if we have the other expression: "/name" again we see that
>through the eyes of the navigation rule and say from the current context,
>move to "name" which is under the current context in the hierarchy. And I
>would say that relative URLs are dominated by the navigation rule, like
>file systems name spaces.

Maybe there's a typo in this example, but I don't the relationship mentioned...

[snip]

>To fully see the concatenation rule let's take an other context. A ISBN
>number as: ISBN 1-57870-000-0 (a good book about LDAP) for a certain reason
>I have to write or sort all ISBN beginning with "1" I would state:: "ISBN
>1" and want to get all names from this base then: 
>"ISBN 1" + "57870-000-0" = " ISBN 1-57870-000-0"
>"ISBN 1" + "58834-000-0" = "ISBN 1-58834-000-0"

Again, there may be a typo in this example but I don't see the RHS resulting
from the LHS.

>As you noticed, this is strictly a string concatenation rule. This last
>rule is useful when a recurring pattern occurs within a name space. This
>doesn't necessarily means a hierarchical name space and a navigation rule,
>no, simply a string concatenation rule. And it doesn't mean that a name has
>to contain delimiters. Why do this? 

>
>A simple index exchange between two name spaces:
>
>Let's say that I have to exchange part of a name space from one place to
>the other and that the naming scheme sort this out with some patterns based
>on cities airports like : "YUL" and a sub pattern to express an other
>category like merchandise "0192". This name scheme doesn't have any
>delimiters then the complete expression is : "YUL0192". Now, lets imagine
>that I transport from one name server to an other all object referred with
>the pattern "YUL". I would express "YUL" as a base and just write numbers
>like "0192", "0187", etc. and with the concatenation rule get "YUL" +
>"0192" = "YUL0192", etc. We didn't said here move from this context to,
>etc.. we just used the concatenation rule to create complete expressions
>from a base.

Fine.  This is all NAMESPACE specific.  What we want (at least what I think
we want) is general considerations for relative URNs.  Additional considerations
may be defined by Namespaces, but I remain unconvinced that any of this
is general (yet).

[rest snipped]

Ryan Moats

From: "didier ph martin" <[email-masked]>
To: "URN Workgroup" <[email-masked]>
Subject: [URN] RE: About relative URNs
Date: Thu, 1 May 1997 12:49:53 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

Ron and Daniel expressed their concerns about URNs and I agree that we have
to be very cautious with that. 

I will expand a little bit more to clarify the subject:

First just a recall that we all know from the relative URL RFC, then I will
explain the implicit rule of this RFC : the navigation rule. Further, how a
relative URNs should differ from the relative URL scheme to support any
hierarchical system using different delimiters, This will be followed by a
short explanation of how the concatenation rule may benefit even to flat
name spaces and show that it is not necessarily restricted to hierarchical
name spaces.

Relative URLs, the intent (RFC 1808):

   Absolute URLs contain a great deal of information which may already
   be known from the context of the base document's retrieval, including
   the scheme, network location, and parts of the URL path.  In
   situations where the base URL is well-defined and known, it is useful
   to be able to embed a URL reference which inherits that context

   rather than re-specifying it within each instance.  Relative URLs can
   also be used within data-entry dialogs to decrease the number of
   characters necessary to describe a location.

   In addition, it is often the case that a group or "tree" of documents
   has been constructed to serve a common purpose; the vast majority of
   URLs in these documents point to locations within the tree rather
   than outside of it.  Similarly, documents located at a particular
   Internet site are much more likely to refer to other resources at
   that site than to resources at remote sites.

   Relative addressing of URLs allows document trees to be partially
   independent of their location and access scheme.  For instance, it is
   possible for a single set of hypertext documents to be simultaneously
   accessible and browsable via each of the "file", "http", and "ftp"
   schemes if the documents refer to each other using relative URLs.
   Furthermore, document trees can be moved, as a whole, without
   changing any of the embedded URLs.  Experience within the World-Wide
   Web has demonstrated that the ability to perform relative referencing
   is necessary for the long-term usability of embedded URLs.

Implicit RFC 1808 rules

As you all know, URLs are hierarchical per nature. They where based on file
system name spaces, more precisely Unix file system name spaces. The path
is defined with a "/" delimiter. This scheme has an implicit rule: the
navigation rule and therefore, implicit in this name system is the concept
of iterator or context, this last concept is at the base of the navigation
rule. For example, when we express the following URL:"../name" we say
explicitly that from the current context we move up one level and set the
new context from here, then go to name. This kind of operation is
navigation. if we have the other expression: "/name" again we see that
through the eyes of the navigation rule and say from the current context,
move to "name" which is under the current context in the hierarchy. And I
would say that relative URLs are dominated by the navigation rule, like
file systems name spaces.

Differences between the concatenation rule and the navigation rule:

 We can see the  expression" /name" through the concatenation rule where a
base expression (string) has been defined and the shorter expression
concatenated to result with a complete expression. This last rule is not
totally dependant on a navigation scheme, it is strictly a string operation
and can encompass a lot of expressions. For instance, let's have a base URL
like "http://myserver.com/" and an other like "name" the concatenation rule
is simply a string operation between these two strings which result with:
"http://myserver.com/"  + "name"  = "http://myserver.com/name". There is no
implicit operations like: from this context move down to "name", it is
simply a string concatenation. 
To fully see the concatenation rule let's take an other context. A ISBN
number as: ISBN 1-57870-000-0 (a good book about LDAP) for a certain reason
I have to write or sort all ISBN beginning with "1" I would state:: "ISBN
1" and want to get all names from this base then: 
"ISBN 1" + "57870-000-0" = " ISBN 1-57870-000-0"
"ISBN 1" + "58834-000-0" = "ISBN 1-58834-000-0"
As you noticed, this is strictly a string concatenation rule. This last
rule is useful when a recurring pattern occurs within a name space. This
doesn't necessarily means a hierarchical name space and a navigation rule,
no, simply a string concatenation rule. And it doesn't mean that a name has
to contain delimiters. Why do this? 

A simple index exchange between two name spaces:

Let's say that I have to exchange part of a name space from one place to
the other and that the naming scheme sort this out with some patterns based
on cities airports like : "YUL" and a sub pattern to express an other
category like merchandise "0192". This name scheme doesn't have any
delimiters then the complete expression is : "YUL0192". Now, lets imagine
that I transport from one name server to an other all object referred with
the pattern "YUL". I would express "YUL" as a base and just write numbers
like "0192", "0187", etc. and with the concatenation rule get "YUL" +
"0192" = "YUL0192", etc. We didn't said here move from this context to,
etc.. we just used the concatenation rule to create complete expressions
from a base.

Differences with relative URLs
Thus, relative URLs are governed by the navigation rule. Relative URNs are
governed by the concatenation rule. For relative URLs, a based URL is
defined to work within a certain scope, we have then to define also rules
for a base URN scope. Relative URNs are relative to a base within this
scope and not outside it. 
Obviously, relative URNs are useful only when there is recurring string
patterns within the naming scheme. When we look at a lot of naming scheme,
it is surprising to notice that a lot of them have implicit hierarchies.
However a lot of them doesn't have delimiters to express the hierarchical
tree, just string patterns appended. Thus, some name spaces contain
delimiters to explicitly show the hierarchy, others don't. In random name
spaces (Where there is no recurrent patterns), relative URNs are totally
useless. In naming systems having patterns, URNs are useful. 

I know that the words "relative URNs" could bring confusion with "relative
URLs", so maybe we should call that with an other word in order to
differentiate both concepts. What do you think?

>From an other point of view, I don't think that an expression like
"../name" within URNs is desirable because it can apply only to naming
schemes having a delimiter and even worse, the delimiter "/", so what about
" . \ @ , ? * ( ) etc. This would right at the beginning restrict ourselves
to a specific naming system which I think is not what we want. Thus, the
navigation rule cannot work with relative URNs, the concatenation rule, at
contrario, is working for all kinds of naming system having recurrent
patterns with or without delimiters. The concatenation rule doesn't even
care about delimiters because it is a string operation, not a navigation
operation, we don't move context, we simply append strings.

A useful case with a completely random naming system

Let's consider now a complete set of objects uniquely identified by a quasi
random naming system RPC GUIDs. In an index exchange document I will have
to list the objects and their name like

object: 2893B561-42BF-11d0-915B-E8B102C10000
object:2823461-42BF-11d0-915B-E8B102C10000

If I want to uniquely define them within this collection with URNs I will
have to write:
object: urn:guid:2893B561-42BF-11d0-915B-E8B102C10000 
for all objects. It would be more economical to set a base URN like

"urn:guid"
and object with:
"2823461-42BF-11d0-915B-E8B102C10000"
You are right, in this case I just gained 8 characters that I don't have to
write. But if this time I have a not so random GUID scheme like they all
start with 2893B561-42BF-11d0 for a certain application, It becomes obvious
that now I gained something.

I am still studying how to address fully concerns brought by Ron and
Patrick to get a strong relative URN schema, but I got to fully explain the
main difference underlying the relative URN concept - the concatenation
rule vs. the underlying relative URL concept - the navigation rule.

We will have to deal with all kind of naming systems, based on numbers,
characters, etc. Up to now, no problem if it is based on ASCII and have an
English centric view of the world. Let's now imagine a Japanese naming
system or even harder than that: a Chinese naming system (I meant here
repectively Katanata for japanese and Kanji for chinese) In languages like
Chinese, a lot of naming systems are based on patterns that are... a single
character. They construct whole-part systems with that. Differently, In
german, it is possible to concatenate words to gets a new word (you know,
philosophical expressions like Aufhebung = Auf + hebung) I saw funny naming
systems at the office in Germany based on concatenation. Thus, in Unicode,
the concatenation rule still works and may even be better adapted to
non-English  naming systems.

Conclusion:
A relative URN is valid within a certain scope, within that scope, the
concatenation rule is applied to obtain the full URN. Stateless protocols
may have problem with that because they don't have any state and a base is
a state. Within other types of documents, self contained like index
exchange, the problem is more easily resolved by saying that the scope is
the document. To resolve the stateless problem of HTTP, a HTML or XML
document, in order to use a relative URN we should define a basewithin the
HTML document, the scope would be the HTML document. This would be useful
if the HTML document wants to extract a collection of objects from a name
service. To get a larger scope would mean that we introduce states or the
concept of a single session to HTTP. I think that this not the intention of
the HTTP working group, even with the HTTP 1.1 pipe concept. So, to be
cautious, let define the scope within a single document may it be a HTML,
SGML or whatever type of document. 

Date: Thu, 01 May 1997 09:33:05 -0600
To: Daniel LaLiberte <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] About realtive URNs
Cc: "URN Workgroup" <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 10:01 AM 5/1/97 -0500, Daniel LaLiberte wrote:
>Ron Daniel, Jr. writes:

> >   1) Unambiguous determination of the base URN
>
>No problem.

I wish I shared your faith on this Dan. However, I'm uneasy about
it.
 
>the default
>base URI for a document, if not specified by the document or the
>delivery package of the document, is the last URI known by the client
>in accessing the document,

But this only works if resources that refer to each other using relative
links are migrated together. There are several reasonable scenarios where
this will not hold:
1)  The owner of a set of such resources sells 1/2 of them to another
    party, who takes charge of their storage. Now, 1/2 of the relative
    links will have the wrong base if it is determined using the "last
    URI known by the client" rule.
2)  Automated replication mechanisms spring up, and the most popular
    resource in an interlinked set gets widely replicated while less
    frequently used ones are not replicated.

>If a URN is redirected to a URL, and the URL is
>resolved to a document containing relative URIs, then they are
>relative to the URL (if the base is not otherwise specified), not the
>URN.

Right, and this can break in the two scenarios I mentioned above.

I'm more in favor of explicit determination of the base URI, either
by the BASE tag in HTML or the "destination" field mentioned in the
message yesterday. But here I think we have to be very careful to
say that only one BASE tag is allowed. People may associate any
number of identifiers with a work, only one of which will make the
relative URNs function correctly.

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  

To: IETF-Announce: ;
Cc: RFC Editor <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>
Cc: [email-masked]
From: The IESG <[email-masked]>
Subject: [URN] Protocol Action: URN Syntax to Proposed Standard
Date: Thu, 01 May 1997 10:18:29 -0400
Sender: [email-masked]
Reply-To: The IESG <[email-masked]>

  The IESG has approved the Internet-Draft "URN Syntax"
  <draft-ietf-urn-syntax-04.txt> as a Proposed Standard. This document
  is the product of the Uniform Resource Names Working Group. The IESG
  contact persons are Keith Moore and Harald Alvestrand.

Technical Summary

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers.  This is in contrast
   with Uniform Resource Locators (URLs) which typically have short
   lifetimes and are tied to a particular resource location.

   This document specifies the syntax to be used for URNs, the
   requirements for transmission of URNs, and the use of the
   URN syntax for both new and pre-existing namespaces.

   The syntax described in this document is compatible with URL
   syntax (for ease of adding URN support to applications which
   already support URLs).

Working Group Summary

   There has been considerable discussion in the working group,
   regarding the compatibility of URNs with URLs (including the
   notion of relative URNs) and the possible internationalization
   of URNs.  This document leaves relative URNs (with syntax
   compatible with that of URLs) for future study, by reserving
   the '/' character.  Internationalization is also left undefined,
   but this document specifies that URNs must be transmitted in
   a pure-ASCII representation, and that all URN aware applications
   must make URNs available for display in the pure-ASCII form
   to enable reliable transcription by humans.

   With these compromises, there is strong working group consensus
   on the document.

Protocol Quality

   Keith Moore reviewed the specification for IESG.

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 1 May 1997 10:01:58 -0500 (CDT)
To: "Ron Daniel, Jr." <[email-masked]>
Cc: "URN Workgroup" <[email-masked]>, [email-masked]
Subject: Re: [URN] About realtive URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > As several people on this list know, I'm not a big fan of relative
 > URNs. However, I think they are pretty much unavoidable.

Your statement that relative URNs are unavoidable is news to me, and
I'm curious why you think that is so.

 > There are about three conditions I would like to see fullfilled by
 > any relative URN scheme.

 >   1) Unambiguous determination of the base URN

No problem.  This is well defined by the relative URI document with
the one clarification (that I mentioned previously) that the default
base URI for a document, if not specified by the document or the
delivery package of the document, is the last URI known by the client
in accessing the document, not the first URI.

This means that if the client uses a proxy is in resolving a URI and
the proxy receives a redirection to another URI, then the proxy must
return that redirection URI to the client whether or not the proxy also
follows the redirection to continue the resolution itself.  I expect
that HTTP proxies behave this way already since redirections are
already in widespread use.

BTW, this same requirement is also important even if there are no
relative URNs.  If a URN is redirected to a URL, and the URL is
resolved to a document containing relative URIs, then they are
relative to the URL (if the base is not otherwise specified), not the
URN.

 >   2) Allowing some namespaces to say that they are not to be processed
 >      as relative URNs.

No problem.  If naming authorities never use unencoded '/' in any
identifier that is registered, then there is never any chance of it
allowing relative URNs, is there?

 >   3) Using the same rules for building relative URNs as are used for
 >      relative URLs.  (This one is a pragmatic concern, not a principle).

Absolutely.

 > I am not so sure how to handle relative URNs when the document does not
 > cleary indicate one and only one base identifier. Dan has put up the
 > rules for resolving relative URLs before, we need to make sure they
 > will generalize to different protocols in the future. If we can't come
 > up with rules that can guarantee unique base IDs, then we are
 > begging for trouble with relative URNs.

I believe that the above clarification should be sufficient.

 > Some namespaces may hide a hierarchical structure. If they are hiding it,
 > we should not presume to make them expose it. I think that if we are to
 > have relative URNs, some namespaces should be able to say not to ever
 > try to build a URN in that namespace using relative processing rules.
 > This means that they can't use unencoded '/' characters, and the document
 > specifying such a namespace needs to say that they are not to be handled
 > in a relative manner.

Actually, I think it might be possible to allow unencoded '/' in
identifiers without any implication of support for relative URIs.  The
author of a document should know what base URI is intended to be used
with any relative URIs that the author puts in the document.  Any
other relative URIs that are not "published" by the author would be
mere guesses on the part of users.  Unless we require servers to
provide some non-trivial response to requests for any '/'-terminated
prefix of a URI, then there does not appear to be any requirement that
the existence of '/'s in an identifier means anything.  The only
context in which '/' in an identifier means anything (currently) is if
the identifier is used as a base URI *and* there are relative URIs
that are relative to that base.

There might be another context in which '/' has meaning.  Security
realms are relative to directories.  So two URIs with the same
'/'-terminated prefix may be identifiers for resources contained in
the same security realm, and clients may cache security info relative
to that realm.  I'm not clear on whether this is the case or where it
is specified.

As much as I've argued above that '/' doesn't mean much (currently),
I'd also argue that it should be reserved to mean only things relative
to hierarchical contexts.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Date: Thu, 1 May 1997 16:25:31 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: "Ron Daniel, Jr." <[email-masked]>
cc: didier ph martin <[email-masked]>, URN Workgroup <[email-masked]>
Subject: Re: [URN] About realtive URNs
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Wed, 30 Apr 1997, Ron Daniel, Jr. wrote:

> >Maybe a good start would be to take ISBN and TSN name
> >spaces as a base
> 
> I don't think we have any demonstration of a need to handle ISBNs in a
> relative manner.

I agree with Ron. One have to differ between the ability and need of
expressing a URN in a relative manner and having a delegated namespace,
i.e. a hierarchy. ISBNs have the latter, but don't need the former...from
my point of view.

   Patrik