Subject: Re: [URN] About realtive URNs
From: "Ron Daniel, Jr." <[email-masked]>
To: "didier ph martin" <[email-masked]>, "URN Workgroup" <[email-masked]>
Date: Wed, 30 Apr 1997 16:05:31 -0600

At 09:38 AM 4/30/97 -0400, didier ph martin wrote:
[Lots of stuff about relative URNs]

As several people on this list know, I'm not a big fan of relative
URNs. However, I think they are pretty much unavoidable. If they are,
then we should be very careful to document our concerns about them.
There are about three conditions I would like to see fullfilled by
any relative URN scheme.
  1) Unambiguous determination of the base URN
  2) Allowing some namespaces to say that they are not to be processed
     as relative URNs.
  3) Using the same rules for building relative URNs as are used for
     relative URLs.  (This one is a pragmatic concern, not a principle).

>Because of the nature of our NSS, it is possible to set relative paths from
>a base URN. So in the Index definition file we set a base URN. All
>subsequent objects are then defined with relative NSS from this base. 
>Example:
>
>destination:"urn:tns:Desktop/MyNameSpace"
>tocOf:"http://www.w3.org"
>......
>......
>.....
>
>unit:"name1"
>location:"/specs"

The file format you give in your example clearly
indicates the base, that is good. Are multiple "destination"s
forbidden? If not, why not? (In an earlier message I gave the example
of a book that had an ISBN, a UPC, and an LC card number. Most books
published in the US will carry these three identifiers. So, a unique
base identifier is not a safe assumption, it needs to be explicitly
guaranteed).

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.

>This NSS can serve as a base for relative
>URNs. My bet is that some name space will be good candidates for relative
>URNs, this will be obviously hierarchical name spaces. Flat name spaces
>will be harder to set as relative URNs except if they hide a hiearchical
>structure like ISBN.

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.

>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 know we will have to define TSN as a URN scheme.
>speaking of this, is there any template for this? Who's working on the
>sample URN NSS draft or RFC? we can follow the same format).

Currently the draft by Cliff Lynch, Cecilia Preston, and I is the only
one that I know of which defines namespaces (ISBN, ISSN, and SICI).

The rules for registering NIDs are a subject for discussion. I'm
afraid that the rules I proposed in my last message on the subject are
probably not friendly to TNS (since I tend to emphasize the adoption
of important legacy name spaces like ISBN). 

>My first suggestion is that we use the following rule that we can call the
>concatenation rule:
>
>The base URN is concatenated to each relative URN. So in the example above
>we have:
>
>Base URN = urn:tns:Desktop/My Name space
>relative URN = name1
>
>complete URN = Base + Relative = urn:tns:Desktop/My Name space + name1 =
>urn:tns:Desktop/My Name space/name1
>
>We can apply this concatenation principle to other NSS candidates for
>relative URNs. Thus, the idea, is that is we have defined a base URN
>(should be an absolute one) relative URN are based on this one. Name
>resolution should be done first by concatenating the base (absolute) and
>the relative URNs, this results with an absolute URN.

You need to take a look at the rules for relative URLs, as well as
the ...unusual... way Netscape handles some relative URLs, and make sure
that your rules match up with those. 

>Comments? I saw part of the discussion about ISBN and a relative schema,
>How could we set a ISBN relative URN without deforming the name space (NSS)
>naming convention (I mean here hte xxx-xxx- naming system).

We can't. If we want to treat ISBNs hierarchically, we would have to
use '/' instead of '-'. I am unaware of any pressing need to treat
ISBNs hierarchically, and am aware of several reasons not to do so.

> Is the
>concatenation rule making sense in other contexts than our.

>Are there any
>showtopper for relative URNs?

I think there are dangers over long time scales. There has to be a clear
indication of the base URN onto which the relative parts are appended.
If there is not, then we run the risk of constructing a valid URN
for a different resource. For example, the book that had the ISBN, UPC, and
LC number. If I make a link to "../1234", is that supposed to be a
relative ISBN, a relative UPC, or a relative LC number? I might end up
with the wrong thing. Even if one format, such as the one you gave as
an example, has an unambiguous way to identify the base, not all formats
will. Therefore the rules have to be extended to cope with such formats.

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] About realtive URNs
Date: Wed, 30 Apr 1997 09:38:24 -0400
Sender: [email-masked]
Reply-To: "didier ph martin" <[email-masked]>

Hi,

I know that we are not there yet, I mean we don't have any RFC or Draft
about relative URNs. However, because of the nature of our work, we have to
had to create a relative URN schema.

We are currently working on the integration of indexing, meta data and
URNs. To say that in couple words. We set a language were a list of objects
are defined with attribute value pairs. Each object is uniquely refered
within the collection with a URN. The urn follow the actuals drafts and RFC
for urn syntax (i.e:  <URN> ::= "urn:" <NID> ":" <NSS>). Our NSS is a
hierarchical name space like one found in the Path NSS (as you now an other
URN). Our NID is TNS for Tranportable Name Space. At the minimum an object
is defined with to attibutes:
a) its URN and its URL. 

Because of the nature of our NSS, it is possible to set relative paths from
a base URN. So in the Index definition file we set a base URN. All
subsequent objects are then defined with relative NSS from this base. 
Example:

destination:"urn:tns:Desktop/MyNameSpace"
tocOf:"http://www.w3.org"
......
......
.....

unit:"name1"
location:"/specs"

In this example both URNs and URLs are relative. each unit or object is
relative to the destination URN (i.e name space) and each unit's location
is relative to tocOf URL.

Basically what this is doing is: A portion of a name space is transported
from one name space to an other. the destination attribute indicates the
pivot point or insertion point within the destination name space. All
subsequent objects defined after this header are relative to the base
insertion point. This scheme works for many hierarchical name spaces like
directories, shell desktop name spaces, etc...

So, after having stated our work, we are greatly interested in discution a
common scheme for relative URNs. This NSS can serve as a base for relative
URNs. My bet is that some name space will be good candidates for relative
URNs, this will be obviously hierarchical name spaces. Flat name spaces
will be harder to set as relative URNs except if they hide a hiearchical
structure like ISBN. Maybe a good start would be to take ISBN and TSN name
spaces as a base (I know we will have to define TSN as a URN scheme.
speaking of this, is there any template for this? Who's working on the
sample URN NSS draft or RFC? we can follow the same format).

My first suggestion is that we use the following rule that we can call the
concatenation rule:

The base URN is concatenated to each relative URN. So in the example above
we have:

Base URN = urn:tns:Desktop/My Name space
relative URN = name1

complete URN = Base + Relative = urn:tns:Desktop/My Name space + name1 =
urn:tns:Desktop/My Name space/name1

We can apply this concatenation principle to other NSS candidates for
relative URNs. Thus, the idea, is that is we have defined a base URN
(should be an absolute one) relative URN are based on this one. Name
resolution should be done first by concatenating the base (absolute) and
the relative URNs, this results with an absolute URN.

Comments? I saw part of the discussion about ISBN and a relative schema,
How could we set a ISBN relative URN without deforming the name space (NSS)
naming convention (I mean here hte xxx-xxx- naming system). Is the
concatenation rule making sense in other contexts than our. Are there any
showtopper for relative URNs?

I can just tell you that practically, it is a lot more economical to have
relative URNs (there is less to code, in the case of hierarchical name
spaces, you don't have to rewrite the whole hierarchy each time). This easy
to implement. An interpreter can easily be set to resolve urns with the
concatenation rule. And all this is not a simple theoritical exercice, we
have actually a concrete example of this with up to 50 000 downloads up and
running. This is probably the largest URN running implementation today.

Have a good day.

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-biblio-00.txt
Date: Fri, 25 Apr 1997 09:25:12 -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     : Using Existing Bibliographic Identifiers as 
                   Uniform Resource Names                                          
       Author(s) : C. Lynch, C. Preston, R. Daniel
       Filename  : draft-ietf-urn-biblio-00.txt
       Pages     : 10
       Date      : 04/23/1997

A system for Uniform Resource Names (URNs) must be capable of supporting 
identifiers from existing widely-used naming systems.  This document 
discusses how three major bibliographic identifiers (the ISBN, ISSN and 
SICI) 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-biblio-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-biblio-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-biblio-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-biblio-00.txt

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

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

--OtherAccess--

--NextPart--

From: [email-masked]
To: [email-masked]
Subject: [URN] An URN-like service on the 'Net....
Date: Fri, 25 Apr 1997 00:20:59 +0200
Sender: [email-masked]
Reply-To: [email-masked]

See http://www.hyperstamps.com/index.html

I became aware of them because they use object identifiers as
time-and-space-unique identifiers. Interesting.....

                Harald A

Date: Wed, 23 Apr 1997 15:20:56 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: [URN] Revised URN Working Group Milestones
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Here is the URN Working Group charter, with revised milestones.

Uniform Resource Names (urn) Charter

Chair(s)

   * Leslie Daigle <[email-masked]>
   * John Curran <[email-masked]>

Applications Area Director(s):

   * Keith Moore <[email-masked]>
   * Harald Alvestrand <[email-masked]>

Area Advisor

   * Harald Alvestrand <[email-masked]>

Mailing List Information

   * General Discussion:[email-masked]
   * To Subscribe: [email-masked]
        o In Body: In body of message: subscribe urn-ietf
   * Archive: ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive

Description of Working Group

The goal of this working group is to define both a Uniform Resource Name
(URN) framework and an initial set of components that fit this framework.

URNs are persistent identifiers for information resources. The output of
this Working Group will comply with RFC 1737, which defines URNs and gives
requirements for them. The framework will define the mechanics for enabling
global scope, persistence, and legacy support requirements of URNs;
requirements for namespaces to support this structure will also be defined.
Although the framework will allow URNs to be defined that vary in terms of
degree of scalability and persistance, ensuring "user friendliness" of all
resultant identifiers is beyond the scope of this group.

This WG will define the framework for URNs, at least one resolution registry
system, and at least one namespace. RFCs describing additional material will
also be developed (per the milestones, below).

Input documents:

o A Framework for the Assignment and Resolution of Uniform Resource Names

o Resolution of Uniform Resource Identifiers using the Domain Name System

o Requirements for URN Resolution Systems

Goals and Milestones

[DONE] Oct 96
     Submit revision of URN Framework document as Internet-Draft.
[DONE] Oct 96
     Submit revised version of the NAPTR proposal as an Internet-Draft.
[DONE] Oct 96
     Submit Syntax document as an Internet-Draft.
[DONE] Oct 96
     Submit document detailing the N2L/N2R/etc resolution results as an
     Internet-Draft.
[DONE] Dec 96
     Submit paper outlining grandfathering one namespace into the framework
     as an Internet-Draft.
[DONE] Dec 96
     Submit NAPTR proposal to IESG as Experimental RFC. 
[DONE] Dec 96
     Submit syntax paper to IESG for publication as an RFC.
May 97
     Submit revised grandfather namespace document as Internet-Draft.
May 97
     Submit revised N2L/N2R/etc document as an Internet-Draft.
May 97
     Submit revised namespace requirements document as an Internet-Draft.
May 97
     Submit document describing one (new) namespace as an Internet-Draft.
May 97
     Submit revision of URN Guidelines document as Internet-Draft.
Jun 97
     Submit N2L/N2R/etc document to IESG for publication as RFC.
Jun 97
     Submit grandfathered namespace paper to IESG for publication as RFC.
Jul 97
     Submit namespace requirements document to IESG for publication as an RFC.
Jul 97
     Submit Framework (Guidelines) document to IESG for publication as an RFC. 
Jul 97
     Submit revised new Namespace document as Internet-Draft.
Aug 97
     Submit new namespace proposal to IESG for publication as RFC.

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

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

Date: Wed, 23 Apr 1997 15:14:24 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: [URN] URN WG Minutes
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Here are the minutes from the URN Working Group meeting in Memphis, April 10, 
1997.

		  Minutes of the URN Working Group
			38th IETF Memphis TN
			April 10, 1997

Session Chair - Leslie Daigle, Bunyip
Minutes: Sally Hambridge - Intel

Summary:

The URN Working Group met and discuessed the status of submitted RFCs 
and drafts.  There are 3 documents which have gone to the IESG: The
URN Syntax draft as proposed standard, The NAPTR document, which has
gone as experimental, and the THTTP draft, also experimental.  There
are also 3 new drafts and one revised draft, although one "draft"
did not make it to the ID editor by the deadline for the Memphis meeting.
After discussing all the documents, the group reviewed progress to date
on milestones and agreed to a revised set of dates for deliverables.
Finally, they agreed to creating a FAQ to document decisions, and
to using the RFCs as a new namespace (pending IESG approval).

Minutes:

Leslie opened the meeting by reviewing the status of the charter.  We
have not met all the milestones although we have made substantial progress.
The group has 3 documents which have gone to the IESG:  The URN Syntax
has gone as a proposed standard, the NAPTR document has gone as an 
experimental document, and the THTTP document has also gone as an
experimental document.  The group has 3 new drafts and one revised draft.
There are relatively few things left as milestones which we have to
produce so it is conceivable that Munich might be our last meeting.

Karen Sollins presented the Framework and Requirements Document and
began by talking about the Security requirements.  She has added some
paragraphs on potential threats and how to deal with them in the
framework (not mechanisms to deal with them).  She noted that there
was clarification needed about the words "authoritative" which could
mean it must be possible to have a version by a person authorized to 
write it, or there must be a certified version.  Both should be 
possible.  She also noted that "access control" could mean access for
read only, for read and modify, and for read with verification.  There
also needs to be a means for certification without passing the original
record.

Leslie then wondered if the draft should really be called a "Requirements"
document when we would not be able to see far enough into the future to
be able to state categorically what needed to be a requirement.  John
Curran thought the draft was much better than previous versions as one
could easily relate paragraphs to requirements, but he too felt uneasy
with the word "requirements".  After much discussion, we agreed (ROUGH
CONSENSUS - FAQ maintainer take note) that the Document should proceed
but needed to be called Guidelines or Considerations for an RDS rather
than Requirements.  Karen felt that ubiquity and scalibility were
requirements (or considerations) which were still missing from the 
document, and urged us to take up discussion of these issues on the
list.

John Curran said that in the future, after we have operational experience
we (not in the lifespan of this working group) needed to produce a crisp 
requirements document and that Karen's doc would continue to proceed as 
informational.

Michael Mealling spoke to the URN Resolution Services draft.  He
said he had drawn most of the content from the THTTP draft.  He felt
that the scope of the document was larger than the working group 
charter, since it encompassed other URI services.  Karen suggested
he needed to be clearer that he was not talking about a global RDS
but about local resolution services.  The draft also needs a section
on security considerations, and on error processing.  John C. pointed
out that Text/URI was not registered as yet, and Ron Daniel admited 
he needed to do that.  Karen S said she was not happy with the example
and that we needed to be clearer about "today's weather" and " a weather
map for April 10, 1997" which were 2 separate things which might have
a point in time of overlap and Michael agreed that a concept of equality
which is time-based needs to be clarified.

Finally, we agreed (ROUGH CONSENSUS) that the draft needed to be called 
URI Services necessary for URN Resolution services and that it could
proceed as either informational or experimental.  Again, a standards-track
document will be revisited after operational experience has been gained.

Cliff Lynch presented the ID which is not quite an ID.  It had been
posted to the list, but in a format that was not friendly for all
mailers and needed to be re-posted.  Since the URN syntax has been 
established, this draft explored how ISBNs and ISSNs as well as 
Serial Item and Contribution Identifier Strings might map to URN.  There 
are no particular syntax problems although some %HH encoding is required.
This document is useful for showing how resolution will work in practice.
ISSNs will probably take the user to a navigation apparatus because
they represent an ongoing publication,  The apparatus will lead the
user to a way to search/browse the serial desired.  The group made clear
that this document showed how the bibliographic area mapped into the
URN name space.  Ron pointed out a caveat that we hadn't talked about
which standards bodies have control over the ISBN and ISSN space and
Cliff assured him there was weasel language in the draft over this issue.

Patrik Faltstrom presented the Namespace Requirements draft.  This draft is 
problematic because in trying to define the requirements for registering
of a name space one fell into operational requirements for the registration
process.  There has been some violent disagreement about what
should be in the document, and Patrik and his co-author Renato (not able
to be present at the meeting), did not even seem to be in agreement.  Patrik 
thought it should deal with grandfathering in existing name spaces.  Renato 
thought it should be about the registration process.  John C. suggested we 
decide who the consumer of the document should be.  He suggested we presume 
it was IANA, and that we should think about what IANA would need from the 
document.  We decided (ROUGH CONSENSUS) that the document needed to go 
forward as a non-judgemental checklist.  This lead to a discussion about
the problems of having a checklist which avoided operations issues,
and the problems of assigning names.  Michael Mealling mentioned that
he needed some arbiter for this problem, and Leslie suggested he refer
current name registration problems to the URN WG.  Leslie acknowledged that we 
have problems with assigning name spaces: Is it a name space, Should 
someone have the name?  What happens when "you" say "no"?  We are just
NOT ready to address the "Can you have it" problem, and will focus
for now on the technical issues of evaluation whether something COULD be a 
namespace.

We spoke for quite a while on the problems of registering name spaces
and discovered areas where there be dragons.  There seems to be large
dragons where ownership is unclear.

To Summarize for existing drafts:

Requirements and Framework - will go through another round of editing, and
continue on its way as informational with a change in focus from 
"requirements" to "Considerations and Guidelines".

URN Resolution Services: Will go forward as FYI as the "List of URI
Services needed by URNS"

Bibliographic IDs - is OK as a proof of the concept.  Will go quickly
to last call  as informational after reposting to the list in a 
format readable by all.

Namespace Requirements - Will describe technical considerations of 
a namespace - not "Can you have it" issues.

We decided we needed a glossary which would define terms which spanned
all the documents.  Dirk-Willem Van Gulik volunteered to be the
glossary editor, and thought he could have a version which would be
put on the web-page by July 1997.

Other Issues

Ryan Moats presented an Experimental URN namespace, in which he 
took RFC's as the data.  The experiment is intended to help gain
experience and insight into the namespace registration process and
issues.

NID: "ietf"
BNF grammar for NSS:
 - <nss> := <family> ":" <number>
 - <family> := "rfc" | "std" | "fyi"
 - <number> := sequence number

Resolution functionality is currently: N2L, N2Ls, N2R, N2Rs, N2C

Introductory URL Page: http://dsm0.ds.internic.net/urn

URL for testing:
http://dsm0.ds.internic.net:8080/urn-res/<function>>?<urn>

Michael said he will try NAPTR today as well.

Following on to Dan Connolly's suggestion on the mailing list, the group then 
decided that decisions of the group needed to be captured somehow, so we did 
not have to contantly revisit decisions.  We decided (ROUCH CONSENSUS) to 
create a FAQ which could be posted to the list periodically.  Leslie will 
write the first iteration of the FAQ.  One of the first things to be 
documented will be the decision surrounding the use of urn:

There is a new URL syntax draft (draft-*-fielding---.04.txt) which has
ONE paragraph which says that URL syntax is for all URIs.  We will
approach the editors and ask them to change it.  We need to demonstrate
the lack of consensus from the URN working group that the URL
syntax draft applied to URNs.  There is very good work in the draft 
about relative URLs.  

We then reviewed the milestones and decided that the only work which was
absent was work on a new namespace.  We elected to use Ryan Moats 
experiment with the RFCs pending approval from the IESG.  The new 
milestones are:

May 97
     Submit revised grandfather namespace document as Internet-Draft.
May 97
     Submit revised N2L/N2R/etc document as an Internet-Draft.
May 97
     Submit revised namespace requirements document as an Internet-Draft.
May 97
     Submit document describing one (new) namespace as an Internet-Draft.
May 97
     Submit Framework (Guidelines) document to IESG for publication as an RFC. 
Jul 97
     Submit N2L/N2R/etc document to IESG for publication as RFC.
Jul 97
     Submit grandfathered namespace paper to IESG for publication as RFC.
Jul 97
     Submit revised new Namespace document as Internet-Draft.
Aug 97
     Submit new namespace proposal to IESG for publication as RFC

The meeting ended on time.

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

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

Date: Tue, 22 Apr 1997 08:55:43 -0600
To: [email-masked] (Stu Weibel), [email-masked]
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] NID rambling
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 10:15 AM 4/22/97 -0400, Stu Weibel wrote:
> Jon The Prolific writes:
>> I thought ISBN _were_not_ globally unique because some publishers reuse
>> them after a period of time for a new work?
>
>[...] of all the problems of bibliographic control,
>duplicate ISBN numbers doesn't even make the list.

I agree with Stu. Duplicate ISBNs do exist, but are not a serious problem.
Errors such as those are a fact of life that we will have to deal with.

Later,

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, 22 Apr 1997 10:15:07 -0400
From: [email-masked] (Stu Weibel)
To: [email-masked], [email-masked]
Subject: Re: [URN] NID rambling
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Stu Weibel)

> I thought ISBN _were_not_ globally unique because some publishers reuse
> them after a period of time for a new work?

It is true that there are rare cases where publishers (who are assigned
blocks of numbers for assignment to their materials) have by mistake
reassigned numbers, but the rules prohibit such action.

This illustrates an interesting property of naming systems.  They are
not flawless (similar errors have been documented for the SSN system in
the US, for example).

The level of security and quality of assurance can be set at some
arbitrarily high level to prevent the majority of such errors, but at a
cost.  Naming must be done inexpensively for most objects, if it is to
be done at all.  If you want to impose constraints, you must accept the
costs (including lack of deployment).  Let the system accomodate a
modest degree of error, and the costs are FAR lower and the common good
is far better served: of all the problems of bibliographic control,
duplicate ISBN numbers doesn't even make the list.

stu

Date: Tue, 22 Apr 1997 14:13:41 +0100 (BST)
From: Jon Knight <[email-masked]>
To: Stu Weibel <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] NID rambling
Sender: [email-masked]
Reply-To: Jon Knight <[email-masked]>

On Tue, 22 Apr 1997, Stu Weibel wrote:
> These are all globally unigue *IF* their respective naming authorities are
> registered in the URN name space:
> 
>   URN:ISBN:0-395-32943-4

I thought ISBN _were_not_ globally unique because some publishers reuse
them after a period of time for a new work?

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

Date: Tue, 22 Apr 1997 07:16:37 -0400
From: [email-masked] (Stu Weibel)
To: [email-masked], [email-masked]
Subject: Re: [URN] NID rambling
Sender: [email-masked]
Reply-To: [email-masked] (Stu Weibel)

Patrik writes, in part:

> The problem that Dirk and I discussed is the problem with differences
> between local registries and global ones. It is _very_ easy to create
> another US-centric (or any country) system by for example saying that
> social security numbers in one country get their own namespace. The same
> thing with library of congress numbers. What is a global existing naming
> system? Are the library of congress numbers truly global? Or is it centric
> in the english-speaking world? Or only in the US?

Stu responds with an edge of churlishness (so what else is new?):

These are all globally unigue *IF* their respective naming authorities are
registered in the URN name space:

  URN:ISBN:0-395-32943-4
  URN:LCCN:82-9346
  URN:OHIO-DRIVERS-LICENSE:RL948134

These are not guaranteed unique:

  URN:0-395-32943-4
  URN:82-9346
  URN:RL948134
 
> I don't know, and I don't know who should make the descision.

No one on this list has perfect knowledge about how names should be
assigned and by whom, or how they will be used.

So, make simple rules UNENCUMBERED by any of the many ideological
perspectives we have been arguing about for lo, these many years, and
support easy adoption by whatever organizations want to assign names.

The URN infrastructure CANNOT ASSURE anything; it can only ENABLE good
practices by organizations with the committment to sustain them.

Date: Tue, 22 Apr 1997 12:07:56 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: "Ron Daniel, Jr." <[email-masked]>
Cc: "Dirk.vanGulik" <[email-masked]>, [email-masked]
Subject: Re: [URN] NID rambling
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Mon, 21 Apr 1997, Ron Daniel, Jr. wrote:

> >2.	IANA _assigns_ NID's upon request; rather
> >	than allow the requester to choose. IANA
> >	'should' use a simple counter, a random
> >	string, or simply time time in seconds
> >	or something that the request arrives. IANA
> >	'can' assign a name like ISO or ISBN if it
> >	wants to.
> 
> What I think we need to establish are the rules whereby IANA can say
> "you asked for 'foo' and you get it" or "you asked for 'foo' and you don't
> get it".

The problem that Dirk and I discussed is the problem with differences
between local registries and global ones. It is _very_ easy to create
another US-centric (or any country) system by for example saying that
social security numbers in one country get their own namespace. The same
thing with library of congress numbers. What is a global existing naming
system? Are the library of congress numbers truly global? Or is it centric
in the english-speaking world? Or only in the US?

I don't know, and I don't know who should make the descision.

   Patrik

Date: Mon, 21 Apr 1997 13:42:14 -0700
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] re URN/NID
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>
Ron:

| >The nit:  drop "industry" as too limiting.  "Standards body" is sufficient.
| OK.
| >Although it's term needing definition in itself.
| True. Got a good one?

No, but in the spirit of things let me give you one off the top of my
head:  "an organization that publishes normative specifications 
that are recognized within its domain of interest as legitimate."

The key points there are "organization" (not just a couple guys
in a garage ...), "normative" (as opposed to merely descriptive,
such as recipes) and "legitimate" (which doesn't require that
they be in use to some specified degree and doesn't require that
there be no other specs or standards bodies in that domain).  Also,
saying "specifications" rather than "standards" avoids objections
to documents that don't explicitly claim to be standards.

I'm not wedded to any of those points, though.  Just something to
react against.

Regards, Terry

Date: Mon, 21 Apr 1997 14:13:33 -0600
To: Terry Allen <[email-masked]>, [email-masked]
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] re URN/NID
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 12:57 PM 4/21/97 -0700, Terry Allen wrote:
>Ron wrote:
>Agreed; I suggest that there may be some conflict among the rules
>given, and have a nit.

>|   3) Is "foo" the product of a international industry standards body such
>|      as the IEEE, SMPTE, etc.?
>|      (Augment "foo" with the organization name, such as urn:foo.ieee:1234)
>
>The nit:  drop "industry" as too limiting.  "Standards body" is sufficient.

OK.

>Although it's term needing definition in itself.

True. Got a good one?

>|   5) Is it a namespace established by a
>|      commercial organization for the use of any organization following
>|      normal business practices?

>Here's where you can get collisions.  What if ISO has a name space
>somewhere it calls DUNS?  (ISO wins because it's somehow more 
>something?  Fine by me, but the priority of rules and the rationale
>for them needs to be explicit.)

Right. The rules are to be evaluated in order, so if ISO has something
it calls "DUNS", Dunn & Bradstreet are out of luck.

The motivation for giving ISO what is clearly preferential treatment is
that ISO standards have the force of law in many countries, and ISO is
(at least supposed to be) very cognizent of the liability they bear
for their standards.

Lots of other standards organizations, either national or industry-specific,
have a relationship with ISO that leads to the eventually blessing of
the early standards.

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: Mon, 21 Apr 1997 12:57:14 -0700
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] re URN/NID
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Ron wrote:
| What I think we need to establish are the rules whereby IANA can say
| "you asked for 'foo' and you get it" or "you asked for 'foo' and you don't
| get it".

Agreed; I suggest that there may be some conflict among the rules
given, and have a nit.

| Here are my suggested rules:
| 
|   0) Select the desired NID. "foo" will be used as an example.
| 
|   3) Is "foo" the product of a international industry standards body such
|      as the IEEE, SMPTE, etc.?
|      (Augment "foo" with the organization name, such as urn:foo.ieee:1234)

The nit:  drop "industry" as too limiting.  "Standards body" is sufficient.
Although it's term needing definition in itself.  Is the W3C a standards
body?  last I looked they hadn't yet claimed to be.

|   5) Is it a namespace established by a
|      commercial organization for the use of any organization following
|      normal business practices?  (This is to allow namespaces such as
|      DUNS (30 million identified organizations), some of the Barcode
|      registries (each can accomodate a few 10s of thousands of companies),
|      etc. It is intended to disallow vanity namespaces. This may be
|      impossible.)
|      Is there a way for organizations to assign names in the system?
|      (For the case of DUNS, Dun & Bradstreet would like to identify
|      certain reports they sell. That's fine, but I see no need for the IETF
|      to standardize it. If however, companies can use their DUNS number
|      in conjunction with some information they specify themselves, we can
|      consider that.

Here's where you can get collisions.  What if ISO has a name space
somewhere it calls DUNS?  (ISO wins because it's somehow more 
something?  Fine by me, but the priority of rules and the rationale
for them needs to be explicit.)

| And what happens to jurisdictions when a country has a civil war and all
| sides claim to be the "true" owner of the ISO 2-letter county code? More
| to the point, trademarks are not unique even within one jurisdiction. A
| brick company, an electrical company, and a bakerey could all trademark
| the term "Acme" giving them rights to it for their product family. So,
| even a letter claiming to hold a trademark is not a guarantee of uniqueness.

I like "acme" as a NID ...

Regards,
  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
          T.A. at Passage Systems:  terry.allen[at]passage.com 

Date: Mon, 21 Apr 1997 10:32:51 -0600
To: "Dirk.vanGulik" <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] NID rambling
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 11:00 AM 4/14/97 +0200, Dirk.vanGulik wrote:
>Just to spark off discussion...

Sorry not to have responded earlier. Now for the sparks.  :-)

>1.	The registry resides in a country with
>	a sane legal system.

Care to define "sane"?

Dirk and I have had enjoyable chats about the legal systems of the US 
and the EC. However, this requirement is too hard to measure, and would not
preclude US courts getting involved. Also, since IANA is the body that has
served as the registrar of all assigned IDs for the Internet so far, I think
they need to keep the job. While the people at IANA might rather
enjoy moving to Monacco, we should probably assume they will remain in
California.

>2.	IANA _assigns_ NID's upon request; rather
>	than allow the requester to choose. IANA
>	'should' use a simple counter, a random
>	string, or simply time time in seconds
>	or something that the request arrives. IANA
>	'can' assign a name like ISO or ISBN if it
>	wants to.

What I think we need to establish are the rules whereby IANA can say
"you asked for 'foo' and you get it" or "you asked for 'foo' and you don't
get it".

Here are my suggested rules:

  0) Select the desired NID. "foo" will be used as an example.

  1) Is "foo" a registered URL scheme? If so, request denied.
     (We need to keep the URN NIDs and URL schemes disjoint to preclude
      future ambiguity).

  2) Is "foo" an acronym for a naming system standardized by ISO?
     (This rule requires that there be a search mechanism over existing ISO
      standards and current ISO committees to look for names).
     If not, go to question 3.
     If it is, does the requested use follow that standard?
     If not, request denied. (Deliberate conflict with ISO is stupid,
        since they are the law of the land in most countries).
     If it does follow ISO use, the name may be registered. (Adding
       the NID to any particular resolution system may require additional
       work, such as a demonstration that all vendors have an equitable
       chance at participating in the resolution system).
     If ISO has multiple naming systems with the same name, let them figure
       it out.

  3) Is "foo" the product of a international industry standards body such
     as the IEEE, SMPTE, etc.?
     (Augment "foo" with the organization name, such as urn:foo.ieee:1234)

  4) Is "foo" the product of a national industry standards body such as
     the NAM, NAB, EIA, etc., and is the use of names going to follow that
     standard?
     If so, augment the name with the name and locality of the standards
     body. (There are issues here of non-uniqueness of standards group IDs
     within a jurisdiction. NAB might be Natl. Assoc. of Broadcasters, or the
     Natl. Assoc. of Ballerinas. Not sure what to do there).

  5) Is it a namespace established by a
     commercial organization for the use of any organization following
     normal business practices?  (This is to allow namespaces such as
     DUNS (30 million identified organizations), some of the Barcode
     registries (each can accomodate a few 10s of thousands of companies),
     etc. It is intended to disallow vanity namespaces. This may be
     impossible.)
     Is there a way for organizations to assign names in the system?
     (For the case of DUNS, Dun & Bradstreet would like to identify
     certain reports they sell. That's fine, but I see no need for the IETF
     to standardize it. If however, companies can use their DUNS number
     in conjunction with some information they specify themselves, we can
     consider that.

>Soap:	I do insist that globally accepted names do
>	NOT exist; no matter what companies claim. Check
>	out the former East Germany, or NATO/OTAN. ISO/OSI
>	etc, for examples. 

Sorry, Dirk. You are trying to prove a negative. Can't be done.

>3.	sub 2. A company can reject a name assigned by
>	IANA, and resubmit. There is a small fee to be
>	paid if you reject.

Being able to say "no, I am not going to use the NID you have sent me" is
useful functionality. I think we leave questions of procing policy to IANA.

>4.	Submiters pick their own name, and provide a
>	legal letter saying that that name is theirs in
>	a certain juristdiction. The NID is postfixed
>	by '/'.jurisdiction; i.e. ISO/CH or SHELL/NL.
>
>	This implies that any claims can be settled by
>	civil court between claimants within that 
>	jurisdiction.

And what happens to jurisdictions when a country has a civil war and all
sides claim to be the "true" owner of the ISO 2-letter county code? More
to the point, trademarks are not unique even within one jurisdiction. A
brick company, an electrical company, and a bakerey could all trademark
the term "Acme" giving them rights to it for their product family. So,
even a letter claiming to hold a trademark is not a guarantee of uniqueness.

I think this is actually a pretty good suggestion for how to deal with
vanity name requests, although it will need some more detail. I also
think that there are some names, such as ISBN, that are not vanity names
but are indicative of existing international standards. I would *really*
like to make sure that the rules for operating the registry will allow
those to be treated as simply as possible. I don't really want to see
urn:isbn/iso/ch:1-234-5678-9, for several reasons.

>	If a company claims to have a name in more than
>	one jurisdiction it MUST supply the credentials
>	for _EACH_ jurisdiction; but will only get the 
>	name in ONE. However in the other jurisdictions
>	the claim prevails.

Right. I'd augment this with a procedure where IANA notifies the holder
of a name in one jurisdiction when someone tries to register it in
another jurisdiction.

>5.	Use OIDs

I would like to see OIDs as a namespace, such as
   urn:oid:1.2.3.4.5.6.29.2.1002
Using OIDs as the NID essentially restricts URNs to being isomorphic to the
OID namespace, which seems too restrictive to me. 

Later,

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: Wed, 16 Apr 1997 13:12:08 -0700
To: [email-masked]
From: Cecilia Preston <[email-masked]>
Subject: [URN] Bibliographic URN's
Sender: [email-masked]
Reply-To: Cecilia Preston <[email-masked]>

At the meeting in Memphis, we decided to put this out to the list again
this time being very carefull that the text be in plain old ASCII.  It
seems what looked just fine to me as I composed the message, didn't
always come out that

way.  Networks....

The file says this is text only.  If anyone has any problems reading
this let me know and we will work something out.

--Cecilia

<fontfamily><param>Times</param><bigger><bigger>

Internet Draft                                Clifford Lynch

draft-ietf-urn-biblio-00.txt        University of California

22 March 1997                                Cecilia Preston

Expires in six months                        Preston & Lynch

                                              Ron Daniel Jr.

                              Los Alamos National Laboratory

          Using Existing Bibliographic Identifiers

                             as 

                   Uniform Resource Names

Status of this Document

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 made obsolete by 

other documents at any time.  It is inappropriate to use 

Internet-Drafts as reference material or to cite them other 

than as works in progress. 

Distribution of this document is unlimited.  Please send 

comments to [email-masked] and [email-masked].

This document does not specify a standard; it is purely 

informational.

0. Abstract

A system for Uniform Resource Names (URNs) must be capable

of supporting identifiers from existing widely-used naming 

systems.  This document discusses how three major 

bibliographic identifiers (the ISBN, ISSN and SICI) can be 

supported within the URN framework and the currently 

proposed syntax for URNs.

                                                    [Page 1]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

1. Introduction

The ongoing work of several IETF working groups, most 

recently in the Uniform Resource Names working group, has 

culminated the development of a syntax for Uniform Resource 

Names (URNs).   The functional requirements and overall 

framework for Uniform Resource Names are specified in RFC 

1737 [Sollins & Masinter] and the current proposal for the 

URN syntax is draft-ietf-urn-syntax-04.txt [Moats].

As part of the validation process for the development of 

URNs the IETF working group has agreed that it is important 

to demonstrate that the current URN syntax proposal can 

accommodate[RD1] existing identifiers from well managed 

namespaces.  One such well-established infrastructure for 

assigning and managing names comes from the bibliographic 

community.  Bibliographic identifiers function as names for 

objects that exist both in print and, increasingly, in 

electronic formats.  This Internet draft demonstrates the 

feasibility of supporting three representative bibliographic 

identifiers within the currently proposed URN framework and 

syntax.

Note that this document does not purport to define the 

"official" standard way of doing so; it merely demonstrates 

feasibility.  It has not been developed in consultation with 

the standards bodies and maintenance agencies that oversee 

the existing bibliographic identifiers.  Any actual Internet 

standard for encoding these bibliographic identifiers as 

URNs will need to be developed in consultation with the 

responsible standards bodies and maintenance agencies.

In addition, there are several open questions with regard to 

the management and registry of Namespace Identifiers (NIDs) 

for URNs.  For purposes of illustration, we have used the 

three NIDs "ISBN", "ISSN" and "SICI" for the three 

corresponding bibliographic identifiers discussed in this 

document.  While we believe this to be the most appropriate 

choice, it is not the only one.  The NIDs could be based on 

the standards body and standard number (e.g. "US-ANSI-NISO-

Z39.56-1997" rather than "SICI").  Alternatively, one could 

lump all bibliographic identifiers into a single 

"BIBLIOGRAPHIC" name space, and structure the namespace-

                                                   [Page 2]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

specific string to specify which identifier is being used.

We do not believe that these are advantageous approaches, 

but must wait for the outcome of namespace management 

discussions in the working group. 

For the purposes of this document, we have selected three 

major bibliographic identifiers (national and international) 

to fit within the URN framework.  These are the 

International Standard Book Number (ISBN) [ISO1], the 

International Standard Serials Number (ISSN) [NISO1,ISO2, 

ISO3], and the Serial Item and Contribution Identifier 

(SICI) [NISO2].  ISBNs are used to identify monographs 

(books).  ISSNs are used to identify serial publications 

(journals, newspapers) as a whole.  SICIs augment the ISSN 

in order to identify individual issues of serial 

publications, or components within those issues (such as an 

individual article, or the table of contents of a given 

issue).  The ISBN and ISSN are defined in the United States 

by standards issued by the National Information Standards 

Organization (NISO) and also by parallel international 

standards issued under the auspices of the International 

Organization for Standardization (ISO).  NISO is the ANSI-

accredited standards body serving libraries, publishers and 

information services.  The SICI code is defined by a NISO 

document in the United States and does not have a parallel 

international standards document at present. 

Many other bibliographic identifiers are in common use (for 

example, the CODEN, numbers assigned by major bibliographic 

utilities such as OCLC and RLG, national library numbers 

such as the Library of Congress Control Number) or are under 

development.  While we do not discuss them in this document, 

many of these will also need to be supported within the URN 

framework as it moves to large scale implementation.  The 

issues involved in supporting those additional identifiers 

are anticipated to be broadly similar to those involved in 

supporting ISBNs, ISSNs, and SICIs.

2. Identification vs. Resolution

It is important to distinguish between the resource 

identified by a URN and the resources that can reasonably be 

provided when attempting to resolve an identifier.  For

                                                    [Page 3]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

example, the ISSN 0040-781X identifies the popular

"Time".  All of it, every issue for from the start of 

publication to present.  Resolving such an identifier should 

not result in the equivalent of hundreds of thousands of 

pages of text and photos being dumped to the user's machine.

It is more reasonable for ISSNs to resolve to a navigational 

system, such as an HTML-based search form, so the user may 

select issues or articles of interest.  ISBNs and SICIs, on

the other hand, do identify finite, manageably-sized 

objects, but they may still be large enough that resolution 

to a hierarchical system is appropriate.  

In addition, the materials identified by an ISSN, ISBN or 

SICI may exist only in printed or other physical form, not 

electronically.  The best that a resolver may be able to 

offer is information about where to get the physical 

resource, such as library holdings or a bookstore or 

publisher order form.  The URN Framework provides resolution 

services that may be used to describe any differences 

between the resource identified by a URN and the resource 

that would be returned as a result of resolving that URN.

3. International Standard Book Numbers

3.1 Overview

An International Standard Book Number (ISBN) identifies an 

edition of a monographic work.  The ISBN is defined by the 

standard NISO/ANSI/ISO 2108:1992 [ISO 1]

Basically, an ISBN is a ten-digit number (actually, the last 

digit can be the letter "X" as well, as described below) 

which is divided into four variable length parts usually 

separated by hyphens when printed.  The parts are as follows 

(in this order): 

* a group identifier which specifies a group of publishers, 

based on national, geographic or some other criteria,

* the publisher identifier,

                                                   [Page 4]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

* the title identifier,

* and a modulus 11 check digit[RD2], using X in lieu of 10.

The group and publisher number assignments are managed in 

such a way that the hyphens are not needed to parse the ISBN 

unambiguously into its constituent parts.  However, the ISBN 

is normally transmitted and displayed with hyphens to make 

it easy for human beings to recognize these parts without 

having to make reference to or have knowledge of the number 

assignments for group and publisher identifiers.

3.2 Encoding Considerations

Embedding ISBNs within the URN framework presents no 

particular coding problems, since all of the characters that 

can appear in an ISBN are valid in the identifier segment of 

the URN.  %-encoding is never needed.

Example: URN:ISBN:0-395-36341-1

For the ISBN namespace, some additional equivalence rules 

are appropriate.  Prior to comparing two ISBN URNs for 

equivalence, it is appropriate to remove all hyphens, and to 

convert any occurrences of the letter X to upper case.

3.3 Additional considerations

The ISBN standard and related community implementation 

guidelines define when different versions of a work should 

be assigned the same or differing ISBNs.  In actuality, 

however, practice varies somewhat depending on publisher as 

to whether different ISBNs are assigned for paperbound vs. 

hardbound versions of the same work, electronic vs. printed 

versions of the same work, or versions of the same work 

published for example in the US and in Europe.  The choice 

of whether to assign a new ISBN or to reuse an existing one 

when publishing a revised printing of an existing edition of 

a work or even a revised edition of a work is somewhat

subjective.  Practice varies from publisher to publisher 

(indeed, the distinction between a revised printing and a 

new edition is itself somewhat subjective).  The use of 

                                                    [Page 5]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

ISBNs within the URN framework simply reflects these 

existing practices.  Note that it is likely that an ISBN URN 

will often resolve to many instances of the work (many 

URLs).

4. International Standard Serials Numbers

4.1 Overview

International Standard Serials Numbers (ISSN) identify a 

work that is being published on a continued basis in issues; 

they identify the entire (often open-ended, in the case of 

an actively published) work.  ISSNs are defined by the 

standards ISO 3297:1986 [ISO 2] and ISO/DIS 3297 [ISO 3] and 

within the United States by NISO Z39.9-1992 [NISO 1].  The 

ISSN International Centre is located in Paris and 

coordinates a network of regional centers.  The National 

Serials Data Program within the Library of Congress is the 

US Center of this network.

ISSNs have the form NNNN-NNNN where N is a digit, the last 

digit may be an upper case X as the result of the check 

character calculation.  Unlike the ISBN the ISSN components 

do not have much structure; blocks of numbers are passed out 

to the regional centers and publishers.

4.2 Encoding Considerations

Again, there is no problem representing ISSNs in the 

namespace-specific string of URNs since all characters valid 

in the ISSN are valid in the namespace-specific URN string, 

and %-encoding is never required. 

Example: URN:ISSN:1046-8188

Supplementary comparison rules are also appropriate for the 

ISSN namespace.  Just as for ISBNs, hyphens should be 

dropped prior to comparison and occurrences of 'x' 

normalized to uppercase.

                                                    [Page 6]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

4.3 Additional Considerations

The ISSN standard and related community implementation 

guidelines specify when new ISSNs should be assigned vs. 

continuing to use an existing one.  There are some 

publications where practice within the bibliographic 

community varies from site to site, such as annuals or 

annual conference proceedings.  In some cases these are 

treated as serials and ISSNs are used, and in some cases 

they are treated as monographs and ISBNs are used.  For 

example SIGMOD Record volume 24 number 2 June 1995 contains 

the Proceedings of the 1995 ACM SIGMOD International 

Conference on Management of Data.  If you subscribe to the 

journal (ISSN 0163-5808) this is simply the June issue.  On 

the other hand you may have acquired this volume as the 

conference proceedings (a monograph) and as such would use 

the ISBN 0-89791-731-6 to identify the work.  There are also 

varying practices within the publishing community as to when 

new ISSNs are assigned due to the change in the name of a 

periodical (Atlantic becomes Atlantic Monthly); or when a 

periodical is published both in printed and electronic 

versions (The New York Times).  The use of ISSNs as URNs 

will reflect these judgments and practices.

5. Serial Item and Contribution Identifiers

5.1 Overview

The standard for Serial Item and Contribution Identifiers 

(SICI) has recently been extensively revised and is defined 

by NISO/ANSI Z39.56-1997 [NISO 2].  The maintenance agency 

for the SICI code is the UnCover Corporation.

SICI codes can be used to identify an issue of a serial, or 

a specific contribution (i.e., an article, or the table of 

contents) within an issue of a serial.  SICI codes are not 

assigned, they are constructed based on information about 

the issue or issue component in question.

The complete syntax for the SICI code will not be discussed 

here; see NISO/ANSI Z39.56-1997 for details.  However an 

example and brief review of the major components is needed

                                                    [Page 7]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

to understand the relationship with the ISSN and how this 

identifier differs.  An example of a SICI code is:

0015-6914(19960101)157:1<<62:KTSW>2.0.TX;2-F

The first nine characters are the ISSN identifying the 

serial title.  The second component, in parentheses, is the 

chronology information giving the date the particular serial 

issue was published.  In this example that date was January 

1, 1996.  The third component, 157:1, is enumeration 

information (volume, number) on the particular issue of the 

serial.  These three components comprise the "item segment" 

of a SICI code.  By augmenting the ISSN with the chronology 

and/or enumeration information, specific issues of the 

serial can be identified.  The next segment, <<62:KTSW>, 

identifies a particular contribution within the issue.  In 

this example we provide the starting page number and a title 

code constructed from the initial characters of the title. 

Identifiers assigned to a contribution can be used in the 

contribution segment if page numbers are inappropriate.  The 

rest of the identifier is the control segment, which 

includes a check character.  Interested readers are 

encouraged to consult the standard for an explanation of the 

fields in that segment.

5.2 Encoding Considerations

The character set for SICIs is intended to be email-

transport-transparent, so it does not present major 

problems.  However, all printable excluded and reserved 

characters from the URN syntax draft are valid in the SICI 

character set and must be %-encoded.

Example of a SICI for an issue of a journal

     URN:SICI:1046-8188(199501)13:1%3C%3E1.0.TX;2-F

For an article contained within that issue

     URN:SICI:1046-8188(199501)13:1%3C69:FTTHBI%3E2.0.TX;2-4

                                                    [Page 8]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

Special equivalence rules for SICIs are not appropriate for 

definition as part of the namespace and incorporation in 

areas such as cache management algorithms.  These are best 

left to resolver systems which try to determine if two SICIs 

refer to the same content.  Consequently, we do not propose 

any specific rules for equivalence testing through lexical 

manipulation.

5.3 Additional Considerations

Since the serial is identified by an ISSN, some of the 

ambiguity currently found in the assignment of ISSNs carries 

over into SICI codes.  In cases where an ISSN may refer to a 

serial that exists in multiple formats, the SICI contains a 

qualifier that specifies the format type (for example, 

print, microform, or electronic).  SICI codes may be 

constructed from a variety of sources (the actual issue of 

the  serial, a citation or a record from an abstracting 

service) and, as such are based on the principle of using 

all available information, so there may be multiple SICI 

codes representing the same article [NISO2, Appenidx D].  

For example, one code might be constructed with access to 

both chronology and enumeration (that is, date of issue and 

volume, issue and page number), another code might be 

constructed based only on enumeration information and 

without benefit of chronology.  Systems that use SICI codes 

employ complex matching algorithms to try to match SICI 

codes constructed from incomplete information to SICI codes 

constructed with the benefit of all relevant information.

6. Security Considerations

This document proposes means of encoding several existing 

bibliographic identifiers within the URN framework.  It does 

not discuss resolution; thus questions of secure or 

authenticated resolution mechanisms are out of scope.  It 

does not address means of validating the integrity or 

authenticating the source or provenance of URNs that contain 

bibliographic identifiers.  Issues regarding intellectual 

property rights associated with objects identified by the

various bibliographic identifiers are also beyond the scope 

of this document, as are questions about rights to the 

databases that might be used to construct resolvers.

                                                    [Page 9]

INTERNET DRAFT:Bibliographic Identifiers as URNs     3/1997

7. References

[ISO1] NISO/ANSI/ISO 2108:1992 Information and documentation 

       -- International standard book number (ISBN)

[ISO2] ISO 3297:1986 Documentation -- International standard 

       serial numbering (ISSN)

[ISO3] ISO/DIS 3297 Information and documentation -- 

       International standard serial numbering (ISSN) 

       (Revision of ISO 3297:1986)

[Moats] R. Moats, "URN Syntax" draft-ietf-urn-syntax-

       04.text. March 1997

[NISO 1] NISO/ANSI Z39.9-1992 International standard serial

       numbering (ISSN)

[NISO 2] NISO/ANSI Z39.56-1997 Serial Item and Contribution

       Identifier

[Sollins & Masinter] K. Sollins and L. Masinter, "Functional

       Requirements for Uniform Resource Names", RFC 1737 

       December 1994.

8. Author's Addresses

Clifford Lynch

University of California Office of the President

300 Lakeside Drive, 8th floor

Oakland CA 94612-3550

[email-masked]

Cecilia Preston

Preston & Lynch

PO Box 8310

Emeryville, CA 94662

[email-masked]

Ron Daniel Jr.

Advanced Computing Lab, MS B287

Los Alamos National Laboratory

Los Alamos, NM, 87545

voice: +1 505 665 0597

fax: +1 505 665 4939

http://www.acl.lanl.gov/~rdaniel

                                                   [Page 10]

</bigger></bigger></fontfamily>

Date: Tue, 15 Apr 1997 14:49:16 -0400 (EDT)
From: [email-masked]
To: [email-masked]
Subject: [URN] Re: urns and mailing lists
Sender: [email-masked]
Reply-To: [email-masked]

I would like to receive mail about URN work.  Thanks.

Date: Tue, 15 Apr 1997 11:50:14 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] Revised WG Milestones
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

As is noted from the minutes, a revision to the WG's timeline was discussed
in Memphis.  The Area Directors have requested an updated list of milestones
for each active group, indicating what _has_ been done, and (realistic)
dates for what remains.

The minutes contain the revision that was proposed and seemed reasonable
at the meeting.  I attach here a slightly revised version to get group
sign-off before submitting them to the ADs.  By the way, the only differences
between this version and the one presented at the meeting are:

	. the resolution services and grandfathered namespace documents
	  are expected to be sent to the IESG earlier (there doesn't seem
	  too much contntion over the current versions; should be just
	  a case of minimal edits and then WG last call).

	. I've put in another round of edits/discussion on the 
	  Framework/Requirements/Guidelines document, since it seemed
	  to be agreed that there were a few more issues to include
	  before it was ready (Karen, do correct me if I am wrong!).

URN Working Group Revised Goals and Milestones

(Note:  this includes one document that was not originally on the slate:
the namespace requirements document.  In part, this is something
that naturally split out of the Framework document (which has become
the Guidelines document) -- it is not new work, just a split of a
document.)

[DONE] Oct 96
     Submit revision of URN Framework document as Internet-Draft.
[DONE] Oct 96
     Submit revised version of the NAPTR proposal as an Internet-Draft.
[DONE] Oct 96
     Submit Syntax document as an Internet-Draft.
[DONE] Oct 96
     Submit document detailing the N2L/N2R/etc resolution results as an
     Internet-Draft.
[DONE] Dec 96
     Submit paper outlining grandfathering one namespace into the framework
     as an Internet-Draft.
[DONE] Dec 96
     Submit NAPTR proposal to IESG as Experimental RFC. 
[DONE] Dec 96
     Submit syntax paper to IESG for publication as an RFC.
May 97
     Submit revised grandfather namespace document as Internet-Draft.
May 97
     Submit revised N2L/N2R/etc document as an Internet-Draft.
May 97
     Submit revised namespace requirements document as an Internet-Draft.
May 97
     Submit document describing one (new) namespace as an Internet-Draft.
May 97
     Submit revision of URN Guidelines document as Internet-Draft.
Jun 97
     Submit N2L/N2R/etc document to IESG for publication as RFC.
Jun 97
     Submit grandfathered namespace paper to IESG for publication as RFC.
Jul 97
     Submit Framework (Guidelines) document to IESG for publication as an RFC. 
Jul 97
     Submit revised new Namespace document as Internet-Draft.
Aug 97
     Submit new namespace proposal to IESG for publication as RFC.

If this seems about right, I will send it off at the end of the week.

Leslie.

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

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

Date: Tue, 15 Apr 1997 11:45:19 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] DRAFT minutes from Memphis
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

--1375770936-1966019686-861119119=:20883
Content-Type: TEXT/PLAIN; charset=US-ASCII

Once again, thanks very much to Sally for her efforts with the minutes!

Attached is a draft rendition of the minutes (Sally's + a few additions
of mine).  If anyone who was at the meeting spots any inconsistencies
or omissions, please signal them to me this week and I will make the changes.

Barring any serious contention over the content, I will send these
off to the minutes-minder at the end of the week.

Thanks!
Leslie.

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

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

--1375770936-1966019686-861119119=:20883
Content-Type: TEXT/plain; name="memphis.minutes.txt"
Content-Transfer-Encoding: BASE64
Content-ID: <[email-masked]>
Content-Description: draft URN WG meeting minutes

--1375770936-1966019686-861119119=:20883--

Date: Tue, 15 Apr 1997 15:54:39 +0200
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked]
Subject: [URN] Glossary, rough cut
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

All credits go to Ron, for providing this start. Any additional
typo's and mistakes are mine. I also went over all our current drafts
with a college; and added the words she spotted as not obvious
as to their meaning.

I am not sure how far this document should go; I feel it should
not muddle the waters of the framework document by re-defining
some of its terms.

Depending on how many updates are posted; I will either re-post
the edited version once a week or once a month. Either send
updates to me directly; or to the list, or even both. 

If you like web/mail interfaces; at 

	http:/www.ceo.org/urn/show.pl

you should be able to find the latest CVS version. There is
a hacked update form. But mail will do just fine.

Thanks

Dw.

----

                        URN Glossary

Introduction

The Uniform Resource Names (URN) working group of the Internet Engineering
Task Force is specifying a framework for URNs and first implementations
of the components of the framework. A particular vocabulary has been
developed during that effort, but the vocabulary has not been codified
and used uniformly in all the draft documents of that working group.
This document's purpose is to define the terms used in the URN-WG
documents. We do this in two ways. The next section is a paragraph
that briefly describes the efforts of the URN-WG, and uses all the
terms. The second section is a glossary listing the terms in alphabetical
order and providing definitions for them.	(Ron's)

Terms In Context:
  
The URN Framework is based on two dichotomies. The first is a separation
of namespaces and resolution mechanisms. Since we expect resolution
mechanisms to evolve over time, they must be capable of resolving
identifiers that do not contain resolution-system specific hints. The
second dichotomy is a distinction between resolvers and resolver
discovery services. Resolvers are the systems that contain a database of
URNs and things to which they may resolve. Resolvers offer certain
resolution services, such as mapping a URN to the location of the
resource. When clients communicate with a resolver to obtain one of
those services, they do so using a particular resolution protocol. We
expect that resolution services and protocols will change over time. We
also expect that the location of resolvers will change over time.
Therefore we need a way to discover the location of resolvers and
determine the protocols and services they offer. That is the role of
resolver discovery services. (Ron's)
 
Glossary
========

Absolute/Relative/Path URNs

Local Resolver, Fallback Resolver
    (Karen uses "local resolver" to mean "resolver". I use it to refer
    to resolvers that are close to the client and are contacted early.
    If the local resolver can't answer the query, then a fallback resover is
    used.)

Must/Shall 
     Software that does not behave in the manner that this
     document says it must is not conformant to this document.

NAPTR

NID
    Name space identifier; which uniquely places a URN in single namespace.

Name Delegation

Namespace
    A space of identifiers governed by a common set of rules on syntax
    and semantics.

RCDS
     Resource Cataloging and Distribution Service. A UDP based protocol

RFC1713

Resolution Mechanism
    The mechanism used to resolve a URI into a resource or another URI.

Resolution Protocol
    The protocol used for a client to communicate with a resolver. Some
    resolvers may offer multiple protocols.    

Resolution Service
    A service offered by a resolver. Example services are mapping an
    identifier to metadata for the resource, mapping an identifier to
    a set of aliases, or mapping the identifier to the resource it
    denotes. The resolution services that a resolver may offer are
    determined by the schema of the resolver database.

    Example Resolution Services
            N2L  - Given a URN, return a URL
            N2Ls - Given a URN, return a set of URLs
            N2R  - Given a URN, return an instance of the resource.
            N2Rs - Given a URN, return multiple instances of the resouce,
                   typically encoded using multipart/alternative.
            N2C  - Given a URN, return a collection of meta-information on
                   the named resource. The format of this response is the
                   subject of another document.
            L2R  - Given a URL, return the resource.
            L2C  - Given a URL, return a description of the resource.

Resolver
    A server which offers a Resolution Service. To this purpose it 
    might contain, or be tightly integrated with, a database of 
    URIs, their mapping and associated information. 

Resolver Discovery Service (RDS):
    A method for discovering resolvers. 

Resource

SRV

Should
     Software that does not follow the behavior that this document
     says it should may still be conformant, but is probably broken
     in some fundamental way.

URC
     Universal Resource Characteristics, essentially Metadata in a
     TBD format, such as the dublin core.

URI
    Uniform Resource Identifiers are the superclass of URNs and URLs.

URN
    Uniform Resource Names are persistent, location-independent identifiers
    for network-accessible resources.

Vanity Names

Acknowledgements:
=================

The author would like to thank Ron Daniel for most of the entries
in this list. 

References:
===========

[1] RFC-1737 "Functional Requirements for Uniform Resource Names", Karen
    Sollins and Larry Masinter, Dec. 1994.

[2] draft-daigle-urn-framework-??.txt "A Uniform Resource Naming
    Framework", Leslie Daigle and Patrik Faltstrom, June, 1996.

Security Considerations
=======================

Security was pondered upon, and is considered not to be an issue
for a glossary.

Author Contact Information:
===========================

Dirk-Willem van Gulik / [email-masked]

http://www.ceo.org/urn/gloss.html

From: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Date: Fri, 11 Apr 97 10:12:21 
Priority: Normal
Subject: [URN] Announcement of a test URN namespace/resolver
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Folks-

[Oops, forgot to do this either Thursday or Friday, so here it is now...]

I introduced in Memphis (and am now announcing here) the availability of a test URN namespace.

The namespace is "ietf" and the resolver can handle URNs that name rfc, std, and fyi documents.
The resolver is based on using HTTP and supports the following resolution "commands": N2C, N2L, N2Ls,
N2R, N2Rs, and (after the URN meeting for those who have read the minutes) N2Ns.

For more information on the syntax and how to connect to the resolver, see
http://dsm0.ds.internic.net/urn.

A note of information: dsm0.ds.internic.net is our test server, so it will not exhibit the availability characteristics
of our other servers.  Apologies in advance, and please be patient if the server is unavailable.

Ryan

Date: Mon, 14 Apr 1997 11:10:58 +0200
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked]
Subject: [URN] More...
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

Procedure for NID/Jurisdiction...

1.	Claimant requests NID within one or
	more jurisdictions. Claimant MAY specify
	prime jurisdiction.

2.	IANA verifies wether any of the NID/Jurisdictions
	are in use. If _ANY_ are in use; the request is
	rejected and the claimant is to solve that first.

3.	IANA publishes the claim for 60 days. 
	(if there are any 'protest' hear, iana
	ignores these; as they are to be settled between claimant
	and protester).

4.	IANA assigns NID in prime jurisdiction; if the claimant
	asked for a prime.

5.	IANA blocks NID in all other jurisdictions.

This does not solve all; in particular, jursidictions have
a tendency to come and disapper; like contries do; or just
to change their local law. Meaning that names can be challenged
at any moment. Thus;

6.	NID owners are to show proof of ownership within
	the jurisdictions upon request; with a maximum
	of once every 6 month if asked by IANA. Failure
	to produce proof in the prime jurisdiction implies
	removal of ALL claims and a redo-from-start. Failure
	in any of the other jurisdictions simply implies
	removal.

7.	NID owners can add any time. 

8.	NID owners can remove claims at any time.

Thus entities can actually freeze out NID's without really
using them; without clogging up the actual prime NID space.

Plus, entities cannot easily claim zillions of equal name,
say 'personal-computer/[nl|us|it|at|de|uk]' but are limited
to just one prime. 

Hope this does not sound toooo insane.

Dw.

Date: Mon, 14 Apr 1997 11:00:20 +0200
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked]
Subject: [URN] NID rambling
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

Just to spark off discussion... some NID
scheme's and possible solutions...

1.	The registry resides in a country with
	a sane legal system.

2.	IANA _assigns_ NID's upon request; rather
	than allow the requester to choose. IANA
	'should' use a simple counter, a random
	string, or simply time time in seconds
	or something that the request arrives. IANA
	'can' assign a name like ISO or ISBN if it
	wants to.

Soap:	I do insist that globally accepted names do
	NOT exist; no matter what companies claim. Check
	out the former East Germany, or NATO/OTAN. ISO/OSI
	etc, for examples. 

3.	sub 2. A company can reject a name assigned by
	IANA, and resubmit. There is a small fee to be
	paid if you reject.

4.	Submiters pick their own name, and provide a
	legal letter saying that that name is theirs in
	a certain juristdiction. The NID is postfixed
	by '/'.jurisdiction; i.e. ISO/CH or SHELL/NL.

	This implies that any claims can be settled by
	civil court between claimants within that 
	jurisdiction.

	If a company claims to have a name in more than
	one jurisdiction it MUST supply the credentials
	for _EACH_ jurisdiction; but will only get the 
	name in ONE. However in the other jurisdictions
	the claim prevails.

5.	Use OIDs

Dw.

To: [email-masked]
Path: usenet
From: Dan Connolly <[email-masked]>
Newsgroups: w3c.urn
Subject: Re: [URN] Re URN question #2
Date: Fri, 04 Apr 1997 00:52:42 -0600
Organization: World Wide Web Consortium
Lines: 19
Nntp-Posting-Host: beach.w3.org
To: Terry Allen <[email-masked]>
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

Terry Allen wrote:
> 
> My preference would be to omit all discussion of hints.  We will
> find a place for them when we get to URCs; we might do well not to
> complicate the URN documents with them now.
> 
> I am not opposed to hinting systems, but as we don't have them
> deployed yet we can afford to leave this issue to the future.

Hmmm... I consider PICS a URC/hint/metadata system. It's
not ubiquitous, but deployment increases daily...

http://www.w3.org/PICS

-- 
Dan Connolly, W3C Architecture Domain Lead
<[email-masked]> +1 512 310-2971
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21

Date: Thu, 3 Apr 1997 12:45:09 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: [email-masked]
Subject: Clarification [Was Re: [URN] Enough.]
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Dan Laliberte quite rightly pointed out that I did not make clear _which_
thread I was referring to.

"Thread" was perhaps the wrong word -- discussion or space might have been
more accurate.

In terms of threads, I was specifically referring to:

	. the "URN:" discussion

	. hierarchies/relative URNs

The latter was previously put off because it was not at all clear that
it was within our mandate, _and_ in deference to having more concrete
documents describing what _is_ within our mandate.  As we have those now,
I'm asking that we focus on getting _them_ sorted out and agreed on before
deciding to tackle new issues.

And, to reiterate the very good point Larry Masinter brought up (in 
reference to whether or not using the hierarchy of ISBNs to refer to
document segments makes sense in the ISBN world):  a lot of this is
name-space dependent, and cannot be discussed without understanding
what the full range of name-spaces is.  It is _not_ about what can be "done"
with URNs.

Leslie.

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

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

Date: Thu, 3 Apr 1997 11:53:19 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] Enough.
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Okay, this thread has now wandered too far into regions that have already
had significant list bandwidth before, and no one is saying anything they
haven't said before.

Given that this is a) wandering out of the space for which we were chartered, 
b) not reaching resolution and c) not about any of the drafts that have 
recently been published, I call this thread to an _end_.

We _do_ have several fine drafts that will be discussed next week in Memphis.
We had some important points brought up last week, but for those who will not 
be able to attend, and in the interest of getting as much done in advance as 
possible, can we have some further discussion about the relative 
strengths/shortcomings of the individual drafts  in the light of the purpose 
for which they were created?

Thanks!
Leslie.

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

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

Date: Wed, 2 Apr 1997 17:51:42 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: Re: [URN] Visible hierarchy, check chars, resolution 
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Re Larry's mail, which I just lost but can still remember (it's been
a truly awful week), if you want a finer degree of URN than that
provided by the grandfathered source, you just assign a new set
of URNs, one for the collection and one for each piece.

If you want to service queries for arbitrary pieces of hierarchy
within a URN, well, I think that's best done by a compound request
(the URN plus the query info).

Re ISBNs, it would be an abuse of their semantics to assign ISBNs
to chapters (at least outside of an anthology), I think.  Another
reason to stop using ISBNs as examples in URN discussions.  The
point could presumably be made with some other name space as
example.

Regards, Terry (at least temporarily connected again)

  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html
           at Passage Systems:  terry.allen[at]passage.com 

Date: Wed, 2 Apr 1997 16:57:09 PST
From: Larry Masinter <[email-masked]>
Organization: PARC
To: Daniel LaLiberte <[email-masked]>
Cc: Dan Connolly <[email-masked]>, "Ron Daniel, Jr." <[email-masked]>, [email-masked]
Subject: Re: [URN] Visible hierarchy, check chars, resolution
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

The place where URNs might actually have relative links is
if you want a URN at a finer granularity of element than the
grandfathered naming system. If the URN for a book is its
ISBN number, what is the URN of chapter 1? Must you use a new
"scheme", or could there perhaps be a default composition
rule:
    isbn:1-12-154212/chapter1/paragraph2
or even some more principled linearization of hytime.

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

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 2 Apr 1997 16:25:19 -0600 (CST)
To: "Ryan Moats" <[email-masked]>
Cc: "Daniel LaLiberte" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] urn: prefix is a brand name?
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ryan Moats writes:
 > On Wed, 2 Apr 1997 13:57:00 -0600 (CST), Daniel LaLiberte wrote:
 > >So that's how it happened.  The previous time I had checked the
 > >syntax, the "urn:" was still optional, as I recall.  I don't recall
 > >any explicit statement to the mailing list that "we are now going to
 > >make 'urn:' required - any comments?".  Oh well, you wanted a brand
 > >name to protect, so you got it.
 > 
 > In fact, I take umbrage at the implication of the first sentence, because
 > that is NOT "how it happened".

I meant that's how it slipped past me.  But I apologize for my
unintended slur.

 >  As to the explicit statement about the "urn:" becoming required,
 > there was one and it is in the archives.

My mistake.  I missed it.

But nevertheless, I argue the concepts, not the letter of the specs.
If I can't convince people at the level of concepts, there is no point
arguing the specs.  I would make a very intolerant lawyer.

 > >E.g. web clients do, in fact, use things besides HTTP in resolving
 > >http URLs.  They are not prohibited from doing so.  It doesn't help
 > >to deny this.
 > 
 > I assume that you are stating that they do something other
 > than do a DNS lookup of the name and connect with HTTP.

Actually, DNS lookup is part of it, and that should be a hint of
other things.  But browsers do much more.  I listed several things in
an earlier longer message.  Here is what I wrote in summarizing it:

------

Here is an abbreviated version of my list of possible ways to discover the
semantics of a URI.  Only item 4 is possibly non-compliant.  The rest
are actually done and in compliance as far as I know.

1. Look up the URI in an in-memory cache.  

2. Look up the URI in local or remote cache services. 

3. Look up the URI in a local table that maps a prefix of the URI to
   some protocol or process. 

4. If the URI has a DNS component, lookup the domain name for a
   protocol/service mapping.
   
5. Ask the named service (discovered by any of the above) to resolve the
   URI and learn that some other service or protocol should be used.

6. Get a redirection to another URI or a collection of alternative URIs.

------

A few additional notes.  Item 4 is compliant too.  Anything is.  It's
just not done as far as I know.  Note this is not just looking up the
IP number for the domain name in a URI - this is asking DNS for a
reference to a protocol or service that should be used to resolve the
URI.  Item 3 might look up the resource in a local file system or via
nfs or afs if a prefix of the URI is recognized.

 > If so, I have a hard time reconciling this with RFC 1738, which
 > states that "The <tag> URL scheme is used to designate Internet
 > resources accessible using the <tag> protocol", where
 > <tag> is FTP, Gopher, HTTP.

Read that carefully.  The resources are "accessible using the <tag>
protocol".  "Accessible" doesn't mean you must use only that protocol
- it means you *can* use it.  But, in fact, it is a lie if the
resource is no longer there.

 > As an extension, if a browser isn't following this, then why can't it
 > be claimed that that browser is not supporting the proposed standard
 > and is therefore a BAD thing?

Generally, clients can do anything they can get away with - anything
that their users find useful.  Clients can't get away with talking to
servers in a way that they don't understand because it is not useful,
so clients are really limited to doing things that servers understand,
but there are no limits on *which* servers a client talks to.

 > If you build an RDS mechanism into the browser, then I claim it to be
 > a URN-aware browser, rather than just a URL-aware browser.  I should
 > have been more specific here.

The distinction becomes meaningless when the RDS mechanism 
is used to resolve URLs as well as these new "urn:"s.

 > [The rest of the mail has been deleted because I read Dan's statements
 > to be agreeing with mine, but I may be wrong]

You never know with names. :-)  Most controversial is:

I agree, and that is why "urn:" would eventually become associated
with a single protocol, just as most URL schemes are associated with a
       ^^^^^^
single protocol.

dan

Date: Wed, 02 Apr 1997 16:45:24 -0500
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: Ryan Moats <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] urn: prefix is a brand name?
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Ryan Moats wrote:
> <snip>

Ok, I'm going to take a stab at this. I really shouldn't because I 
have some really pressing stuff to do but I can't let this go on.

The only assumptions you get to make about a URI is that it identifies
something. You don't get to make assumptions about how persistant
it might be or whether it might get re-assigned. Now, some have said
that both of those things are sociological and, in so far as it ACTUALLY
BEING DONE by the entity on the other end, they are right. 

What I and a lot of other people need is some way for anyone else to
look at an identifier and be able to make those assumptions that a
normal URI won't let us make without either a) knowing something about
each specific URI scheme or b) asking some net resource. We're not
saying
that urn: in any way gaurantees those assumption. It just says that,
"hey, when this person put this identifier within this class of URIs
they
understood that you get to make some assumptions about how they
are going to treat it."

Now, you can say that this is something that should be defined per
URI scheme but what we are recognizing is that there are several
possible schemes that have this important property and that this
property is important enough to use as a discriminator between
names and locators. Plus, whenever a new scheme or namespace comes
along we don't want or need to update the clients so that they 'know'
that a particular scheme has those properties. The client simply
knows this by the fact that the "urn:" is there.

-MM

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

From: "Ryan Moats" <[email-masked]>
To: "Daniel LaLiberte" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Wed, 02 Apr 97 15:07:53 
Priority: Normal
Subject: Re: [URN] urn: prefix is a brand name?
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Wed, 2 Apr 1997 13:57:00 -0600 (CST), Daniel LaLiberte wrote:

>Ryan Moats writes:
> > Reasons that come to my mind for having "urn:" (I don't claim that anybody
> > else needs to agree with these...):
>
>So that's how it happened.  The previous time I had checked the
>syntax, the "urn:" was still optional, as I recall.  I don't recall
>any explicit statement to the mailing list that "we are now going to
>make 'urn:' required - any comments?".  Oh well, you wanted a brand
>name to protect, so you got it.

I don't claim this are the accepted reasons by the whole group
(or why "urn:" became required in the first place), these are just what
came to my mind while thinking about Dan Connely's questions over
the weekend (since "it's a closed topic" doesn't seem to work).
In fact, I take umbrage at the implication of the first sentence, because
that is NOT "how it happened".

 As to the explicit statement about the "urn:" becoming required,
there was one and it is in the archives.   I sent mail to the URN list
Mon, 16 Dec 1996 (Message-Id [email-masked])
that was a pre-release of the syntax-02 draft.  This message included
a list of changes in the syntax draft.  Change #2 (I'm quoting now...)

	"2. The tag "urn:" is now required.  There were several folks at San
	Jose that said that the absence of this tag would break things, while there
	was no one that said the presence of this tag would break things. If
	someone has a situation where the presence would BREAK things
	(not just be inconvient) let the mailing list know!"

> > 1. URNs are NOT URLs.
>
>Argument by affirmation, as Dan Connolly says.  Doesn't help.

This position has been stated before on the mailing list, and (my humble
opinion, not fact) I think the majority of the WG agrees with this...

> > 3. Currently (based on my interpretation of URL schemes, your mileage may
> > vary), each and every URL scheme has a "resolution" "protocol" tied to it.
>
>Not true.  There is an associated protocol for most URL schemes, but
>it is not necessarily used.  *If* you use the protocol, then you have
>protocol-specific info in the URL.  But if you do not use the
>protocol, then you still can use the same info.
>
>E.g. web clients do, in fact, use things besides HTTP in resolving
>http URLs.  They are not prohibited from doing so.  It doesn't help
>to deny this.

I assume that you are stating that they do something other
than do a DNS lookup of the name and connect with HTTP.
If so, I have a hard time reconciling this with RFC 1738, which
states that "The <tag> URL scheme is used to designate Internet
resources accessible using the <tag> protocol", where
<tag> is FTP, Gopher, HTTP.  The statement is slightly different
for other protocols, the concept of tying protocol to scheme is there.
If a browser doesn't use the <tag> protocol to retrieve a <tag> URL scheme
resource then why have the <tag> scheme at all?
As an extension, if a browser isn't following this, then why can't it
be claimed that that browser is not supporting the proposed standard
and is therefore a BAD thing?
 
> > The URN working group is proposing that initially there be a set of
> > "resolution" "protocol(s)" for URNs tending toward a single
> > resolution protocol.  All of these are independent of the URN NID.
>
>Just to clarify, what you are calling "resolution protocols" are being
>called RDS protocols by other people, if I read you correctly.

Yes, and I apologize for my inexact wording.

> > 3a. (#3 has the result that URN-aware browsers do not have to be
> > modified if a new NID is defined as compared to what is required for
> > supporting a new URL scheme.
>
>Not true.  Browsers could resolve all current URL schemes as well as
>any new schemes using an RDS mechanism.

If you build an RDS mechanism into the browser, then I claim it to be
a URN-aware browser, rather than just a URL-aware browser.  I should
have been more specific here.

[The rest of the mail has been deleted because I read Dan's statements
to be agreeing with mine, but I may be wrong]

Ryan

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 2 Apr 1997 13:57:00 -0600 (CST)
To: "Ryan Moats" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] urn: prefix is a brand name?
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ryan Moats writes:
 > Reasons that come to my mind for having "urn:" (I don't claim that anybody
 > else needs to agree with these...):

So that's how it happened.  The previous time I had checked the
syntax, the "urn:" was still optional, as I recall.  I don't recall
any explicit statement to the mailing list that "we are now going to
make 'urn:' required - any comments?".  Oh well, you wanted a brand
name to protect, so you got it.

 > 1. URNs are NOT URLs.

Argument by affirmation, as Dan Connolly says.  Doesn't help.

 > 2.  As a corollary to #1, using the same space for URN NIDs and URL
 > schemes leads to greater collisions than keeping the spaces separate.  

Even within URNs alone, or URLs alone, the same collisions could occur.
But you are right that the space of both URNs and URLs is larger, and
thus more collisions could occur.

 > 3. Currently (based on my interpretation of URL schemes, your mileage may
 > vary), each and every URL scheme has a "resolution" "protocol" tied to it.

Not true.  There is an associated protocol for most URL schemes, but
it is not necessarily used.  *If* you use the protocol, then you have
protocol-specific info in the URL.  But if you do not use the
protocol, then you still can use the same info.

E.g. web clients do, in fact, use things besides HTTP in resolving
http URLs.  They are not prohibited from doing so.  It doesn't help
to deny this.

 > The URN working group is proposing that initially there be a set of
 > "resolution" "protocol(s)" for URNs tending toward a single
 > resolution protocol.  All of these are independent of the URN NID.

Just to clarify, what you are calling "resolution protocols" are being
called RDS protocols by other people, if I read you correctly.

 > Using "urn:" at the beginning of the URN provides a syntactic
 > handle for browsers to recognize URNs as being distinct from URLs.

Not only are they made distinct from URLs, but all "urn:" ids can use
the same RDS protocol.  I understand this perfectly fine; I just don't
agree that it is necessary.

 > 3a. (#3 has the result that URN-aware browsers do not have to be
 > modified if a new NID is defined as compared to what is required for
 > supporting a new URL scheme.

Not true.  Browsers could resolve all current URL schemes as well as
any new schemes using an RDS mechanism.

But new resolution mechanisms may be associated with any URL schemes
AND any URN subschemes.  E.g. for "urn:hdl:" you might use the CNRI
handle resolution mechanism directly.

 > An addition to the "family" of resolution
 > protocols for URNs would require browser modification , but the direction
 > is for less URN resolution protocols rather than more).

I agree, and that is why "urn:" would eventually become associated
with a single protocol, just as most URL schemes are associated with a
single protocol.

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

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 2 Apr 1997 13:04:57 -0600 (CST)
To: Leslie Daigle <[email-masked]>
Cc: Patrik Faltstrom <[email-masked]>, [email-masked]
Subject: [URN] Re: Hierarchical ownership of name spaces
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Leslie Daigle writes:
 > By your model, then, in order for ISBNs to be used in URN space, they
 > would have to be _assignable_ by some distributable, published
 > mechanism that ensures automatic assignment is unique (and satisfies
 > every other criterion that the _developers_ of that namespace have
 > for their own purposes).

ISBNs are already screwed up, I understand, since publishers are
forced to reuse IDs in their subspace when they run out of space.  The
problem, in my mind, is that they limited the size of the space rather
than making it hierarchically extensible.

But despite that flaw, ISBN ids *are* assigned by an established
mechanism (that doesn't quite ensure uniqueness) and corresponding
URNs would be assigned by the same mechanism, I would think.  I don't
see what you are getting at, or what you think my model is.

Any established name space will already have its own rules for
assignment of names, and the existence of corresponding URNs won't
change those rules.

 > I, however, have been operating on the assumption that URNs should be
 > globally and publicly _resolvable_, while perhaps only privately _assigned_.
 > I.e., I still can't assign an ISBN (URN) if I am not a publisher having
 > signed whatever necessary agreements.

I do not disagree.  Your "however" indicates that you think I do.
But, and you probably agree, some URN name spaces may be resolvable
only with limited access control.

 > The proposed work is to develop a system for globally unique, persistent
 > identifiers.
 > 
 > If we have _no_ requirements that participating namespaces produces either
 > unique or persistent identifiers, then what's the point?

Good question.  If the only definition of what is unique is up to each
name space, and persistence, like life itself, eventually comes to an
end, then what possible enforcable requirements make any sense?

 > I agree that
 > it is difficult to _ensure_ that namespaces do adhere to this, but if
 > we don't even make the effort to require it, well...!

If we don't make the effort to require it, and there is not enough
incentive for the providers to provide it on their own, and users
don't care enough, well, why will anyone use it?  What are we really
trying to do?

My motivation for setting up the NAPTR mechanism, or any persistent
service, is to provide the service *if* people want it.  If they don't
want it, then why bother trying to force it on them with requirements?
The idea of requirements here is backwards.  We don't want to force
people to use URNs, we want to motivate them by providing a persistent
service that they will want to use.

It appears that the motivation behind the requirements is to protect
the "urn:" prefix as a brand name, as Dan Connolly suggested.  I agree
with him that this is ill advised.

 > > And you want to impose on the naming authority that they somehow avoid
 > > the hassles for the benefit of the world.  Doesn't the naming
 > > authority have a strong enough incentive without any external
 > > impositions?  Why will people choose to use URNs if they dont
 > 
 > If the na doesn't want to do this -- htere are plenty of other mechanisms
 > for producing identifiers.  URLs, for example...  I hear they can 
 > do virtually everything we're proposing for URNs...

But you don't believe it, of course.

As I've pointed out several times, the biggest problem with deploying
any new URI scheme is deploying the resolution mechanism.  If we can
deploy just one very general mechanism that is applicable not only to
names but any other kind of identifier, then this will be a great
benefit.  This is especially true if the mechanism also supports
greater persistence in the resolution process.

 > > understand the benefit of avoiding the hassles in the first place?
 > > But if they do, then why do we need to step in to impose our vision of
 > > order?
 > 
 > Because some people _do_ feel the need for this order -- and that's
 > why they're participating in this process.

If the people who want the order think they can impose it on others
who are relatively satisfied with things as they are, then this is the
wrong market model - it won't happen that way.

Other people are involved in the process for other reasons.
I am here to provide a persistent resolution service that many people
will *want* to use, and not because there are any requirements on how
it is used.

 > > But indeed, it becomes very complex to decide whether the unique id
 > > rule is being obeyed.  

 > Yes -- and I believe the NID requirements draft contains verbiage
 > to the effect that "different" is defined on a per namespace basis.
 > Namespaces may choose to delgate that decision furhter down the
 > food chain.

Great, but then what is the point of a baseline uniqueness requirement
that says only that "You MUST assign names uniquely, but you can
define 'uniquely' however you want"?

 > The difference is that I believe namespaces, _when_proposed_
 > as_URN_namespaces, should "agree" to adhere to some baseline
 > requirements.

But the baseline uniqueness requirement is meaningless.

I don't think there is a single requirement that could be enforcable
or meaningful.  So why do I worry about the imposition of
non-enforcable and meaningless requirements?  Good question.

Requirements that do make sense are at the level of protocol, not name
space management.

dan

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 2 Apr 1997 12:06:16 -0600 (CST)
To: "Martin J. Duerst" <[email-masked]>
Cc: [email-masked]
Subject: [URN] Hierarchical resolution
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Martin J. Duerst writes:
 > In the context of ISBNs, relative URLs will rarely appear.

Probably true.  But the principle is the same.

 > [...] And I still don't see the
 > technical benefits. It seems that you (and others) have
 > scalability in mind. Well, if you use something such as
 > NAPTR, it is as easy to get "contact a server in Japan
 > for all ISBNs starting with a '4'" whether the delimiter
 > is a '/' or a '-'. The same again if you have a prefix
 > such as 0-201- (Addison-Wesley), on the next level.
 > It also does not inhibit you to reuse information
 > obtained in previous NAPTR requests if you still have
 > it around.

You are right.  This is the difference between a hierarchy that is
visible as a path in the identifiers and one that is invisible (in a
standard '/' delimited form) but only exists as a lattice (acyclic
graph) of transformation steps.  The transformation capability, using
NAPTR regular expressions, is more general, but less constraints mean
the client must do more work, and there is more data to be cached.
With a '/'-delimited path, the constraints make parsing trivial.

There is still a question as to whether NAPTR regular expressions will
be deployable.  But a more severe problem is that regular expressions,
as general as they are, are inconvenient or, in some cases, not
sufficient.  For example, reversing a list of components, such as
left-to-right path components, to construct a DNS name for the next
step of the resolution cannot be done with a single regular expression
substitution - it requires a sequence of transformations.

 > There may be multiple hierarchies, such as conceptual
 > hierarchy, resolution hierarchy (different for various
 > resolution services),... Assuming their identity with
 > a single and fixed hierarchy delimiter may be rather
 > contraproductive.

Multiple hierachies, even overlapping hierarchies, are not
incompatible with what I am (we are) thinking.  The forest of
alternative trees can be viewed as a single tree at one level higher.

Using a single delimiter is merely a syntactical issue, but an
important one nevertheless.

You seem to be concerned that a visible path will make the resolution
path fixed.  This is not quite true.  An explicit a path does not
necessarily correspond to a fixed resolution path since each step of
the resolution determines where to go next to resolve the remainder of
the path.  This is similar to a sequence of transformations in being
flexible about the resolution hierarchy.

Furthermore, even if we are resolving a path, one identifier might, in
the end, map to another identifier, and that might map to another,
etc, and thus we get the equivalent of the NAPTR sequence of
identifiers.

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

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 2 Apr 1997 10:44:42 -0600 (CST)
To: Dan Connolly <[email-masked]>
Cc: "Ron Daniel, Jr." <[email-masked]>, [email-masked]
Subject: [URN] Visible hierarchy, check chars, resolution
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Dan Connolly writes:
 > I'll buy that check digits and relative URIs don't mix.
 > For the ISBN: scheme, we have to pick one. This
 > is a tradeoff between human-friendliness vs. functionality:
 > check digits imporove man-machine reliability, while hierarchical
 > names support scalable resolution, as Daniel says.

Well, check chars could work just fine with relative URIs.  After
thinking about it a bit more, it became clear that the check chars
should just be incorporated into the last component of the path.
There is always a last component (except where noted below), and the
relative URI corresponds directly to a full URI, so the last component
"knows" what the check chars should be.  The error in our previous
suggestions was that, without knowing what we were doing, we made the
last component *be* the check char, which would not work.

One exception to the always-a-last-component rule is when a relative
URI, or any URI for that matter, is a directory.  There are three
situations in which this can happen: the URI ends in "/", ".", or
"..".  For URIs that do correspond to directories, but do not end in
"/", the rule is that since only the server knows this, it should
return a redirect to the correct URI that does end in "/".  There
might be a similar rule about URIs containing "." or "..", but in that
case, the client can figure it out.  Anyway, for these directory
"documents", there is perhaps not even a need for a check char for
legacy naming schemes because they don't even address the issue of
identifiers for collections of documents.  But nevertheless, I would
be happier knowing that check chars are allowed for directories too,
even for new naming schemes.  And the solution is still pretty simple
- the check chars should be attached to the name of the directory.
This means you cannot end your relative URI with "." or "..", though,
because you must always name the directory with its check char
explicitly.  But for all directory names appearing in the middle of a
path, the check char should not be there.

This question of where to put the check chars is similar to where we
put other associated information when we have a hierarchical path.
Information such as an issue date or signature of the identifier
should also be attached to the last component of the path.

 > To put it another way: hierarchy is necessary to exploit
 > locality of reference, which is essential to scalability.

But the hierarchy *may* not need to be visible, and there *may* be
other ways to exploit locality of reference, but I haven't seen
sufficient arguments to that effect.

The main advantage of a visible hierarchy is that processing of the
components of a path is far more straightforward than successive
transformations of an identifier through intermediate states using
locally cached transformation directives.  The visible hierarchy
also, incidently, supports relative identifiers.

 > Hmmm... all this regexp stuff is cool, but in order
 > to exploit locality of reference, we have to be able to
 > parse addresses from the other direction: from the
 > leaves toward the root. I'm suddenly perplexed as
 > to how to do that with NAPTR.

I don't follow why parsing needs to be done from the leaves toward the
root.  In order to know what leaf you are looking at, you have to know
the whole path, from the root down, so you have to always start at the
root.

With DNS lookup, there is typically a first stage you may be thinking
about in which you try to determine whether a DNS name can be
interpreted relative to the local domain of the client.  So if I just
say "union.ncsa" when on the "void.ncsa.uiuc.edu" machine, it is
interpreted first relative to "void.ncsa.uiuc.edu", then
"ncsa.uiuc.edu", then "uiuc.edu", at which point we get a match:
"union.ncsa.uiuc.edu".  But this first stage of DNS lookup is not
about locality of reference; this is about interpretation relative to
a local context.

 > > Until there is a strong enough argument
 > > for how non-hierarchical name spaces can support scalable resolution,
 > > I would hesitate to disallow hierarchical name spaces.
 > 
 > That makes a lot of sense.

But currently, hierarchical name spaces (visible or not) are actively
discouraged, though not quite disallowed.  I think this is the wrong
way around.

dan

Date: Wed, 2 Apr 1997 18:28:20 +0200 (MET DST)
From: "Martin J. Duerst" <[email-masked]>
To: Dan Connolly <[email-masked]>
Cc: Cecilia Preston <[email-masked]>, [email-masked]
Subject: Re: [URN] draft Bibliographic Identifiers to URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 28 Mar 1997, Dan Connolly wrote:

> Cecilia Preston wrote:
> > >> Example: URN:ISBN:0-395-36341-1
> ...
> > >Since ISBNs are hierarchical, ISBN:/0/395/36341/1 would
> > >make more sense.
> > >
> > 
> > You are imposing your hierarchical
> >path name model into a space that is
> > defined by community to have hyphens and had done so since the mid 1960's.
> > 
> > Furthermore it is not up to the URN community to direct the use of that
> > part of the space, that is up to the Namespace ID.  Please remember that
> > this document is intended to illustrate how existing namespaces schemes can
> > work within the URN syntax.
> 
> Hmm... I can see the social benefits of using the syntax
> that the community is familiar with.
> 
> But do you see the technical benefits of exploiting the
> URI hierarchy syntax? It allows the use of relative
> URLs. It remains to be seen whether they would be used
> in the ISBN context as much as they are in the http:
> and ftp: contexts. But the technical benefit is there.

In the context of ISBNs, relative URLs will rarely appear.
Even if we could get rid of the checksum digit problem,
the case where all URLs in a document refer to books by
the same publisher are rare. And I still don't see the
technical benefits. It seems that you (and others) have
scalability in mind. Well, if you use something such as
NAPTR, it is as easy to get "contact a server in Japan
for all ISBNs starting with a '4'" whether the delimiter
is a '/' or a '-'. The same again if you have a prefix
such as 0-201- (Addison-Wesley), on the next level.
It also does not inhibit you to reuse information
obtained in previous NAPTR requests if you still have
it around.

There may be multiple hierarchies, such as conceptual
hierarchy, resolution hierarchy (different for various
resolution services),... Assuming their identity with
a single and fixed hierarchy delimiter may be rather
contraproductive.

Regards,	Martin.