Subject: Re: [URN] URNs and MIME "Content-Disposition"
From: "John C. Mallery" <[email-masked]>
To: Terry Allen <[email-masked]>
Cc: [email-masked]
Date: Fri, 28 Nov 1997 20:30:51 -0500

What about content-location? I believe it accepts a URI, which subsumes URNs.

Date: Fri, 28 Nov 1997 15:23:08 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] URNs and MIME "Content-Disposition"
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

I would like to find a way to indicate in the wrapper of a MIME message
that a body part has a given URN, and that the recipient should refer
to that thing by that URN in subsequent correspondence.

This is quite like RFC 2183's Content-Disposition header field with
the "filename" parameter.  But I can't really squeeze URNs into
2183's definition of "filename," and it seems better not to try.
I'm inclined to use a parameter of "x-urn" (even though I haven't yet
figured out whether that would be legal), or else find another way to
achieve the same end.

I'd appreciate comment (privately; it isn't apropos to our current
work items) from anyone who is interested in the same functionality or
would be interested in commenting on how to achieve it.  

Thanks.

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

From: "Zhangfan Xing (llf 96)" <[email-masked]>
Date: Wed, 26 Nov 1997 16:05:46 -0800
To: Leslie Daigle <[email-masked]>
Subject: Re: [URN] Regarding name spaces of U.P.C., EAN, etc.
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Zhangfan Xing (llf 96)" <[email-masked]>

Many thanks for your reply.

> I didn't know if you'd gotten a response yet on your queries.  Sorry
> I haven't leapt in before now, but I've been travelling/buried under
> other things.

Yours is the only one.

> Yup, and very relevant ones, at that :-)
>
> > (1) Who is or is going to be the Global NID registry?
> > Or we don't need any, because the future clients have the knowledge.
>
> You may choose whether you want to be accessible there or not.  It hasn't

I am not so clear about this. Why doesn't anybody want to be accessible?

> yet been formalized, but a volunteer will have to be found for the NAPTR
> global NID service, and any other competitors.
>
What is the requirement for such a volunteer?

> > (2) If there is a Global NID registry, when and how it register RDS
servers?
>
> This is something that will have to be specified in a document describing
> the NAPTR global NID service.  You are very correct in fingering it
> as missing information right now.
>
When do we expect a NID registry starts to function, one/two years from now?

> > (3) Has U.P.C. (or EAN or other barcode technology related codes) name
space
> > been proposed? Or if someone is working on that?
>
> Not that I am aware of.

So I can start to propose one? Can you suggest any similar proposal that
I can follow?

>
> > (4) Is there a forum for RDS or URN resolver service?
>
> What sort of forum?  Discussion forum?  So far as I know, the
> [email-masked] mailing list is the only discussion forum.  It's
> been a bit slow lately as we fall into the gap between theoretical
> discussions and very practical ones as different people pick this up
> and use it.  (A very _good_ thing for people to do, I might add!).
>

I think there are quite a few services out there, which are in fact
RDS or URN resolver service. People just have not thought in the line of URN.
However, mobilizing people is not an easy task. Maybe we can work out
certain scheme for that.

> > (5) Are DNS root servers currently running BIND Release 8, which is
> > NAPTR-capable? Is InterNIC going to register RDS servers, referred to (1) ?
>
> I can't speak for InterNIC.  But, NAPTR has been in BIND for quite a while
> (over a year, I think), so the deployed base of NAPTR-capable nameservers
> should be pretty high.
>

The problem is how to "sale" it to the mass ;-)

Zhangfan

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Zhangfan XING               Tel: (818)393-3555
Mail Stop 300-323           Fax: (818)393-6720
Jet Propulsion Laboratory   Email: [email-masked]
4800 Oak Grove Drive        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Pasadena, CA 91109
~~~~~~~~~~~~~~~~~~~~~~~~~

Date: Wed, 26 Nov 1997 17:15:33 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] Agenda for Washington Meeting
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Here's the proposed agenda for the Washington meeting.  Please let
me know if there's anything you think should be added.

Leslie.

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

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

----------------------------------------
IETF URN Working Group
----------------------------------------

Agenda for Thursday, December 11, 1997 (13h00-15h00), Washington DC

	. Review of (known) other work

	. URN Registration and Standardization Process
	  (draft-ietf-urn-nid-req-02.txt)

	. NAPTR Global NID registration process
	  (formal draft not yet in archives)

	. State of Proposed RFCs 
		. biblio identifiers
		. architecture
	  	. URI resolution services

	. Learning by Doing:  PDIs
	  (draft-mallery-urn-pdi-00.txt)

        . Action plan for WG wrap-up

Date: Tue, 25 Nov 1997 11:59:09 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] Drafty Confusion
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

My apologies for not noticing that the urn-nid-02 draft I commented
on (and which I'd freshly fetched from ds.internic.net) was not
the document advertised in the announcement, and in fact is dated
25 March 1997 and identified as draft-ieft-urn-nid-req-01.txt.
It's been a busy year...

I like the drafty draft much better!

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

Date: Tue, 25 Nov 1997 11:46:43 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] re ISO name space(s)
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Leslie wrote:

| > We are presumably going to grandfather in ISO name spaces,
| > such as those for FPIs (8879) and PIs (9070).  Can we decide on
| > nids for these in parallel with constructing this document?  Is
| > it appropriate for liason with ISO to take place on this point?
| > (ISO might want "iso" as a nid, it occurs to me.)  
| 
| I'm operating on the "push" assumption -- that if ISO is interested,
| a suitable representative will go through the steps outlined in the registration
| process.

Given that it's ISO, I think we need to be more proactive; our Area
Director might have some thoughts on this point.  A point on which ISO
may need some time to think is how its name spaces are arranged.  Does
it want urn:iso:fpi or urn:fpi or urn:iso:8879:fpi - in other words,
what does it want as the top level and what level is immediately below?
This may be too high-level a question for any one ISO's WGs to 
consider it its job to answer, so it may need to be presented to the
ISO liason representative (there is one, isn't there?).

Regards, Terry

Date: Tue, 25 Nov 1997 12:53:36 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Terry Allen <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] re urn-nid-02
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Tue, 25 Nov 1997, Terry Allen wrote:
> I see I commented on the drafty draft a bit late.  Here goes on
> urn-nid-02.  Executive summary:  All we have to do is figure out

Wait a minute...

Something smells fishy here.  What you have here (and presumably waht
made it to the draft repository) is the _old_ document.

I will check into what happened, and in the meantime, just let me
say that this document _HAS_ been replaced in intention, if not in
fact in the repository.

Leslie.

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

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

Date: Tue, 25 Nov 1997 12:49:53 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Terry Allen <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] re URN NRSPM drafty draft
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Mon, 24 Nov 1997, Terry Allen wrote:
> Fine so far as it goes, although I don't see that vanity
> nids are addressed.  A few comments, but first a question.

Vanity NIDs are not really tackled head on.  However, in order to
select a NID by name, you have to go through an RFC process, which
is perhaps more daunting than staking $50US/year for whatever string
occurs ;-)

> We are presumably going to grandfather in ISO name spaces,
> such as those for FPIs (8879) and PIs (9070).  Can we decide on
> nids for these in parallel with constructing this document?  Is
> it appropriate for liason with ISO to take place on this point?
> (ISO might want "iso" as a nid, it occurs to me.)  

I'm operating on the "push" assumption -- that if ISO is interested,
a suitable representative will go through the steps outlined in the registration
process.

> 1.  This document is now short.  Short is good.

:-)  

> 2.  The place of the nid in the URN syntax should be recapituated
> 	for clarity.

Okay.

> 3.  What does "publication of structural elements of the identifiers"
> 	mean?  is this re type IV?

No, not just type IV.  This is the opportunity for a namespace to expose
as much of its structure as it wants to be available to the world for
whatever uses/speculation/resolution tactics might be useful.  For
example, the PDI draft outlines the structure of PDIs in terms of 
document series, etc. 

In part, I guess the grand theory is that registration with a particular
global NID (e.g., the NAPTR one) can make reference to teh structure
thus-identified when proposing how to delegate to subauthorities.

> 4.  "A URN namespace may be assigned or may request..." no, its owner
> 	may request.

Okay, good point :-)

> 5.  "OID" should be glossed and a reference provided.

Okay.

> 6.  What is the status of a "Standardized" name space while it is
> 	passing through the RFC process?  Experimental?  so TFNS
> 	(Terry's Fine Name Space) would be "x-TFNS" during that process,
> 	and when through it would be "TFNS"?

This seems like a reasonable proposal, or else it could be a POID.

> 7.  I think point IV (Top-level) is unneeded, although the RFC 1766
> 	part could be kept.  Re that, I recently spent $143 on what
> 	turned out to be an obsolete version of the relevant ISO
> 	standard, ISO 3166, which included codes for countries that
> 	existed in 1988 but do not today.  If Yugoslavia had used
> 	YU (or whatever the code was), which present-day entity
> 	would have inherited it?  Do we care?  Would the code
> 	remain valid (it has been dropped from ISO 3166:1997, I
> 	believe).

Understand that the proposal for the country codes is not so much
to ensure/enable longevity of identifier collections -- we've previously
agreed that country designators are lousy for this, for just the reasons
you identify.

Rather, there has already been proposals by various governments that 
they wish to designate a national authority (e.g., national library)
that can sub-assign namespaces -- e.g., for audio publications, printed
publications, serial publications, etc.  Each of these should be a valid
first-class namespace, but qualified by the fact that it is particular
to one organizing body.

Type IV just seeks to generalize that, so that, for example, companies
could have their own top-level namespaces for the different object types
they choose to identify.

> 8.  Does the string "POID.##" indicate that the suffix should be a
> 	number?  Who assigns this number?

Yes; it shall be clarified.  The expectation was that it would be a 
serially incrementing number -- i.e., the first one is 1, then 2, then... 100.

> 9.  The "Registration Procedures" for type II and the "Standardization
> 	Process" for type III are very similar.  Is there any reason
> 	they should differ at all?

Type III registration procedures should subsume Type II ones and add
additional constraints that address validation (see below) and scope of
the namespace (which _is_ an issue for arguing about the appropriateness
of the NID string.  The argument is that the US government shouldn't
get "social security numbers", as the potential scope exceeds their
range -- other countries have such identifiers).

> 10.  Why the requirement that the validation mechanism for type III
> 	be whois, finger, or mail?

This is the beginnings of a suggestion that, for fully-standardized
namespaces, there should be a validation service that can verify if
a URN is indeed an identifier in that namespace.  Note that this does
_not_ imply that the URN itself need be resolvable.  The argument here
is that for it to be an _Internet_ standard, it should have some bearing
on the Internet infrastructure.

The specific protocols listed (whois, finger, mail) were proposed as
a reasonable range of base-line protocols from which to _select_ for
supporting this validation service.  There is, somewhere in the ether
(hi Dirk ;-)  the beginnings of a proposal for what the validation
service could be.

Thanks for all the comments...

Now I've provided more background on what the document authors were looking
to express in the document -- I look forward to the group's comments
on what this is attempting to capture.

Leslie.

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

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

Date: Tue, 25 Nov 1997 09:19:27 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] re urn-nid-02
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

I see I commented on the drafty draft a bit late.  Here goes on
urn-nid-02.  Executive summary:  All we have to do is figure out
a registration procedure and get on with business.  We do not have
to play URN Inquisition with would-be registrants, and attempts to
do so both impede the introduction of URNs and reduce the likelihood
of obtaining cooperation of name space owners in the registry that
*WE want them to use*.

|             Namespace Identifier Requirements for URN Services
| Abstract:
| =========
| 
| Services that offer to resolve Uniform Resource Names implicitly
| require that they support a persistent and reliable service for an
| indeterminate length of time. This draft outlines the requirements for
| any such service that wishes to participate as a Namespace Identifier.

Disagree with the first sentence (see below).  Participate within what 
framework?

| Introduction:
| =============
| 
| The Uniform Resource Name (URN) Working Group has defined mechanisms
| for both the syntax [4] and resolution of URNs [1,2]. An framework
| for URN discovery systems has also been outlined [3]. This draft
| discusses and recommends the requirements for entities that wish
| to act as Namespace Identifiers (NIDs) within the URN system.

The NID is part of the URN string.  So these entities are not acting 
as NIDs.  They are assigning URNs or delegating parts of name spaces.

| The NIDs in these cases, "znet", "buns", and "hoptus" all
| act as top-level namespaces, and hence, must meet certain
  ^^^^^^  "denote", not "act as"

|  Global Scope and Uniqueness.
| 
|   - The NID must be registered with IANA to ensure uniqueness and
|     demonstrating that it meets the requirements listed in this
|     document.

What happened to I-IV in the drafty draft?  

|   - Rules on how the Namespace Specific String are allocated
|     must be documented.

But not necessarily published.

|  Persistence
| 
|   - The NID service providers must show that they intend to
|     support the service for an indefinite period of time.

Impossible to do.  They might be required to promise that they
intend to do that, or arrange for successors, but showing their
inner state of mind is not something we should require.

And it is possible to imagine uses of name spaces for short-TTL
objects such that it would be perfectly reasonable to expect that
no one would want to resolve such names after, say, 20 years or
the expiration of a statue of limitations.

|   - Support facilities must be described and how the service
|     intends to operate, including "disaster recovery"-like
|     operations.

Oh come on.  Are you requiring everyone to describe their IT
policy?  This is for adults in the marketplace to deal with.

|   - Demonstrated experience in managing an established namespace
|     system is essential.    

Is required?  Um, no, we should not be erecting barriers to entry.

|   - One URN should never be reused for a different resource (where
|     "different" is defined as in previous paragraph by the namespace).
|     The URN should be persistent for all times, even though the
|     resource goes away.

This does not belong in a list of what name space registrants have
to demonstrate.

|  Independence
| 
|   - The NID service providers must also show any relationship
|     (both technical and administrative) that may impede on the
|     provision of the URN service.

This is just silly.  *Any* relationship might impede something,
but many relationships are confidential.  This goes far beyond
what we can expect reasonable people and corporations to expose.
"NID service" means nothing to me; "URN service" needs to be glossed.

|   - However, multi-party participation in the NID service is
|     an advantage.

A point not necessary to include here.

|  Resolution
| 
|   - The NID service providers must produce an RFC
|     describing the technical characteristics of the URN
|     resolution service, including security considerations.

Real vague, and requires exposing security considerations that it may
be desired to keep secret.

|   - The NID service providers may elect not to have the
|     resolution service publically available.

Of course, but we don't need to say that here.

| This URN, in the namespace called "buns" is referring to the
| document named annual-report, in postscript format. 
| 
| At a later stage, that resource is replaced by a text version, which
| lacks the pictures, but that is ok, because the namespace has decided
| that postscript format documents and text documents are considered the
| same even though the figures doesn't exist in the textual version.
| 
| In the third stage, the report is removed, and replaced with a report
| for a different year. This new report gets a new URN because it is
| considered being a different document.
| 
| The old URN is never reused.

What is this scenario doing in this document at all?  And the next one?

| (2) urn:foo:bar:current-weather
|     urn:foo:bar:weather/19970325
| 
| These are two URNs referring at one stage to the same resource, i.e.
| on the 25th of March 1997. On the 26th of March 1997,
| urn:foo:bar:current-weather is referring to the same resource as
| urn:foo:bar:weather/19970326.
| 
| Conclusion:
| ===========
| 
| This draft has outlined the requirements for providers of
| NID services for URN systems. The objective is to maintain 
| a high persistence rate for URN services, and these requirements
| are aimed at ensuring a high level of service stability.

I don't think this draft even defines "NID services."

| 
| References:
| ===========
| 
| [1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
|     Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
|     February, 1997.
| 
| [2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
|     draft-ietf-urn-http-conv-01.txt, February 1997
| 
| [3] Karen R Sollins, "Requirements and a Framework for URN Resolution
|     Systems", draft-ietf-urn-req-frame-00.txt, November 1996
| 
| [4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997.
| 
| [5] Karen R Sollins & Larry Masinter, "Functional Requirements for
|     Uniform Resource Names", RFC1737, December 1994
| 
| 
| Security Considerations
| =======================
| 
| It is a requirement that it in the definitions of a namespace are
| included sections on security covering for example:
| 
|   + Spoofing of servers
|   + Verification of responses
| 
| Because a namespace can decide that a resolution service is not
| publically available, it is possible to use firewall installations and
| other traffic limiting constructions to diconnect the namespace from
| the global Internet.

More stuff not necessary to say.

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-nid-req-02.txt
Date: Tue, 25 Nov 1997 10:45:17 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

	Title		: URN Namespace Registration and 
                          Standardization Process Mechanisms
	Author(s)	: L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom
	Filename	: draft-ietf-urn-nid-req-02.txt
	Pages		: 4
	Date		: 24-Nov-97
	
The URN WG has defined a syntax for Uniform Resource Names
(URNs) [RFC2141], as well as some proposed mechanisms for their
resolution and use in Internet applications ([RFC2168, RFC2169]).
The whole rests on the concept of individual ''namespaces'' within the
URN structure.  Apart from  proof-of-concept namespaces, the use
of existing identifiers in URNs has been discussed (??? biblio id
document). This document lays out general definitions of and mechanisms
for establishing URN ''namespaces''.

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-nid-req-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-nid-req-02.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

Send a message to:	[email-masked].  In the body type:
	"FILE /internet-drafts/draft-ietf-urn-nid-req-02.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-nid-req-02.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 24 Nov 1997 12:07:31 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] re URN NRSPM drafty draft
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Fine so far as it goes, although I don't see that vanity
nids are addressed.  A few comments, but first a question.

We are presumably going to grandfather in ISO name spaces,
such as those for FPIs (8879) and PIs (9070).  Can we decide on
nids for these in parallel with constructing this document?  Is
it appropriate for liason with ISO to take place on this point?
(ISO might want "iso" as a nid, it occurs to me.)  

1.  This document is now short.  Short is good.

2.  The place of the nid in the URN syntax should be recapituated
	for clarity.

3.  What does "publication of structural elements of the identifiers"
	mean?  is this re type IV?

4.  "A URN namespace may be assigned or may request..." no, its owner
	may request.

5.  "OID" should be glossed and a reference provided.

6.  What is the status of a "Standardized" name space while it is
	passing through the RFC process?  Experimental?  so TFNS
	(Terry's Fine Name Space) would be "x-TFNS" during that process,
	and when through it would be "TFNS"?

7.  I think point IV (Top-level) is unneeded, although the RFC 1766
	part could be kept.  Re that, I recently spent $143 on what
	turned out to be an obsolete version of the relevant ISO
	standard, ISO 3166, which included codes for countries that
	existed in 1988 but do not today.  If Yugoslavia had used
	YU (or whatever the code was), which present-day entity
	would have inherited it?  Do we care?  Would the code
	remain valid (it has been dropped from ISO 3166:1997, I
	believe).

8.  Does the string "POID.##" indicate that the suffix should be a
	number?  Who assigns this number?

9.  The "Registration Procedures" for type II and the "Standardization
	Process" for type III are very similar.  Is there any reason
	they should differ at all?

10.  Why the requirement that the validation mechanism for type III
	be whois, finger, or mail?

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

Date: Thu, 20 Nov 1997 12:10:57 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] urn namespace registration process
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Attached is a very drafty draft of a revision of Renato and Patrik's
NID requirements document.  This attempts to rework the ideas in 
more process-oriented terms; when it is done, it should be a clear
expression of what one should do if one wants to construct a URN
namespace.

What I'd ask people to do is to review this document with and provide
constructive suggestions re. how it does not (or does) address the kinds
of issues we've been batting about -- such as ease of establishing
a namespace vs. potential issues of vanity namespaces, etc.

Leslie.

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

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

Internet Draft                               Leslie L. Daigle
November 19, 1997                            Bunyip Information Systems
draft-ietf-urn-nid-req-02.txt                Dirk-Willem van Gulik
                                             ISIS/CEO, JRC Ispra
                                             Renato Iannella
                                             DSTC Pty Ltd
                                             Patrik Faltstrom
                                             Tele2/Swipnet

      URN Namespace Registration and Standardization Process Mechanisms

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 obsoleted by other
     documents at any time.  It is inappropriate to use Internet-
     Drafts as reference material or to cite them other than as 
     "work in progress."

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

Abstract

The URN WG has defined a syntax for Uniform Resource Names
(URNs) [RFC2141], as well as some proposed mechanisms for their
resolution and use in Internet applications ([RFC2168, RFC2169]).    
The whole rests on the concept of individual "namespaces" within the
URN structure.  Apart from  proof-of-concept namespaces, the use
of existing identifiers in URNs has been discussed (??? biblio id 
document). This document lays out general definitions of and mechanisms 
for establishing URN "namespaces". 

Foreword to this Edition

This document is a very drafty draft.  The intention of this version
is to lay out the groundwork for some proposed processes.  Detail will
be needed.  No one has formally approached IANA to set up the registry
this is defining.  The model here is not unlike media type registrations.

Introduction

For the purposes of URNs, a "namespace" is a collection of uniquely-assigned
identifiers.  A URN namespace itself has an identifier in order to

	. ensure global uniqueness of URNs
	. (where desired) provide a cue for the structure of the identifier

For example, ISBNs and ISSNs are both collections of identifiers used
in the traditional publishing world; while there may some number (or numbers) 
that is both a valid ISBN identifier and ISSN identifier, using different 
designators for the two collections ensures that no two URNs will be the same 
for different resources.

The development of an identifier structure, and thereby a collection
of identifiers, is a process that is inherently dependent on the needs
of the identifiers, how they will be assigned, and the uses to which they 
will be put.    All of these issues are beyond the scope of the URN
work.

This document concerns itself with the mechanical processes of associating
an identifier string with a predefined namespace and publication of
identifier structures.  Of particular concern are:

	. selection of strings to associate with a namespace
	. publication of structural elements of the identifiers
	. identification of support infrastructure for assignment 
	  and resolution of URNs for a given namespace
	. determination of failure of support for a namespace

Different levels of disclosure are expected/defined for namespaces.
According to the level of discussion and standardization surrounding the
disclosure, a URN namespace may be assigned or may request a particular
identifier.

Note that this document restricts itself to the description of processes
for the creation of URN namespaces.  If "resolution" of any so-created
URN identifiers is desired, a separate process of registration in a global
NID directory, such as that provided by the NAPTR [Ref ??] system,  is
necessary.

URN Namespace Categories

There are 4 categories of URN namespaces defined here, distinguished by 
expected level of service and required procedures for registration.

The first three are simple namespace types:

	  I. Experimental: These are not registered with IANA. They take the 
	                 form
		x-<NID>

	 II. Informal:  These are registered with IANA (see Section ??), and
		are assigned a number based on a private OID ("POID" 
		namespaces).  

	III. Standardized:  These are processed through a full standards-track
	 	RFC review process.  The NID may be any valid NID string
		that does not clash with an existing, registered NID.

The fourth is a composite namespace type (i.e., one constructed for
the express purpose of later subdivision):

	 IV. Top-level: These are processed through a full standards-track
		RFC review process.  The result is not a NID so much 
		as a top-level NID structure, which will be subdivided by the 
		rules laid out in the top-level NID RFC.  These NID
		strings must not clash with existing, registered NIDs;
		additionally, the RFC1766 country code strings are 
		reserved for use by countries that desire to so-obtain
		a top-level NID.

Registration Procedures

To register a namespace (for type II namespaces, informal), the following
information must be provided to the IANA:

Declared owner of the namespace
Description of:

	. uniqueness of identifiers assigned by the namespace's naming
	  authority
	. process of assignment of identfiers in the namespace
	. rules for determining lexical equivalence between identifiers in the 
	  namespace
	. identification of validation mechanism (to ascertain whether or
	  not a string is in fact a valid URN in the namespace).  This
	  can include:
		. a syntax grammar
		. an on-line service
		. an off-line service
	. conformance with RFC1737 requirements (??? these should be
	  listed out)

The namespace is then identified by the declared owner's private OID (POID)
and a suffix to distinguish among different namespaces assigned to the
same POID:  POID.##

Standardization Process 

To establish a standardized URN namespace, the following information
must be described and vetted in an IETF standards-track RFC:

Declared owner of the namespace
Desired NID
Description of:

	. uniqueness of identifiers assigned by the namespace's naming
	  authority
	. process of assignment of identfiers in the namespace
	. rules for determining lexical equivalence between identifiers in the 
	  namespace
	. conformance with RFC1737 requirements (??? these should be
	  listed out)
	. identification of validation mechanism (to ascertain whether or
	  not a string is in fact a valid URN in the namespace) (??? in
	  this case, it is required to be one of whois, finger, mail
	  service)
	. match of scope, ownership, and/or global applicability. (?? E.g.,
	  you can't ask for "social security numbers", but the US
	  may ask for US social security numbers).

Examples

Security Considerations

(??? THere will most assuredly be some!).

References

[RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
    Identifiers using the Domain Name System", RFC 2168 June 1997.

[RFC2169] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
    RFC 2169, June 1997.

[RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997.

[RFC1737] Karen R Sollins & Larry Masinter, "Functional Requirements for
    Uniform Resource Names", RFC1737, December 1994

Authors' Addresses

Leslie L. Daigle
Bunyip Information Systems Inc
310 Ste. Catherine St. W
Suite 300
Montreal, Quebec, CANADA
H2X 2A1
voice: +1 514 875-8611
fax:   +1 514 875-8134
email:  [email-masked]

Dirk-Willem van Gulik
ISIS/STA/CEO - TP 270
Joint Research Centre Ispra
21020 Ispra (Va)
Italy.
voice: +39 332 78 9549 or 5044  
fax:   +39 332 78 9185
email:  [email-masked]

Renato Iannella
DSTC Pty Ltd
Gehrmann Labs, The Uni of Queensland
AUSTRALIA, 4072
voice:  +61 7 3365 4310
fax:    +61 7 3365 4311
email:  [email-masked]

Patrik Faltstrom
Tele2/Swipnet
Borgarfjordsgatan 16
P.O. Box 62
S-164 94 Kista
SWEDEN
voice:  +46-5626 4000
fax:    +46-5626 4200
email:  [email-masked]

Date: Wed, 19 Nov 1997 21:47:25 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Document proposed for Informational RFC 
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

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

               URI Resolution Services Necessary for URN Resolution
               draft-ietf-urn-resolution-services-01.txt

be put forward as an informational RFC.

Thanks!
Leslie.

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

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

Date: Wed, 19 Nov 97 16:02 CST
To: Dave Raggett <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [URN] Re: RFC 2141
From: Ryan Moats <[email-masked]>
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

| On Wed, 19 Nov 1997, Ryan Moats wrote:
| 
| > Before I "deal with the URN-scheme-specific issues", maybe some
| > background would be useful.  I sort of feel like I've joined in
| > the middle of the conversation... 

Thanks for bringing me up to speed Dave.  I've copied the
URN mailing list in, because they had a lot to do with the RFC
and so should be able to add their $0.02 (and to be sure this
gets into the archives for future generations :-).

| I have a few queries about the RFC, which I gave in my message.
| Harald has answered on the Unicode question, although I still
| feel it would be helpful if the RFC made it explicit that the
| name space specific part uses the Unicode/ISO 10646 character
| set. I suggest the addition of a reference to the ISO 10646
| specification, e.g.
| 
| [ISO10646] 
|    "Information Technology -- Universal Multiple-Octet Coded 
|    Character Set (UCS) -- Part 1: Architecture and Basic
|    Multilingual Plane", ISO/IEC 10646-1:1993. The current
|    specification also takes into consideration the first
|    five amendments to ISO/IEC 10646-1:1993.

Well, I think this is worth considering for the next go 'round.

| RFC 2141 requires URN's to be encoded in UTF-8, but this
| seems inappropriate and wasteful if the document in which
| the URN appears uses another encoding such as UCS-4. It does
| make sense to require UTF-8 for email encoded in say ASCII.
| The decoupling of character encoding and character set has
| proved to be very useful for HTML and XML.

First of all, this is what Section 4 of the RFC is about:

"The URN syntax defines the canonical format for URNs and all URN transport
and interchanges MUST take place in this format.  Further, all URN-aware
applications MUST offer the option of displaying URNs in this canonical
form to allow for direct transcription (for example by cut and paste
techniques).  Such applications MAY support display of URNs in a more
human-friendly form and may use a character set that includes characters
that aren't permitted in URN syntax as defined in this RFC (that is, they
may replace %-notation by characters in some extended character set in
display to humans)."

The point is that an application displaying a document in UCS-4 may
display the URN is something other than the canonical form.  However,
a user must be able to view the URN in its canonical form and it
must be transported in its canonical form.  There was a definite insistence
on just one canonical form and that's in the archives.  BTW, there
is a mirror to the archives at ftp://ftp.internic.net/ietf/urn/urn-archives/.

| Harald didn't answer the question as to why the name space
| identifier prohibits the use of Unicode, which surely will
| cause offense to non-English speaking cultures. Why should
| the identifiers be restricted to the English alphabet?

Most of this I know was covered the first time around (and is in
the archives). Originally, the NID was ASCII letters only.
ASCII numbers and the "-" were then added after one of the
IETF meetings (I think 12/96). There was a lot of discussion
about "." and ":" and adding structure to the NID, but was dropped
as being a bad idea. Part of our intent was to line
up (as much as possible) with the URL syntax.  In addition, it
I know that the NID was chosen to not discriminate against any
resolution methodology.

| The restricted syntax for name space identifiers suggests that
| this will have the same role as the top level domains for DNS
| such as "com", "org", "edu", "fr" and "uk" etc. Aren't we going
| to see a repeat of the problems facing DNS as people try to pick
| domains. Does the world really need yet another global name space?
| The lawyers would love it, obviously!

There has been a lot of discussion about just this problem on
the mailing list and in the working group and Identifier
Registration is a current WG topic that is still open.  See the archives.

| The spec would be improved by a section explaining how the
| IETF expects to manage name space identifier registration.
|
| Finally, it would be nice to explain how URN's differ from
| URLs. URLs can be both persistent and location independent.
| Perhaps a better differentiator will be the use of Unicode?

I'll point to the archives (which has a lot of the URL/URN discussion)
rather than repeat it here.

Ryan

Date: Tue, 11 Nov 1997 21:24:07 -0500
To: Larry Masinter <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] URN-PDI Issues
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

At 4:16 PM -0800 97-11-11, Larry Masinter wrote:
>> 1 the monotonicity in the binding of names to resources.
>> 
>>         2. knowledge of the resource media type
>> 
>>         3. versioning to handle updates while maintaining 
>>         document etiology
>
>(Aren't the first and the third the same?)  

No. 1 says the bytes associated with the identifier never change, ever.

3 says byte changes are associated with the same identifier by incrementing
the version number, thus allowing us to know it is the same document, but that
something has been changed. We can then march through the version numbers
and see the evolution of the document. Fragment specifiers for each version are
resolved against the correct version.
>
>I believe that each of these is fuzzy enough as to make the
>distinction useless in practice. 

Shouldn't be a problem in principle. Might take a little discipline
and commitment in practice. But, careful management of
the machine representation will also serve portable security interests,
e.g. digital signatures, digests, etc.
>
>If you allow for 'correction of transcription errors', it is quite
>possible to mis-transcribe, oh, chapter numbers, in a way that will
>make chapter-number-references obsolete.

We always increment the version number. New PDIs are issued when
the changes are more substantial. But, in general, documents for
which these are great (government documents) don't change.
>
>As for 'knowledge of media type', the current taxonomy of media types by MIME
>registration is weak enough to make this useless in countless cases. It's a
>historical artifact that Postscript level 3 is the same media type as Postscript
>level 2, but a different media type than PDF.

OK. That's not my problem, but it would be desirable to clean it up.  It will be easier
sooner than later. One approach is to parameterize the content types with the levels.

The PDI spec provides for content-type tokens to use  the <format>. These must
be differentiated enough to allow fragment types for the media type to work.  This
probably requires more emphasis in the spec.

The PDI spec differentiates the machine representation from the media type representation
in order to allow translation across different machine representations for the same
media type. This could be a leverage point for the postscript versions. If the fragment
syntax that you propose for postscript can map to the various versions, you win. If
the mapping is efficient, somebody could actually use it.
>
>In the end, you wind up with "semantic fragment identifiers work when they work
>and don't when they don't", which is good enough to make it a general mechanism
>with specific applicability.

Bottom line: they work for text/plain (single byte) and they allow us to field
a quote server.

I think that they can be made to work for even the hard cases with:

	1. sufficient pain (lots of work by someone, simplifying assumptions)

	2. degradation in performance (slow to compute, full scan + parse required)

	3. degradation in quality (lose information, e.g. fonts, indentation etc)

After all these are digital objects and they can be converted into different formats.
The real question is whether there is loss associated with a specific media type and
whether it is acceptable.

At a minimum, the introduction of  fragment identifiers puts evolutionary preasure
on new media types to support fragments or to give way to other ones that can.

You didn't mention the sporty case where you have a fragment idenfier for text/plain
but you want to resolve against application/postscript. Also, there is the issue
of combining incomensurate fragments in a composite document.  food for thought.
>
>It would work for URLs, for that matter, too. After all 'the thing at this
>location' can be a kind of URN.

yea, except we need to enforce the monitonicity constraint. Perhaps, we have 
contract associated URNization (or better PDIification) of a URL, whereby once you
commit you can't change the associated bytes. One approach is to issue PDIs for
the set of URLs by transfering the bytes to PDI semantics and using redirects
on the URLS (which amounts to asserting equality between the URL and the PDI
and enforcing the most restrictive semantics).

This should work for legacy URLs (newspaper archives etc etc) that nobody wants to
change anyway.  Additionally, the advent of an assertion infrastructure would
allow changes to be grafted above the base representation by combine fragments
in a composite PDI.

We might term this process migration from a mutable to a persistent namespace.

Date: Tue, 11 Nov 1997 16:16:46 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "John C. Mallery" <[email-masked]>
CC: [email-masked]
Subject: Re: [URN] URN-PDI Issues
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> 1 the monotonicity in the binding of names to resources.
> 
>         2. knowledge of the resource media type
> 
>         3. versioning to handle updates while maintaining 
>         document etiology

(Aren't the first and the third the same?) 

I believe that each of these is fuzzy enough as to make the
distinction useless in practice. 

If you allow for 'correction of transcription errors', it is quite
possible to mis-transcribe, oh, chapter numbers, in a way that will
make chapter-number-references obsolete.

As for 'knowledge of media type', the current taxonomy of media types by MIME
registration is weak enough to make this useless in countless cases. It's a
historical artifact that Postscript level 3 is the same media type as Postscript
level 2, but a different media type than PDF.

In the end, you wind up with "semantic fragment identifiers work when they work
and don't when they don't", which is good enough to make it a general mechanism
with specific applicability.

It would work for URLs, for that matter, too. After all 'the thing at this
location' can be a kind of URN.

From: "Zhangfan Xing (llf 96)" <[email-masked]>
Date: Tue, 11 Nov 1997 13:11:38 -0800
To: [email-masked]
Subject: [URN] Regarding name spaces of U.P.C., EAN, etc.
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Zhangfan Xing (llf 96)" <[email-masked]>

Hi, everyone,

A few questions about URN name space and its registry.

For quite a while, I have been compiling a database mapping U.P.C.
to manufacturers' web address. It's been put out on-line recently:
	http://www.deBarcode.com
It is a N2Ls service (also able to provide N2C) and will grow as time goes.

After reading ftp://ftp.bunyip.com/mailing-lists/urn-ietf.archive,
I feel this may be the time to make it compliant to the giudelines by
urn-ieft. However I do have a few questions about URN name space and
its registry:

(1) Who is or is going to be the Global NID registry?
Or we don't need any, because the future clients have the knowledge.

(2) If there is a Global NID registry, when and how it register RDS servers?

(3) Has U.P.C. (or EAN or other barcode technology related codes) name space
been proposed? Or if someone is working on that?

(4) Is there a forum for RDS or URN resolver service?

(5) Are DNS root servers currently running BIND Release 8, which is
NAPTR-capable? Is InterNIC going to register RDS servers, referred to (1) ?

Thanks,

Zhangfan XING
Mail Stop 300-323
JPL, Caltech
4800 Oak Grove Drive
Pasadena, CA 91109
[email-masked]
(818)393-3555

Date: Tue, 11 Nov 1997 13:52:37 -0500
To: Larry Masinter <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] URN-PDI Issues
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

At 8:43 AM -0800 97-11-11, Larry Masinter wrote:
>I'm sorry, I was just reacting to the issue of specifying fragment
>identifiers. Although PDIs may be widely used, it sounds like naming
>of fragments isn't well worked out. Since this is a well-known
>Hard Problem, and it seems to apply for all URN schemes and not
>just PDIs, perhaps it would be better to remove the 'fragment
>identifier' component from the PDI spec?

A separate fragment spec  is an option. However, note that
workability of this approach depends on:

	1 the monotonicity in the binding of names to resources.

	2. knowledge of the resource media type

	3. versioning to handle updates while maintaining 
	document etiology

These semantic properties of the namespace are required for this
fragment approach. I'm not sure how many other extant namespaces
currently meet these requirements.  IETF documents would work
because they are fixed and text.

Since we are in the process of deploying, one might acquire the experience base 
with PDIs and then develop the general fragment spec

Hard Problem: This fragment approach uses divide and conquer as
well as extensibility to cut the gordian knot. Why wait until a workable
fragment syntax is available for media types with design problems wrt
fragments when there are many opportunities that we can use now?

I have tried to start the ball rolling with some obvious fragment specifiers
for obvious media types. Others can work on their favorite media types. 

When there is doubt, no default fragment specifier is provided for the
media type.  That allows specialists to work out definitive solutions (if possible)
later. 

The HTML/SGML languages raise the problem of relevant context (as noted
by Ron Daniel). There is no default there. We have some simple and efficient
specifiers that can be used now. 

When better proposals from the specialist community
are forthcoming, they can be dropped in, and perhaps, made the default if they
solve the problem. As far as I can tell form a quick perusal of HyTime addressing,
it provides any number of tree reference schemes, but I saw no solution to
the context problem that we face in deployed HTML.
(Correct me if I am wrong).

Date: Tue, 11 Nov 1997 08:43:38 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "John C. Mallery" <[email-masked]>
CC: [email-masked]
Subject: Re: [URN] URN-PDI Issues
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I'm sorry, I was just reacting to the issue of specifying fragment
identifiers. Although PDIs may be widely used, it sounds like naming
of fragments isn't well worked out. Since this is a well-known
Hard Problem, and it seems to apply for all URN schemes and not
just PDIs, perhaps it would be better to remove the 'fragment
identifier' component from the PDI spec?

Larry

Date: Tue, 11 Nov 1997 03:01:27 -0500
To: Larry Masinter <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: Re: [URN] URN-PDI Issues
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

At 11:24 PM -0800 97-11-10, Larry Masinter wrote:
>John,
>
>Hytime claimed to handle these kinds of issues. Why are you
>proposing something different?

Larry,

This is pretty vague.  Would you care to be specific and constructive?
Specific issues with references and suggested text changes would be most helpful. 
Please separate your concerns with URNs from concerns with PDIs. 

The PDI namespace has been in use since 1994 with a document set numbering
over 12,000 that is distributed world-wide and replicated in many locations.
This draft is intended as an informational RFC to document practice,
prepare us for resolving PDIs  using emerging URN discovery and resolution standards,
and  extending the PDI namespace to meet our current requirements.  The implementation 
will go live in the near future. Further, we intend to deploy an assertion framework
to complement the PDI namespace thereafter.

Date: Mon, 10 Nov 1997 23:24:43 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "John C. Mallery" <[email-masked]>
CC: [email-masked]
Subject: Re: [URN] URN-PDI Issues
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

John,

Hytime claimed to handle these kinds of issues. Why are you
proposing something different?

Larry

Date: Tue, 11 Nov 1997 00:32:25 -0500
To: [email-masked]
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URN-PDI Issues
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Just to start the ball rolling, here is my list of outstanding issues for
the URN-PDI draft. Solutions solicited.
--------------------------------------------------------------------
11/10/97 OUTSTANDING ISSUES: draft-mallery-urn-pdi-00.txt

A. Text Fragments/ Media Types

        1. Explicate multibyte character sets in text documents.
        [Choice of representation for fragments can imply translation
        problems in the future,eg UTF-7). Explain tradeoffs.]

        2. Dynamic CRLF conversion by clients. R. Daniel.  Argument is
        that the spec describes only CRLF. Implementations may deviate
        but MUST provide all data, references, digital signatures in
        the canonical form.

B. Temporal Hierarchicalization

        1. How do we describe different time ranges in hierarchical
        date?  Universal time? Do we need a means for finer temporal
        granularity.

        2. How do we tell URN discovery systems about chronological
        delegation?  Regular Expressions don't do numeric comparisons.

C. Resolution

        1. What guarantees does the resolver make concerning whether
        the version of the PDI is the newest one anywhere?

        2. Define primary resolvers that are authoritative with regard
        to a document series. Consider three categories of resolvers:
        primary, caching resolvers, local replicas.

        3. How do we assure that URN resolvers

Date: Mon, 10 Nov 1997 19:14 -0500
From: "John C. Mallery" <[email-masked]>
Subject: [URN] PDI Namespace Draft
To: [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Below is a copy of the PDI namespace spec that I have just submitted as an
internet draft. I would appreciate comments and suggestions from this working
group to improve the document.

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

Internet-Draft                                           J. C. Mallery
draft-mallery-urn-pdi-00.txt                             M.I.T.
Expires in six months                                    November 10, 1997

                  Persistent Document Identifiers
                  Filename: draft-mallery-urn-pdi-00.txt

Status of This Memo

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

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

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

Abstract

   This document specifies the syntax and semantics of the Persistent
   Document Identifier (PDI) namespace within the URN framework
   defined by RFC 2141 [17]. PDIs provide a means to refer to digital
   objects and fragments that does not depend their storage location
   or the protocol used to access them. Since 1994, several
   large-scale applications with these requirements have used PDIs
   [12] [21].

   PDIs are intended primarily as permanent identifiers for archival
   reference to long-lived documents.  PDIs have a fragment syntax to
   allow permanent references to parts of documents (within specific
   formats) as well as a citation syntax to allow references to
   appearances of such fragments in composite documents.

   PDIs are most useful for any document series that is distributed via
   multiple protocols, is available from multiple sources, migrates to
   new locations, needs fragment references, or participates in
   distributed assertion semantics related to collaboration or access
   control.
  
1. Namespace Syntax

1.2 Design Goals
   
   Persistent Document Identifiers provide a means to refer to digital
   objects and fragments that does not depend their storage location
   or the protocol used to access them.  PDIs offer the following
   capabilities:
   
        * Multisourcing: The same resource can be stored in different
        locations yet retrieved by a virtue of a shared identifier.

        * Multiple Protocols: Identifiers are not tied to specific
        transport protocols.

        * Persistence: PDIs persist across relocation of a digital
        object to different storage sites. The longevity of a PDI is
        not limited by lifetime of a directory, domain name, or even,
        a transport protocol.

        * Organizational Delegation: PDIs define a hierarchical
        encoding of the issuing authority that allows delegation in a
        manner analogous to names in the Domain Name System names but
        more akin to X.400.

        * Chronological Delegation: PDIs incorporate a time hierarchy
        that allows delegation of identifiers with different time
        ranges to different authorities or to different resolution
        regimes.

        * Fragment Syntax: PDIs offer an extensible syntax for
        referring to part of a resource. This evolutionary approach
        allows different schemes according to media type as well as
        multiple schemes per media type. Longevity of reference is
        sought by defining fragment schemes that are independent of
        machine representation. Referential consistency is guaranteed
        by monotonic commitment of versioned PDIs to immutable
        resource representations.

        * Citation Syntax: PDIs include a syntax for referring to
        appearances of document fragments as quoted in other composite
        documents. This makes fragment quotations first-class objects,
        about which assertions can be made.

        * User Friendly: PDIs carry a relatively simple syntax with
        some mnemonics so that, if need be, people can type them to
        access a resource.
   
   A guiding design principle for PDIs is to minimize the document
   semantics carried within the identifier.  Most semantics is better
   encoded by assertions about PDIs. Not only is overloading of the
   identifier avoided, but assertions can also be modified without
   recourse to changing the identifier.

1. Namespace Syntax

   Consistent with the URN syntax specification in RFC 2141 [17], each
   namespace must specify syntax related information that is specific to
   that namespace.  This section provides these specifications for the
   PDI namespace. The PDI grammar below uses the ABNF [6]. A URN using
   the Persistent Document Identifier namespace has the form:

        <URN> = "urn:" pdi              ; Encoding in URN syntax

1.1. Namespace Identifier (NID)

   The Namespace Identifier for this namespace is "pdi", which is case
   insensitive.

        <PDI> = "pdi" ":" nss           ; Persistent Document Identifier

1.2. Namespace Specific String (NSS)

   The Namespace Specific String for this namespace is:

        <NSS> = resource-identifier [(citation-specifier / fragment-specifier)]

1.2.1 Resource Identifier

        <RESOURCE-IDENTIFIER> = "//" document-series "/" iso-date "/" specifier

        <DOCUMENT-SERIES> = component *["." component] "." iso-country

        <COMPONENT> = alpha-hyphen-digits

        <ISO-COUNTRY> = 2*alpha                 ; See ISO Standard 3166 [10]

        <ISO-DATE> = year "/" month "/" day

        <YEAR> = 4*digit / wildcard

        <MONTH> = 2*digit / wildcard

        <DAY> = 2*digit / wildcard

        <SPECIFIER> = unique-id ["." format ["." version]] ;versions require formats

        <UNIQUE-ID>  = daily-serial-number / encapulated-unique-id / digits / 
                         wildcard

        <DAILY-SERIAL-NUMBER> = digits

        <ENCAPULATED-UNIQUE-ID> = unique-id-chars

        <UNIQUE-ID-CHARS> = alpha / digit / other / "%" hex hex

        <FORMAT> =  media-type-token / wildcard

        <MEDIA-TYPE-TOKEN> = "text" / "html" / extension-token

        <EXTENSION-TOKEN> = alpha-hyphen

        <VERSION> = digits / wildcard

        <WILDCARD> = "*"

1.2.2 Citation Specifier

        <CITATION-SPECIFIER> = "@" origin-position "=" pdi

        <ORIGIN-POSITION> = position

1.2.3 Fragment Specifier

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

        <FRAGMENT-SCHEME> = "char" / "elt" / "name" / "rect" / "msec" / "sec" / 
                              "crop" / "byte" / ext-fragment-scheme

        <EXT-FRAGMENT-SCHEME> = alpha-hyphen

        <POSITION> = char-position / element-position / element-name / 
                       2-dim-coordinate / frame-number / time / byte-position / 
                       ext-position

        <EXT-POSITION> = position-specifier / 
                           "(" position-specifier  *["," position-specifier] ")" 

        <POSITION-SPECIFIER> = alphadigits

1.2.4 Supporting Definitions

        <ALPHA> = %x41-5A / %x61-7A                     ; A-Z / a-z

        <ALPHA-DIGITS> = alphas / digits

        <ALPHA-HYPHEN-DIGITS> = alpha-hyphen / digits

        <ALPHA-HYPHEN> = alpha / "-"

        <ALPHA-HYPHENS> = *alpha-hyphen

        <ALPHAS> = *ALPHA

        <DIGIT> = %x30-39                               ; 0-9

        <DIGITS> = *DIGIT

        <URN-CHARS> = trans / "%" hex hex               ;RFC 2141

        <TRANS> =  alpha / digit / other / reserved

        <HEX> = digit / "A" / "B" / "C" / "D" / "E" / "F" /
                        "a" / "b" / "c" / "d" / "e" / "f"

        <OTHER> = "(" / ")" / "-" / ":" / ";" / "$" / "_" / "!" / "'"

        <RESERVED> = "%" / "." / "," / "/" / "#" / "*" / "@" / 
                     "=" / "?" / "+"

1.2.5 Reserved Characters

   <RESERVED> are used as special characters in the PDI grammar. They
   MUST be encoded according to the character escaping method
   described in RFC 2141 [17].

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

   The encoded date in <ISO-DATE> is the date when the identifier is
   minted. This date is based on Greenwich meantime. The encoded date
   bears no relationship to dates associated with the resource that the
   PDI denotes, even if there may be proximity between the time when the
   resource issues and the time when the PDI is minted.

   The PDI namespace is monotonic; PDIs cannot be retracted. If a new
   version of the same document issues, it MUST increment the version
   number for the previously issued PDI. This requirement assures that
   any machine representation (byte sequence) associated with formats
   of a versioned PDI never changes.

   Byte equivalence for all resource formats denoted by a specific PDI
   version ensures that digital signatures associated with a PDI check
   for any uncorrupted resource. More significantly, byte equivalence
   enables reliable, efficient fragment references for many media types.
   It eliminates the potentially difficult problem of rolling fragment
   references forward as a target resource is modified.
  
2.2 Issuing Authority
   
   The issuing authority controls the name in a document series. These
   names are hierarchical so that administration can be delegated within
   authority domains. Unlike domain names, the right most component of a
   <DOCUMENT-SERIES> MUST be a two digit ISO 3166 country code [10],
   indicating the country in which the issuing organization resides.  In
   most cases, a <DOCUMENT-SERIES> SHOULD add a term to the issuing
   authority in order to differentiate the series from other document
   sets that the authority might issue. By specializing the document
   series below the issuing authority, identifiers reflect the chain of
   delegation.  Additionally, it becomes easier to obsolesce an entire
   document series, if that becomes necessary.

   For wide use of PDIs, an issuing authority will need to issue
   toplevel authority names to organizations wishing to mint PDIs in
   their own document series. Once a toplevel document series name has
   been obtained, an organization may issue PDIs itself or delegate
   subseries. 

   A subseries is delegated by adding a name component to the left of
   <DOCUMENT-SERIES>. The accretion of components on a document series
   MAY utilize existing organizational names or acronyms whenever
   feasible in order to preserve mnemonics in the document series
   name. Additionally, dropping components from the left SHOULD lead
   to ever more general issuing authorities in terms of organizational
   scope.

   Delegation SHOULD follow de jure organizational structure. Issuing
   authority SHOULD NEVER be delegated outside the organization unless
   the external agent is acting directly on behalf of the document
   series owner. When organizational boundaries are crossed, a new
   document series toplevel SHOULD be acquired. Within an organization,
   issuing authority SHOULD be delegated to the level where
   responsibility for content resides. This facilitates contact with
   document originators. More importantly, it reduces administrative
   scope, and thus, encourages more uniform document management policies
   for a particular document series.
   
2.3 Hierarchical Date
   
   <ISO-DATE> of a PDI MUST be assigned when the identifier is minted.
   The calendar date MUST correspond to Greenwich Mean time. 

   Inclusion of the ISO date conveys the time when the identifier was
   minted.  Beyond making it easier to guarantee identifier uniqueness,
   hierarchicalization by date enables reference to ranges of
   identifiers issued within specific time intervals.

   Use of ISO dates also ensures that lexical sorts of identifiers
   produce a chronological ordering of PDIs, making various listings
   (e.g., directory lists) automatically appear in a meaningful
   order.

   Moreover, different administrative policies MAY be applied to any
   particular time interval.  For example, when responsibility for
   resolving PDIs shifts to a different administrative authority,
   intervals covered by the new policy are readily specifiable and
   conveyed. For example, different intervals may be delegated to
   different URN resolvers and these delegations recorded with
   relevant URN discovery systems.

   Operations may be applied to identifiers within an interval. For
   example, a browser can provide a directory list of all the
   documents in a year, a month, or on a day.

   More generally, assertions can be made about identifiers within an
   interval, such as where to find a resolver.

2.4 Daily Unique ID

   An application may use a mnemonic name or a serial number as the
   <UNIQUE-ID>. The only requirement is that <UNIQUE-ID> MUST be a
   unique sequence of <UNIQUE-ID-CHARS> for <ISO-DATE> and
   <DOCUMENT-SERIES>.
   
   If the unique ID is a <DAILY-SERIAL-NUMBER>, serial numbers SHOULD
   start from 1 and SHOULD be incremented by 1 as each new PDI is
   minted. When the calendar day is incremented at midnight GMT, the
   unique ID of the day SHOULD be reset to start at 1 on the new day.
   This prevents daily unique IDs from growing very large as it
   enforces date semantics on the identifier.
   
2.4.1 Encapsulation of Foreign Identifiers

   The specification of this field has been left open so that foreign
   document identifiers MAY be incorporated within a PDI as the daily
   unique ID. For our purposes, a foreign identifier is any identifier
   used by other naming or reference regimes.  Examples of foreign
   identifiers include, serial numbers, invoice numbers, URIs, URLs or
   other application-specific identifiers.

   When encapsulating a foreign identifier, <FORMAT> is required and
   MUST use a <MEDIA-TYPE-TOKEN> that identifies the media type of the
   resource and format of the encapsulated identifier. The media type
   token is required in order to allow unambiguous interpretation by
   applications aware of the identifier semantics. All other
   applications, MUST treat the unique id as opaque.
   
2.5 Format
   
   Format should use standard, controlled terms that indicate the
   media type [3] of the resource to which the identifier refers or,
   in the case of encapsulated identifiers, indicate the type of the
   encapsulated identifier. <FORMAT> is case insensitive.

   The standards for MIME content types [10] do not as yet provide a
   single controlled term per media type that can be used as a file
   extension or here as a PDI format. Below we provide a rule for
   constructing the <MEDIA-TYPE-TOKEN>. These tokens are created from
   the registered media types [10] by using the <MINOR-TYPE> if it is
   unique, or otherwise, concatenating the <MAJOR-TYPE> and
   <MINOR-TYPE>. These tokens are case insensitive and MUST encode any
   reserved characters (<RESERVED>) for PDIs.

        <CONTENT-TYPE> = major-type "/" minor-type 
                           [* (";" parameter ["=" value])]

        <MEDIA-TYPE-TOKEN> = minor-type / (major-type "+" minor-type)

        <MAJOR-TYPE> = alpha-hyphen-digits

        <MINOR-TYPE> = alpha-hyphen-digits

   There are two media types for which <MEDIA-TYPE-TOKEN> is not
   <MINOR-TYPE>:

        Token           Content Type

        text            text/plain
        header          message/header          ;RFC 822 message headers

   <FORMAT> is always required when:
   
      * A PDI is minted and assigned to a specific resource.
      * A foreign document ID is encapsulated in <UNIQUE-ID>.
      * References to resource fragments are made.
      * A client requests a resource in a specific format.

   The format indicates how to interpret encapsulated identifiers and
   MUST be supplied whenever foreign document identifiers are
   encapsulated. For example, if an HTTP URL was encapsulated, the
   PDI might look like:

   pdi://oma.eop.gov.us/1994/10/20/http%3a%2f%2fwww%2ewhitehouse%2egov%2f.html.1

   This PDI encapsulates the URL http://www.whitehouse.gov/ and denotes
   its content on October 20, 1994, when the site was unveiled.
   
   When a PDI contains fragment syntax, a format MUST be provided in
   order to convey the media type of the resource to which the
   fragment reference applies.

   A server may store any subset of formats for a resource. It may
   compute unstored formats on demand. A client can specify the desired
   format by using a PDI with the appropriate format field.

   If format is omitted, the identifier refers to the generic resource
   denoted by the PDI. Assertions about the generic resource apply to
   all the instantiations in the various media types indicated by the
   universe of format in which the resource is available.

2.6 Version

   The PDI <VERSION> is an optional component indicating a specific
   version of a resource. <VERSION> is a positive integer greater than
   0. When <VERSION> is omitted, it defaults to version 1. 
   
   Version numbers refer to the generic resource and not the specific
   format, but a resource cannot have a version without having at
   least one format. When a resource is changed in any format, version
   numbers for all formats MUST be updated. In general, when a
   resource changes significantly, applications SHOULD generate new
   PDIs. When changes are small or incremental, applications SHOULD
   increment the version. Any change in the byte count of a resource
   for a specific <FORMAT> is a change and the version SHOULD be
   incremented. Addition of a new <FORMAT> with the same semantics as
   an existing <FORMAT> for the PDI is not a change and does not
   require the version to be incremented.

   Consequently, if an HTML document issues under

                 pdi://oma.eop.gov/1997/09/01.html.1

   ,and later, the HTML is converted to text, the PDI for the text
   version is

                 pdi://oma.eop.gov/1997/09/01.text.1

   However, if a spelling mistake is corrected later, whether or not
   it changes the byte count in any format, the version number is
   incremented.

                pdi://oma.eop.gov/1997/09/01.text.2
   
   An editing application MAY write internal versions of a document in
   progress and only commit to the versioned PDI at a point when the
   editing completed and the document is ready for release.

   Version numbers MUST be included when:

        * PDIs are minted and associated with specific resources.
        * PDIs contain a fragment references.
        * PDIs contain a fragment citation.

   Inclusion of a <VERSION> in a fragment references ensures that the
   fragment reference is resolved against a consistent machine
   representation of the resource.

3 Fragment Syntax

3.1 Motivation

   The PDI namespace provides an extensible syntax for referring to
   parts of resources. Fragment syntax must be extensible because:

        * There are too many existing media types.

        * Some media types require highly technical fragment syntax,
        (e.g., multidimensional points, multiresolution channels).

        * New media types are coming into existence all the time.

   The approach adopted here is to allow additional RFCs to extend
   fragment syntax by adding fragment specifiers as they are needed.

   The availability of a syntax for referring to resource fragments
   raises the problem of referring to citations of fragments by
   composite resources. The PDI namespace provides a fragment citation
   syntax to address this issue.

3.2 Philosophy

3.2.1 Media Representations

   A fragment syntax SHOULD differentiate the media representation from
   the machine representation. If fragment schemes for a particular
   media type use a media representation, they can be retargeted at new
   or different machine representations. Otherwise, fragment schemes may
   become unresolvable in the future when machine representations
   change. Consequently, although a byte fragment specifier is provided
   below, it SHOULD be used only for short-term purposes when
   alternatives are unavailable.

3.2.2  Immediate Fragments

   URNs require a fragment syntax because the alternative of interning
   every fragment PDI in a URN namespace does not scale. It requires
   the resolver to store potentially all possible permutations of the
   fragment specifier for every resource.  Immediate fragments require
   the fragment syntax to be part of the identifier.  With immediate
   fragments, resolvers need only store those fragment PDIs for which
   there are assertions beyond the binding to the resource subset.
   Additionally, immediate fragments enhance privacy by not storing
   all references to resource subsets. They also conserve storage and
   reduce computation on resolvers.

3.2.3 Fragment Conjunctions

   The fragment syntax does not support conjunctions of fragments
   because this introduces a source of ambiguity when assertions are
   made about PDIs.  Conjunctive fragments SHOULD be handled by creating
   a new PDI and asserting that it is the conjunction of some fragments.
   In this way, the set is explicitly represented and ambiguous
   references are excluded from the syntax.

3.2.4 Decoupling from Reference Mechanics

   Fragment reference could be accomplished by providing a program
   that given a resource return the specified part.  This is not the
   approach advocated here. The fragment scheme MUST be a minimal set
   of parameters required for a program to extract the relevant part.
   Additionally, these parameters SHOULD be specified in the order of
   importance for extracting the referent. This increases the
   probability of finding a referent if an identifier is accidently
   truncated. In general, new fragment specifiers SHOULD minimize the
   syntax the of invariants and parameters they require.

3.3 Fragment Scheme

   The <FRAGMENT-SCHEME> indicates the position syntax used in
   <POSITION>.  A default position scheme should be defined for each
   Content Type token used in PDIs. For example, text/plain uses
   character positions as the default.  The <FRAGMENT-SCHEME> MAY be
   omitted when it is the default position scheme for the content type
   indicated by <FORMAT>. In all other circumstances,
   <FRAGMENT-SCHEME> MUST be supplied in order to ensure unambiguous
   interpretation of position specifiers. Position schemes are case
   insensitive.

3.4 Fragment Specifiers

   The following position reference schemes have been defined:
         
3.4.1 Text Fragment Specifier

   Text fragments are defined for the MIME Content Type text/*.  Each
   text fragment is an interval bounded by two character positions in
   the resource. The fragment is the set of characters from <START>
   upto but excluding <END>. The first character position starts with
   0.  Character positions are relative to the canonical,CRLF encoded
   text for the resource.  Therefore, all text/* resources MUST be
   CRLF encoded to ensure correct fragment references.  The PDI
   <FORMAT> for text/plain is "text" and <CHAR-FRAGMENT-SPECIFIER> is
   the default position specifier for the media type.

        <CHAR-FRAGMENT-SPECIFIER> = "#" ["char" "="] start-char 
                                        "," end-char

        <START-CHAR> = digits

        <END-CHAR> = digits

   Although wide-spread encodings for many alphabets use a single 8 bit
   byte (e.g., ISO-8859 [15]), other encodings (e.g., unicode) employ
   multi-byte encodings. Consequently, a server MUST be aware of the
   character set used to encode a text resource.  For 8 bit character
   sets, char fragment resolution reduces to byte position.  However,
   multi-byte character sets require the server to perform appropriate
   translation from the stored data representation.

   The following PDI refers to the text starting at character 37 and
   continuing upto but excluding character 51.

            pdi://oma.eop.gov.us/1997/09/01/1.text.1#char=37,51

   Since the default fragment specifier for text is
   <CHAR-FRAGMENT-SCHEME>, the following PDI is equivalent:

            pdi://oma.eop.gov.us/1997/09/01/1.text.1#37,51

   When a text/plain content type uses a multi-byte character set,
   <FORMAT> MUST be the character set token as defined by the IANA
   Character Set Registry [18].

3.4.2 HTML Fragment Specifier

   Fragments may be specified for the MIME Content Type text/html using
   character fragment specifiers. The PDI <FORMAT> for text/html is
   "html".  The default position specifier for text/html is "char"
   because it simplifies serving fragments.

   Although character references are simple and effective for HTML
   document fragments, it is often more convenient to use HTML
   elements to delimit an interval within a document.  Specific HTML
   elements can be identified using the name parameter value or the
   position of the tag in the document. In either case, the fragment
   consists of all text and HTML tags from <START-ELEMENT> to and
   including <END-ELEMENT>.  References to HTML containers is
   facilitated by use of a closed interval, but it can be awkward for
   tags that are not explicitly closed, especially if they are
   implicitly closed (e.g., <p>). Tag positions are counted from the
   start of the resource, with the first being assigned 0. An
   <ELEMENT-NAME> refers to the first element whose name parameter
   value is equal to <ELEMENT-NAME>, which must be encoded according
   to URN syntax [17], but decoded for case-sensitive equality testing.

        <HTML-FRAGMENT-SPECIFIER> = "#" start-element "," end-element

        <HTML-FRAGMENT-SCHEME> = char-fragment-scheme / 
                                  element-fragment-scheme / 
                                  named-fragment-scheme

        <ELEMENT-FRAGMENT-SCHEME> = "elt"

        <START-ELEMENT> = element-position / element-name

        <END-ELEMENT> = element-position / element-name

        <ELEMENT-POSITION> = digits

        <NAMED-FRAGMENT-SCHEME> = "name"

        <ELEMENT-NAME> = urn-chars

   Char, elt, and name position references MUST use the same position
   scheme for <START-ELEMENT> and <END-ELEMENT> an HTML fragment
   reference.

   HTML fragments may depend on surrounding context that is not part
   of the fragment. HTML rendition without this containing context may
   produce different effects or incorrect HTML. Responsibility for
   assuring legal and felicitous HTML must reside with the user or
   application creating the fragment reference because document
   authors cannot be expected to anticipate all possible citations.
   Therefore, the user or application creating the fragment citation
   MUST NOT create illegal HTML fragments.  

   When fragments require context, the user or application MAY create
   an intermediate document that uses fragment references to extract
   both the relevant context and the target fragment.  This
   intermediate document SHOULD be legal HTML capable of standing
   alone.

3.4.2 SGML & XML Fragment Specifier

   The element and char fragment schemes can be applied to the more
   general Standard Generalized Markup Language (SGML) [14] and
   Extensible Markup Language XML [4] mark up languages, of which it
   is a subset.  The BNF below give the fragment specification for
   SGML and any subsets, such as XML.

        <SGML-FRAGMENT-SPECIFIER> = "#" sgml-start-element "," 
                                        sgml-end-element

        <SGML-FRAGMENT-SCHEME> = element-fragment-scheme / 
                                 char-fragment-scheme

        <SGML-START-ELEMENT> = element-position

        <SGML-END-ELEMENT> = element-position

   The default fragment specifier for SGML and SGML subsets is "char".
   The following content tokens are defined:

        text/sgml               sgml
        text/xml                xml

   The context caveats for HTML fragments should be extended pari pasu
   to SGML and XML fragments.

3.4.5 Image Fragment Specifier

   Image media types use a variety of encoding schemes and some
   include multiple frames. Fragment reference for image/* uses a two
   dimensional cartesian coordinate system with the origin (0, 0) being
   in the upper left hand corner. The scale of the coordinate system is
   the pixel level scale of the containing image. References to
   subrectangles are made by specifying for the image fragment the
   <START-COORDINATE> as the upper left most point and <END-COORDINATE>
   as the lower right most point. These x and y coordinates are in
   coordinate system of the containing image. When multiple frames are
   present in an image, the reference frame is specified by providing
   <FRAME>, which is 0 based and defaults to 0 when omitted.
   <RECTANGLE-FRAGMENT-SPECIFIER> is the default fragment specifier for
   the media types image/*.

        <RECTANGLE-FRAGMENT-SPECIFIER> = # ["rect" "="] start-coordinate 
                                           "," end-coordinate ["," frame]

        <FRAME> = digits

        <START-COORDINATE> = 2-dim-coordinate

        <END-COORDINATE> = 2-dim-coordinate

        <2-DIM-COORDINATE> = "(" x-coordinate "," y-coordinate ")"

        <X-COORDINATE> = digits

        <Y-COORDINATE> = digits

   The example below refers to an image fragment whose origin is x=5,
   y=10 and extends to x=25, y=30. This yields the maximal rectangle
   including the coordinates (5,10), (24,10), (24,29), (5,29). Note that
   the zero-based coordinate system does not include the point denoted by
   the <END-COORDINATE>.

        pdi://images.satellite.nasa.gov.us/1997/09/30/1234.gif#(5,10),(25,30)

   Since frame is unspecified, it defaults to zero and this PDI is equivalent to
   
        pdi://images.satellite.nasa.gov.us/1997/09/30/1234.gif#(5,10),(25,30),0

   The next PDI refers to the third frame in an animated GIF. As it
   simplifies array references, the zero-based index shifts references
   to the left by 1.

        pdi://images.satellite.nasa.gov.us/1997/09/30/1234.gif#(5,10),(25,30),2
   
3.4.4 Audio Fragment Specifier 

   Audio media types use various encoding schemes (including variable
   quality) that make byte ranges problematic for fragment references.
   Start and end times provide a coordinate scheme that can be resolved
   for any audio media type. A fragment reference includes data from and
   including <START-TIME> upto and excluding <END-TIME>. The position
   scheme for the temporal reference gives the time units. Two time
   position schemes are defined. "msec" is millesconds and "sec" is
   seconds.  Temporal position schemes MUST NOT be intermixed. The
   default time position scheme for audio/* is "sec".
   <TIME-FRAGMENT-SPECIFIER> is the default fragment specifier for
   audio/*.

        <TIME-FRAGMENT-SPECIFIER> = # time-position-scheme "="
                                      start-time "," end-time

        <TIME-POSITION-SCHEME> = "msec" / "sec" / 
                                      ext-time-position-scheme

        <START-TIME> = time

        <END-TIME> = time

        <TIME> = digits

        <EXT-TIME-POSITION-SCHEME> = alpha-hyphen-digits

   The example below denotes the audio clip extending from second 23
   upto but not including second 57.

        pdi://audio.npr.org.us/1997/09/30/1234.au#sec=23,57 

3.4.5 Video Fragment Specifier

   Video media types combine difficulties similar to those presented by
   audio and image media types.  A simple syntax for video should allow
   fragment references to video by start and end times. Because some
   applications may wish to crop the image, an optional x-y coordinate
   framework is also supported.

   The video fragment specifier uses a required time component and an
   optional pair of coordinates to denote cropping. A video fragment
   reference includes data from and including <START-TIME> upto and
   excluding <END-TIME> in time units given by <TIME-POSITION-SCHEME>.
   
   When cropping is desired, a fragment may include the optional
   <START-COORDINATE> and <END-COORDINATE>.

        <VIDEO-FRAGMENT-SPECIFIER> = # "crop" "=" time-position-scheme 
                                       "," start-time "," end-time 
                                       ["," start-coordinate "," end-coordinate]

   The following example refers to seconds 23 upto 51 of the video clip
   1234.mpeg.

        pdi://video.cnn.co.us/1997/09/30/1234.mpeg.1#sec,23,51

   The next PDI uses the crop fragment scheme and is equivalent to the
   preceding one because no cropping is specified.

        pdi://video.cnn.co.us/1997/09/30/1234.mpeg.1#crop=sec,23,51

   However, the crop scheme is easily able to specify a cropping, such
   as the one below.

        pdi://video.cnn.co.us/1997/09/30/1234.mpeg.1#crop=sec,23,51,(10,10),(20,20)

   Here, only the rectangle from origin (10,10) to (20,20), the right
   lowest point, is included in the fragment.

   The video fragment scheme presupposes a pixel-based imaging model.
   For other models, such as line-oriented analog video, specialized
   fragment schemes may be appropriate when cropping is desired.  Note
   that the time fragment scheme works for analog models. For this
   reason, the time position scheme <TIME-FRAGMENT-SPECIFIER> is the
   default fragment specifier for video/*.
   
3.4.6 Octet Fragment Specifier

   In general, long-lived fragment specifiers seek to avoid schemes
   that depend on the underlying data representation because of low
   generality and high probably of future failure when the data
   representation is obsolesced by future developments.  The byte
   fragment scheme is provided as short-term solution that SHOULD be
   superseded by defining a new fragment specifier. In any event, byte
   fragments provide a fallback scheme for use until a new extension
   can be introduced.

   The content token for <BYTE-FRAGMENT-SPECIFIER> is "byte". The
   fragment includes <START-BYTE> and all intervening bytes upto
   <END-BYTE> which is excluded from the fragment reference.

        <BYTE-FRAGMENT-SPECIFIER> = "#" "byte" "=" start-byte "," end-byte

        <START-BYTE> = digits

        <END-BYTE> = digits

   The fragment PDI below refers to the byte sequence starting with byte
   23 and continuing upto but excluding byte 57. 

        pdi://documentation.adobe.co.us/1997/09/30/1234.pdf#byte=23,57

   These byte indices are compatible with byte ranges used in HTTP 1.1
   [9].

3.5 Fragment Citation

3.5.1 Motivation

   Once fragments can be specified, documents can move from a
   cut-and-paste model to an inline reference model, where the
   fragment is served from an origin site.  Composite documents are
   those that combine fragments using inline references. One reason
   for preferring inline fragment references to cut-and-paste is that
   the etiology of the fragment is preserved. Thus, meta-data such as
   digital signatures can be carried forward and a document consumer
   can easily follow references back to sources to examine original
   contexts.

   An example might be citing some sentences from Presidential policy
   speech in a decision memorandum. Authenticity can be checked
   because the original document and its digital signature are
   available.  But, what if the citation was out of context?  Someone
   else could use the citation syntax to refer to the citation of a
   fragment by the composite document and assert that the fragment
   citation was out of context as it built an argument against the
   logic of the decision memorandum.

3.5.2 Discussion
   
   Reference of a fragment as cited in a composite document is
   accomplished by using a position specifier to give the
   <ORIGIN-POSITION> in the composite document. The cited fragment
   begins at the origin position and continues for the full extent of
   the fragment. Thus, <ORIGIN-POSITION> provides the alignment in the
   citing document while the dimensions or extent is carried by the
   fragment reference.  By keeping knowledge of the dimensions of the
   fragment out of the coordinate framework of the composite document,
   any position scheme can use the same generic citation syntax.

   The origin position is defined as the point closest to the start of
   the document. In a media type structured as a single sequence of
   characters, the origin position is character 0.  In a three
   dimensional cartesian coordinate systems, the origin position is
   0,0,0. When each content type token is made available for fragment
   citation, the origin position MUST be defined.

   The following identifier 

   pdi://oma.eop.gov.us/1997/11/03/4.text.1@103=pdi://oma.eop.gov.us/1997/09/01/1.text.1#37,51

   refers to the citation of the fragment

        pdi://oma.eop.gov.us/1997/09/01/1.text.1#37,51

   by the document,

        pdi://oma.eop.gov.us/1997/11/03/4.text.1  

   The citing document PDI uses the fragment text from character 37 to
   51 starting from character 103. If the fragment PDI had no fragment
   specifier, the entire document would appear starting at position 103.

3.6 Operations on PDIs

   The three classes of operations on PDIs have slightly different
   characteristics.

3.6.1 Minting

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

3.6.2 Binding

   Once minted, a PDI can be bound to directly to a resource or
   indirectly via a Uniform Resource Indicator (URI) [2], which may
   often be a URL. Binding to a resource commits the PDI to a specific
   sequence of bytes. Therefore, a URI that is indirectly bound to a
   PDI MUST NOT change. If the URI changes, the indirect binding MUST
   be broken, and the original machine representation associated
   directly with the PDI.

3.6.3 Resolution

   PDIs may be resolved to URLs, or other locators using recent URN
   resolution standards, such as THTTP described by RFC 2169 [10] and
   these resolvers may be discovered using the DNS extensions for
   Naming Authority PoinTeR (NAPTR) described by RFC 2168 [8].  As
   these experimental resolution standards evolve, or new ones are
   introduced, PDI resolution can track any new standards precisely
   because a URN namespace is independent of the method used to resolve
   them.

   When requesting a PDI from a URN resolver, the omission of a
   version number is a request for the resolver to return to the
   highest version available for the PDI. When defaulting a PDI to the
   highest version, the resolver MUST indicate to the client the fully
   qualified PDI associated with the media object.  For THTTP, when a
   server returns an entity, the server MUST include a content
   location header [9] containing the fully-qualified PDI.  This
   allows the client to associate the entity body with the versioned
   PDI that specifically identifies it.

         When submitting a PDI to a URN resolver, wildcards may be used
   to obtain information for sets of PDIs. However, the set of returned
   PDIs MAY be complete only with regard to the specific knowledge about
   a document series available to a resolver at the time.

3.6.4 Lexical Equivalence

   PDIs can be lexically compared for equivalence after they are
   converted to canonical form using the following procedure:

        1.Unescape all escaped characters that are within <URN-CHARS> but which
        are not <RESERVED-CHARACTERS>.

        2. Downcase the two <HEX> characters following the escape character "%".

        3. Downcase all PDI components except <UNIQUE-ID> and <POSITION>.

        4. If it is an encapsulated identifier, canonicalize
        <UNIQUE-ID> according the rules for the foreign identifier.

        5. If <POSITION> is case-insensitive, as indicated by <FRAGMENT-SCHEME>,
        downcase position.

   Wildcards carry a semantic interpretation that is not relevant for
   lexical equivalence. Two PDIs are lexically equal if and only if any
   wildcards appear in exactly the same positions in both.

3.6.5 Assertions

   With the advent of URN standards, networked assertion infrastructures
   can now associate assertions (meta-data) with the unique identifier
   of a resource rather than replicating that information with every
   instance of a resource and creating a variety of synchronization
   problems.  On this view, each URN namespace may also become an
   assertion domain with specific semantics.

   A document series thus becomes an address space in which each PDI
   serves as a pointer. Assertions about PDIs are assertions about the
   digital objects or fragments to which they refer. The ability to make
   and retrieve assertions about PDIs provides a means to associate
   meta-data with digital objects.  For example, collaboration systems
   may use a typed link semantics to structure resources in meaningful
   ways.  Alternatively, security systems may assert digital signatures
   or other trust information about PDIs. For example, a digital
   signature may be attached to some mobile code to check its integrity
   regardless of its proximate source. Access control systems might even
   assert differential access to various components of a single digital
   object.

   Several groups are developing standards for associating meta-data
   with resources [11] [16]. These approaches are currently evolving and
   as yet lack a suitable persistent identifier model.  URNs [17] [19]
   [20] and specifically PDIs offer a suitable persistent identifier for
   use with assertion schemes.  The ability to refer to tokens and
   relations as first-class objects will dramatically simplify equality
   testing and significantly enhance the power and flexibility of the
   emerging standards for wide-area assertion infrastructures.

3.7 Registering New Fragment Specification Schemes

   [TBD: This section will provide rules for registering new fragment
   specification schemes with IANA.]

3.8 Interpreting PDIs as Uniform Resource Locators

   Current URN resolver discovery [8] and URN resolution [7] standards
   are experimental and lack wide deployment.  As these standards
   evolve and become more wide spread, an interim resolution strategy
   using existing servers and clients for HTTP may prove useful.  This
   section defines use of PDIs as URLs [1] with standard HTTP servers.

   PDIs MAY be interpreted as Uniform Resource Locators (URL) and MAY
   be used in contexts where URLs are appropriate, such as with HTTP
   servers. When interpreting PDIs as URLs, PDIs do not carry URN
   prefix.

                <URL> = pdi             ; Encoding in URL syntax
   
   In all other ways, the syntax and semantics of PDIs remains exactly
   the same as under the URN namespace interpretation. However,
   resolver discovery and resolution under the URL interpretation are
   somewhat different.

3.8.1 Resolver Discovery

   While an appropriate resolver for a PDI document series SHOULD be
   found using current standards [8], an HTTP resolver MAY also be
   discovered heuristically by interpreting the document series as a
   domain name and looking up an IP address associated with the name.
   If a PDI-aware HTTP server is operating at the IP address and it
   successfully answers HTTP requests on the document series, then
   assume that a resolver for the document series has been located.

   A client MAY also use new resolver discovery standards as they
   emerge or out of band methods to locate a resolver for a document
   series.

   Since the heuristic discovery method provides no indication
   concerning the completeness or authority of the resolver, server
   operators SHOULD ensure that any server providing PDI resolution
   has complete knowledge of the document series, whether served
   locally or proxied from remote servers.  Thus, if a server can
   resolve one PDI in a document series, the server operator
   guarantees the assumption that the server has sufficient knowledge
   to resolve any PDI in the series. An HTTP 1.1 or higher client MAY
   check whether an HTTP server resolves a PDI document series by
   issuing a HTTP request using the OPTIONS method on the PDI.

3.8.2 Resolution Methods

   Since the HTTP standard [9] provides for use of any URI [2] in HTTP
   requests, no immediate extensions to the HTTP standard are required
   for PDI resolution.  Requests for PDIs are just like requests for
   URLs, except that there are no relative PDIs; the scheme and
   document series MUST always be provided.  Fully-specified PDIs
   allow the server to distinguish PDIs from ordinary URLs using the
   HTTP scheme. Servers SHOULD invoke augmented parsing for PDIs, for
   example, as necessary for fragment resolution.

        <HTTP-REQUEST-LINE> = <method> " " <pdi> " " <http-version> 
                              <crlf>

   HTTP provides a series of methods on URIs. Below we define the
   operations for each method in HTTP 1.1 with respect to PDIs.
        
        GET Resolves the PDI and returns the resource.

        HEAD Returns the meta-data of the PDI as headers.

        OPTIONS Returns the HTTP operations supported for the PDI.

        TRACE returns information on the path to the origin server 
        through proxies.

   Non-idempotent HTTP methods interact with PDI semantics and require
   special handling.

        PUT associates a resource with a PDI. If the PDI already
        exists, the server MUST increment the PDI version number and
        store the resource under this new version. If the PDI does not
        exist, the server SHOULD return 404 "Not Found". If the client
        wishes to assign a new PDI, the PUT request MUST indicate the
        document series by providing a partial PDI:

        <DOCUMENT-SERIES-IDENTIFIER> = "pdi://" document-series "/" 

        When a server receives a <document-series-identifier> as the
        URI in a PUT method, it MUST assign a unique PDI within the
        document series using the current <ISO-DATE>, a daily
        <UNIQUE-ID>, an appropriate <FORMAT>, and a <VERSION> equal to
        1. 

        DELETE is not defined for PDIs as they are long-lived,
        persistent identifiers. An HTTP server MUST return 405 "Method
        Not Allowed".

   When an HTTP method is applied to an unknown PDI, the server MUST
   return 404 "Not Found."

   For all HTTP methods, whenever the server is unable to apply the
   method to an existing resource or to assign a new PDI, it MUST
   return 405 "Method Not Allowed."

3.8.3 Proxying HTTP Resolution

   When a server is proxying PDI operations to an upstream HTTP
   server, it MUST pass through all requests and responses.  The
   server contributes its knowledge of an origin server that can
   resolve the PDI.  A server unable or not wishing to proxy PDI
   operations but aware of a server capable of handling the operations
   SHOULD redirect the client to the PDI-capable server.

3.8.4 Proxying THTTP Resolution

   When the upstream server implements URN resolution, the proxy
   SHOULD perform protocol translation. For THTTP [7], the server
   SHOULD perform the following request translations.

                Request         Proxy Request

                GET <PDI>       GET "/uri-res/N2R?urn:" <PDI>

                HEAD <PDI>      GET "/uri-res/N2C?urn:" <PDI>

   Responses from the THTTP resolver SHOULD be passed through.  For
   HTTP methods other than GET and HEAD, the server MUST return a 405
   "Method Not Allowed"

4. History

   Persistent Document Identifiers (PDI) were developed in early 1994 in
   order to provide persistent, location-independent identifiers for
   electronic publications. PDIs were deployed in Fall, 1994 when the
   second White House Electronic Publications System [21] was brought
   online.  Every document published by the system since January 20,
   1993 now carries a PDI.  An identifier that was independent of
   protocol and transport proved extremely useful in managing this
   document set and resolving delivery failures. The publications server
   currently issues PDIs and resolves them using THTTP URN resolution
   [7].

   The White House publications are an excellent example of documents
   that are monotonic (not subject to revision), widely mirrored, and
   subject to eventual relocation.  Documents are never revised after
   they issue.  Instead, they may be superseded by a corrected versions,
   but corrections are limited to transcription errors.  Many sites
   around the world archive and redistribute the documents.  These
   include major online services, libraries, advocacy groups, government
   entities.  As of March 1996, it was estimated that about one million
   people around the world read at least some part of a document during
   the course of a week.  At the end of an administration, the White
   House ceases to serve a former President's documents and they must be
   relocated to the National Archives, and normally, to his Presidential
   library.  In sum, the White House documents are mirrored in many
   locations from which they may be obtained and the primary document
   repository must move after a period of time.

   Persistent Document Identifiers were also used in an advanced
   experiment in large-scale, asynchronous collaboration during the Vice
   President's Open Meeting on Government Reinvention in December 1994.
   [12] In the Open Meeting, PDIs not only identified resources but they
   also associated a collaboration semantics with resources. A variety
   of meta-data and annotations were attached to resources via PDIs.
   More generally, PDIs were used to build the persistent semantic
   network around resources that allowed arbitrary assertions using
   first-class links, each with their own PDIs. Both the document
   database and the semantic network were mirrored at another site using
   PDIs to align all structures.

5. Acknowledgments
                                                                        
   This specification was improved by comments from Andrew J.
   Blumberg, Mitchell N. Charity, Ron Daniel jr., Henrik Frystyk
   Nielsen, Jerry Saltzar, Karen R.  Sollins, Christopher R.  Vincent.
   This specification was revised and extended from an earlier draft
   dated December, 1994.

   This specification describes research done at the Artificial
   Intelligence Laboratory of the Massachusetts Institute of
   Technology.  Support for the M.I.T. Artificial Intelligence
   Laboratory's artificial intelligence research is provided in part
   by the Defense Advanced Research Projects Agency of the Department
   of Defense under contract numbers MDA972-93-1-003N7 and
   F30602-97-2-0239.

6. References

   [1] T. Berners-Lee, L. Masinter, M. McCahill, ``Uniform Resource
   Locators (URL)'', RFC 1738, December, 1994.
   http://ds.internic.net/rfc/rfc1738.txt

   [2] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource
   Identifiers (URI): Generic Syntax and Semantics", Internet Draft
   (work in progress), November 5, 1997.

   [3] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
   Extensions) Part One: Mechanisms for Specifying and Describing the
   Format of Internet Message Bodies", RFC 1521, September 1993.
   http://ds.internic.net/rfc/rfc1521.txt

   [4] T. Bray, J. Paoli, C. M. Sperberg-McQueen, ``Extensible Markup
   Language (XML),'' World Wide Web Consortium, August, 1997,
   http://www.w3.org/TR/WD-xml

   [5] T. Bray, S. DeRose, ``Extensible Markup Language (XML): Part
   2. Linking,'' World Wide Web Consortium, July, 1997.
   http://www.w3.org/TR/WD-xml-link

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

   [7] R. Daniel, "A Trivial Convention for using HTTP in URN
   Resolution," RFC 2169, June, 1997.
   http://ds.internic.net/rfc/rfc2169.txt

   [8] R. Daniel, M. Mealling, "Resolution of Uniform Resource
   Identifiers using the Domain Name System," RFC 2168, June, 1997.
   http://ds.internic.net/rfc/rfc2168.txt

   [9] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee,
   "Hypertext Transfer Protocol -- HTTP/1.1," RFC 2068, January, 1997.
   http://ds.internic.net/rfc/rfc2068.txt

   [10] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail
   Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
   November, 1996.  http://ds.internic.net/rfc/rfc2048.txt 
   Registered media types can be found at:
   ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types

   [11] R. V. Guha, T. Bray, "Meta Content Framework Using XML," W3C
   Technical Note NOTE-MCF-XML, June, 1997.

   [12] R. Hurwitz, J. C. Mallery, ``The Open Meeting: A Web-Based
   System for Conferencing and Collaboration,'' Proceedings of The
   Fourth International Conference on The World-Wide Web, December 12,
   1995. Also in Web Journal, Winter, 1996, 1(1): 17-36.

   [13] ISO 3166:1988 (E/F) - Codes for the representation of names of
   countries - The International Organization for Standardization, 3rd
   edition, 1988-08-15. ISO 3166 country codes can be found at:
   ftp://ftp.isi.edu/in-notes/iana/assignments/country-codes

   [14] ISO 8879 Information Processing -- Text and Office Systems --
   Standard Generalized Markup Language (SGML), ISO 8879:1986.  For
   the list of SGML entities, consult
   ftp://ftp.ifi.uio.no/pub/SGML/ENTITIES/.

   [15] ISO-8859. International Standard -- Information Processing --
     8-bit Single Byte Coded Graphic Character Sets -- 
     Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
     Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
     Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
     Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
     Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
     Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
     Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
     Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
     Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.

   [16] O. Lassila, R. R. Swick, "Resource Description Framework
   (RDF): Model and Syntax," World Wide Web Consortium, Technical Note
   RDF-Syntax (work in progress), August, 1997.

   [17] R. Moats, "URN Syntax," RFC 2141, May 5, 1997.
   http://ds.internic.net/rfc/rfc2141.txt

   [18] J. Reynolds & J. Postel, ``Assigned Numbers,'' STD 2, RFC 1700,
   October, 1994.

   [19] K. Sollins, "Architectural Principles of Uniform Resource Name
   Resolution," Internet Draft (work in progress), July, 1997.

   [20] K. Sollins, L. Masinter, "Functional Requirements for Uniform
   Resource Names," RFC 1737, December, 1994.
   http://ds.internic.net/rfc/rfc1737.txt

   [21] White House Electronic Publications System,
   http://www.pub.whitehouse.gov

6. Author's Address

   John C. Mallery
   Artificial Intelligence Laboratory
   Massachusetts Institute of Technology
   545 Technology Square, NE43-797
   Cambridge, MA 02139 USA
   Email: [email-masked]
   Phone: 617-253-5966

Date: Fri, 7 Nov 1997 12:15:47 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] URN meeting scheduling
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

FYI, we are currently scheduled to meet on Thursday AFTERNOON in
Washington:

        Thursday, December 11 at 1300-1500 
                (opposite usefor, ip1394, ptopomib, saag, nat)

More agenda details to follow...

Leslie.

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

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

To: Keith Moore <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: draft-fielding-uri-syntax-00 
Date: Wed, 05 Nov 1997 23:10:43 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

I made some minor changes to match the comments received and have
submitted the URI spec as draft-fielding-uri-syntax-00.txt (Nov 05).
As usual, I have created a diff from draft 09 as well; both are
available from

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

....Roy

From: [email-masked]
DATE: 04 Nov 10 12:10:01 AM
TO: [email-masked]
Subject: [URN] Let Us Do Your Bulk Emailing Advertising !!!
Sender: [email-masked]
Reply-To: [email-masked]

LET US DO YOUR BULK MAILINGS!!!

..$250 PER MILLION
..$150 PER 500,000

THE WAY OF THE FUTURE FOR SUCCESS IN YOUR BUSINESS!

Our company will do bulk emailing for your product/service.

Addresses are extracted daily by four of our computers,
which run 24 hours a day 7 days a week, scanning the net
for new addresses.  They are fresh!  Over 36 million
addresses on file.

Our prices start at $150 per 1/2 million mailed. No more
than 2 pages (50 lines), no porn and no foul language.
We do not do targeted mailings at this price.

Targeted mailins start at $200 per 100,000.

There are no lower prices on the net.  Your mailing 
can be done in a matter of hours.  We have 6 computers 
sending and processing messages.  4 more computers 
extracting addresses 24/7.

For the fastest service, cheapest prices and cleanest
mailings call our processing and new accounts office
at 904-282-0945, Monday - Friday 9 - 5 EST.

Large corporate mailings available - ask for details.

Email addresses available on CD, zipped text files.  
If interested, let our office know and will send 
our daily extracted list for only $250.  Available 
on CD are over 30 million for ONLY $250.  Overnight 
delivery $14, priority $5 and regular mail $3. New 
addresses are added daily.  All domains available.
No .edu,.mil and .gov. domains.  Addresses are processed 
to remove any key names and flamers, who have notified 
our company and/or clients.  $100 extra insures you of
new addresses extracted up to 6 months.

To have your name removed, call our processing office.
Any negative responses will be dealt with accordingly.

Date: Tue, 4 Nov 1997 12:46:11 +0100 (MET)
From: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>
To: "Sam X. Sun" <[email-masked]>
cc: urn-ietf <[email-masked]>, URI mailing list <[email-masked]>
Subject: Re: [URN] Re: URN/URL spec issues...
Sender: [email-masked]
Reply-To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>

On Tue, 4 Nov 1997, Sam X. Sun wrote:

> > > One more question though. About the excluded characters. I can see the
> > > reason why ASCII 00-1F and 7F are excluded. But do characters like "<",
> > > ">", and "#" definitely have to be excluded also?
> > 
> > "<" and ">" are used to delimit URIs. If they are not excluded, it's
> > very difficult to know where an URI starts or ends. Also, "<" and ">"
> > are very frequent in HTML. 
> 
> Isn't charactar  "  enough to serve the delimiter purpose? In HTML, the
> real
> delimiter to separate the URL is character ", but not  "<"  or ">" .
> Characters  "<"
> and  ">"  are used to separate the HTML tags. For example, in HTML
> document,
> when a hyperlink is defined as <A HREF="http:my-link" options...>My
> Link</A>, only the http:my-link is the URL, which is delimited by a pair of
> " characters. Characters "<" and ">" are not in the context of URL itself.

Correct. But at one time, there were browsers that accepted
<A HREF="http:my-link>. "<" and ">" are mainly used to delimit
URLs in free text, e.g. as <http:my-link>. And it's very nice if
a system allows you to click links in e.g. a plain text email message.

> >"#" is the delimiter between what gets sent to the server and what 
> >remains at the client for further processing. If this is scheme-specific, 
> >this creates lots of problems.
> > 
> 
> I'm having a hard time to figure the kind of problems it creates. Could you
> be more specific of the problem? 

It's not that a big point, but assume a HTML parser is extracting an URL
reference and then wants to send the URL to a resolving machinery. If
it knows "keep the part after the # for yourself, give the part before
the # to the resolver", it's very easy. If it didn't know that, it
would have to ask the resolver, which would have to decide based on
scheme/protocol. Some browsers may just send all unknown schemes to
a proxy, and so we would need protocol additions so that the proxy
could send back the part after the # (or whatever). Having the #
and only the # for this purpose, and not allowing anything else to
use the # leads to a much nicer architecture.

> I might miss some big point here, and correct me if I'm wrong. But I do
> feel 
> that there is an intention of making the URL/URI specification fitting into
> the 
> "http URL" model. But "http URL" is just A particular scheme under the
> URL family. New schemes should be allowed to come up with their own 
> syntax definition to serve their own purpose, but not have to carry over
> the 
> constraints of other schemes. Even for implementation simplicity, every 
> scheme will have to do its own parsing anyway. Why not allow them to 
> define its own set of reserved/excluded characters?

Well, it's not really that the URL/URI spec is fitted to http.
HTTP and HTML were the first to use URLs, as far as I know,
and made URLs popular. If it were not for HTTP and HTML, nobody
would use URLs. So there is some legacy, and some kind of
right-of-ownership and first-come-first-served.

URLs allow quite a wide range of scheme-specific syntax, but also
have some common concepts that allow generic parsing. But not only
the computer processing aspect is important, also the human user
has to be considered. It would not be too difficult, if it would
be needed, to build an infrastructure that e.g. considered "/"
to have scheme-specific semantics. But now that people are used
to relative URLs, the chances are large that they would make
many mistakes. So having some kind of common syntax has many
advantages.

> >Also, I would like to use this occasion to reiterate my (and many
> >other's) request to put a note into draft-fielding-url-syntax-09.txt
> >to alert readers of the fact that internationalization of URIs
> >is converging towards UTF-8. The IMAP URL and the URN syntax
> >draft are clear evidence of this and can be cited easily.
> >Not putting in such a note would consist a serious negligence
> >to include relevant information. I will be glad to provide the
> >detailled wording.
> >
> 
> I also think using UTF8 as the underlying character set encoding for 
> global naming scheme, like URN, is a good choice. In fact, we specified 
> UTF8 as the character set encoding for the handle system. 

Great!

> On the other hand, "http URL" can and is surviving without a globally
> agreed character set encoding. And the link generally won't break even
> if changed from one character set encoding to another.

"surviving" is the right word here. It works as long as the encoding
stays the same. It definitely doesn't work when the encoding gets
changed. By proposing to use UTF-8, we don't want to force every
http server to change to UTF-8 immediately (or at all). Backwards
compatibility measures have been discussed that will allow an
amazingly smooth transition.

> Currently there're
> tons of non-ASCII URL out there already, and this could make moving "http
> URL" into UTF8 very difficult.

No, it turns out that it's not very difficult. The key is that UTF-8
has a very particular structure, and therefore is easy to detect,
and that the namespace on a server is extremely sparsely populated.
I can point you to some papers of mine that discuss this.

> Besides, UTF8 is not readable for most other
> languages other than ASCII, and this may not make it acceptable for people,
> say, using CJK or Greek. It's might be more appropriate to let "http URL"
> will have their character set encoding information carried with them,
> either embedded in the HTML context, or by switching the encoding setup
> from the browser.

It is true that if you take a non-ASCII URL, encode it as UTF-8, and then
insert the resulting octets into e.g. a Greek document (iso-8859-7), that
will look ugly or even worse, will get an editor or browser confused.
But that's not what we are proposing. Whatever characters the URL
contains, these characters are encoded in the same way as the rest of
the characters in the document. For Greek characters in an iso-8859-7
document, these can be encoded as single octets, and then will be
nicely readable. If it is a HTML document, other characters can be
included by using numeric character references (the &#dddd; things),
for all characters from Unicode/ISO 10646. Where UTF-8 comes into
play is where %HH escaping is needed, or when the URL or part of it
is sent to the server.

Regards,	Martin.

From: "Sam X. Sun" <[email-masked]>
To: "=?ISO-8859-1?Q?Martin_J._D=FCrst?=" <[email-masked]>
Cc: "urn-ietf" <[email-masked]>, "URI mailing list" <[email-masked]>
Subject: Re: [URN] Re: URN/URL spec issues...
Date: Tue, 4 Nov 1997 01:49:28 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

> > One more question though. About the excluded characters. I can see the
> > reason why ASCII 00-1F and 7F are excluded. But do characters like "<",
> > ">", and "#" definitely have to be excluded also?
> 
> "<" and ">" are used to delimit URIs. If they are not excluded, it's
> very difficult to know where an URI starts or ends. Also, "<" and ">"
> are very frequent in HTML. 

Isn't charactar  "  enough to serve the delimiter purpose? In HTML, the
real
delimiter to separate the URL is character ", but not  "<"  or ">" .
Characters  "<"
and  ">"  are used to separate the HTML tags. For example, in HTML
document,
when a hyperlink is defined as <A HREF="http:my-link" options...>My
Link</A>, only the http:my-link is the URL, which is delimited by a pair of
" characters. Characters "<" and ">" are not in the context of URL itself.

This said, it is still not quite clear to me why characters "<" and ">"
have to be
excluded?

>"#" is the delimiter between what gets sent to the server and what 
>remains at the client for further processing. If this is scheme-specific, 
>this creates lots of problems.
> 

I'm having a hard time to figure the kind of problems it creates. Could you

be more specific of the problem? 

I might miss some big point here, and correct me if I'm wrong. But I do
feel 
that there is an intention of making the URL/URI specification fitting into
the 
"http URL" model. But "http URL" is just A particular scheme under the
URL family. New schemes should be allowed to come up with their own 
syntax definition to serve their own purpose, but not have to carry over
the 
constraints of other schemes. Even for implementation simplicity, every 
scheme will have to do its own parsing anyway. Why not allow them to 
define its own set of reserved/excluded characters?

>Also, I would like to use this occasion to reiterate my (and many
>other's) request to put a note into draft-fielding-url-syntax-09.txt
>to alert readers of the fact that internationalization of URIs
>is converging towards UTF-8. The IMAP URL and the URN syntax
>draft are clear evidence of this and can be cited easily.
>Not putting in such a note would consist a serious negligence
>to include relevant information. I will be glad to provide the
>detailled wording.
>

I also think using UTF8 as the underlying character set encoding for 
global naming scheme, like URN, is a good choice. In fact, we specified 
UTF8 as the character set encoding for the handle system. 

On the other hand, "http URL" can and is surviving without a globally
agreed
character set encoding. And the link generally won't break even if changed
from one character set encoding to another. Currently there're tons of
non-ASCII 
URL out there already, and this could make moving "http URL" into UTF8 very

difficult. Besides, UTF8 is not readable for most other languages other
than 
ASCII, and this may not make it acceptable for people, say, using CJK or 
Greek. It's might be more appropriate to let "http URL" will have their 
character set encoding information carried with them, either embedded in 
the HTML context, or by switching the encoding setup from the browser.

Regards,
Sam

Date: Mon, 3 Nov 1997 12:36:30 -0500
From: <[email-masked]>
To: Dave Raggett <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Sender: [email-masked]
Reply-To: <[email-masked]>

Dave Raggett writes:
 > I am not sure this follows from your definition. For instance,
 > GUIDs are guaranteed to remain globally unique but need never
 > refer to any concrete resource, neither are they Human friendly
 > unless you are particularly good at remembering 128 bit numbers.

I agree with you on both counts.  So the definition should have been
"...long after the resource it refers to, *if any*, ceases...".  The
human friendly issue is different from the issue of the "URN" keyword
that is supposed to indicate to humans (and programs) that the
identifier is *intended* to be persistent, etc, and should therefore be
preferred over lower forms of life.  

[I would argue that it is reasonable for such intent to be expressed for
any URI, and that URN spaces will eventually be obsoleted too, so this
doesn't really buy us anything, but I could live with it because it is
explicitly merely an "intent" as opposed to a strong technical
distinction.]

 > I think the key idea is that such names are guaranteed to be
 > globally unique over a very extended period of time -- i.e. they
 > won't be reused unintentionally for something different, as is
 > quite likely for names based on file system hierarchies. 

I disagree that such a guarantee means anything useful, so I would
replace it with a promise to be good.  Consider that it might be the
correct thing to do to reuse an identifier for something that is not
identical to the original but has equivalent meaning.  Accidentally or
unintentionally reusing an identifier should be avoided, however, and it
is generally not difficult to do once you set your mind to it.

 > > We could leave it at that or add some further explanation, which
 > > perhaps gets too close to the controversy:
 > > 
 > >    A URN should be associated with a global, persistent service
 > >    for resolving it or returning a redirection to another URI.
 > 
 > I don't think this is necessary in all cases. For example an MD5
 > of a document is useful even in the absence of such a service.
 > The uniqueness of a name over space and time certainly lends itself
 > to fault tolerant means to access resources associated with such
 > names. However this is a useful side-effect and not a fundamental
 > property.

I agree.  I tend to be more concerned about the persistent resolution
service since it is difficult to provide in a scalable manner.  By
comparison, persistent uniqueness is trivially easy.

--
Daniel LaLiberte
[email-masked]

Date: Mon, 3 Nov 1997 09:32:17 -0500 ()
From: Dave Raggett <[email-masked]>
To: [email-masked]
cc: "Roy T. Fielding" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: The UR* scheme registry, Citing URL/URI specs 
Sender: [email-masked]
Reply-To: Dave Raggett <[email-masked]>

On Thu, 30 Oct 1997 [email-masked] wrote:

> I would replace the above paragraph with the following argument
> for a non-technical distinction: 
> 
>    A URN differs from a URL in that a URN is intended to remain
>    globally unique and persistent long after the resource it
>    refers to ceases to exist or becomes unavailable. 
> 
> This non-technical distinction seems to agree with Keith Moore's
> argument that URNs are really for humans.

I am not sure this follows from your definition. For instance,
GUIDs are guaranteed to remain globally unique but need never
refer to any concrete resource, neither are they Human friendly
unless you are particularly good at remembering 128 bit numbers.

I think the key idea is that such names are guaranteed to be
globally unique over a very extended period of time -- i.e. they
won't be reused unintentionally for something different, as is
quite likely for names based on file system hierarchies. 

> We could leave it at that or add some further explanation, which
> perhaps gets too close to the controversy:
> 
>    A URN should be associated with a global, persistent service
>    for resolving it or returning a redirection to another URI.

I don't think this is necessary in all cases. For example an MD5
of a document is useful even in the absence of such a service.
The uniqueness of a name over space and time certainly lends itself
to fault tolerant means to access resources associated with such
names. However this is a useful side-effect and not a fundamental
property.

Regards,

-- Dave Raggett <[email-masked]> http://www.w3.org/People/Raggett
phone: +44 122 578 2984 (or 2521) +44 385 320 444 (gsm mobile)
World Wide Web Consortium (on assignment from HP Labs)

Date: Mon, 3 Nov 1997 11:04:30 +0100 (MET)
From: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>
To: "Sam X. Sun" <[email-masked]>
cc: "Roy T. Fielding" <[email-masked]>, moore <[email-masked]>, urn-ietf <[email-masked]>, URI mailing list <[email-masked]>
Subject: Re: [URN] Re: URN/URL spec issues...
Sender: [email-masked]
Reply-To: =?iso-8859-1?Q?Martin_J=2E_D=FCrst?= <[email-masked]>

On Mon, 3 Nov 1997, Sam X. Sun wrote:

> One more question though. About the excluded characters. I can see the
> reason why ASCII 00-1F and 7F are excluded. But do characters like "<",
> ">", and "#" definitely have to be excluded also?

"<" and ">" are used to delimit URIs. If they are not excluded, it's
very difficult to know where an URI starts or ends. Also, "<" and ">"
are very frequent in HTML. "#" is the delimiter between what gets
sent to the server and what remains at the client for further processing.
If this is scheme-specific, this creates lots of problems.

> Again, some URI/URL
> schemes may need to use them as delimiters, some may not. Should they be
> put in the "unwise" category in stead? Even the ASCII 00-1F and 7F may be
> implementation specific, because future namespace or URI/URL scheme may be
> based on UNICODE, and mandating the excluded character set may be costly.

Current URIs/URLs are already to some extent based no UNICODE. As
an examlpe, please see the IMAP URL RFC. Work on the general definition
of Unicode-based URLs is proceeding currently in a private group of
experts, and we hope to go back to open discussion soon.
Such URLs will be based on UTF-8, which uses the octets 0x80-0xFF,
so that excluding 00-1F and 7F is no problem.

Please note that due to backwards compatibility problems, characters
outside the ASCII set will not be usable as reserved characters, because
for them, the distinction between escapend and non-escaped cannot
be used to distinguish between reserved and non-reserved.

Also, I would like to use this occasion to reiterate my (and many
other's) request to put a note into draft-fielding-url-syntax-09.txt
to alert readers of the fact that internationalization of URIs
is converging towards UTF-8. The IMAP URL and the URN syntax
draft are clear evidence of this and can be cited easily.
Not putting in such a note would consist a serious negligence
to include relevant information. I will be glad to provide the
detailled wording.

Regards,	Martin.

From: "Sam X. Sun" <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: [URN] Re: URN/URL spec issues... 
Date: Mon, 3 Nov 1997 03:25:38 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

First of all, thanks very much for answer my questions.

One more question though. About the excluded characters. I can see the
reason why ASCII 00-1F and 7F are excluded. But do characters like "<",
">", and "#" definitely have to be excluded also? Again, some URI/URL
schemes may need to use them as delimiters, some may not. Should they be
put in the "unwise" category in stead? Even the ASCII 00-1F and 7F may be
implementation specific, because future namespace or URI/URL scheme may be
based on UNICODE, and mandating the excluded character set may be costly.

Would it be more saft to say that the set of excluded characters should
also be scheme or implementation specific, like the reserved character set?

-Sam

----------
> From: Roy T. Fielding <[email-masked]>
> To: Sam Sun <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: URN/URL spec issues... 
> Date: Saturday, November 01, 1997 12:45 AM
> 
> Sam asks some good questions:
> >1. Should the reserved character set be reconsidered for URL, or why
such a
> >big set of reserved characters? Your draft states that "Characters in
the
> >'reserved' set are not reserved in all contexts". I think it's more
> >appropriate to say that reserved characters are defined on a per URL
scheme
> >bases. This is because some URL schemes may require more reserved
characters
> >because of their more complicated <scheme-specific-part>, while other
URL
> >schemes may need no reserved characters at all, and making hex encoding
is a
> >totally unnecessary overhead. The URL is defined as a super set covering
all
> >URL schemes, and so it should make the least restrictions.
> 
> It does make the least restrictions.  In 2.4.2 it says
> 
>    A URI is always in an "escaped" form, since escaping or unescaping
>    a completed URI might change its semantics.  Normally, the only
>    time escape encodings can safely be made is when the URI is being
>    created from its component parts; each component may have its own
>    set of characters which are reserved, so only the mechanism
>    responsible for generating or interpreting that component can
>    determine whether or not escaping a character will change its
>    semantics. Likewise, a URI must be separated into its components
>    before the escaped characters within those components can be safely
>    decoded.
> 
> which is saying that whether or not a character is actually reserved
> is a property of the resource namespace of the individual URI.  Some
> schemes may require a single set of reserved characters, but most do not.
> The only time that the reserved set is "known" is when it is a
requirement
> of a particular component within a particular scheme's namespace.
> 
> >3. What is URI? Is it intended for the common denorminator of URL and
URN,
> >or for the super set specification for both of them?
> 
> The greatest common denominator (the set of syntax and semantics that
> allows both to be compliant and yet describe as much as possible so
> that implementers do not have to duplicate their work).  That means
> 
>    a) sufficient syntax to distinguish them from surrounding context;
> 
>    b) algorithms that must be common to all URI namespaces that allow
>       relative references;
> 
>    c) common rationale and examples of use.
> 
> In other words, the things a URI reference handler needs to know even
> if it does not understand the semantics of a particular scheme, which
> is the common case for URI-enabled applications that are designed for
> extensibility.
> 
> >4. Following your earlier thread, URL is for locator, not necessarily
> >location. And the semantics of any particular URL should be defined by
the
> >corresponding URL scheme. Hence when defined properly, certain URL
schemes
> >could very well be used as an implementation of URN, that is, locate by
name
> >instead of by location. Is this the common understanding or have I
missed
> >some point here?
> 
> That's certainly what I think of in terms of a URL, but calling it a
> "common understanding" depends on who you talk to.  Introducing the
> term URI allows us to change the definition of URL such that it does
> refer to network locations only.  Keep in mind that these things were
> originally called Web Addresses, and later UDIs, and then URIs, so it's
> not as if this is anything new.
> 
> The problem, of course, is that not all location-independent URI's fit
> within the URN syntax, and thus the conceptual difference between URN 
> and URL is as clear as mud.
> 
> .....Roy

From: Keith Moore <[email-masked]>
To: "Roy T. Fielding" <[email-masked]>
cc: Sam Sun <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: URN/URL spec issues... 
Date: Sat, 01 Nov 1997 01:21:33 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

[wow...the recipient list got trimmed...]

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

"location independent URI" != "URN"

All URNs are location-independent, but not all location-independent
URIs are URNs.  There are several other requirements of URNs besides 
location-independence and the URN syntax rules, because location-
independence alone is not sufficient to promote name stability.

It doesn't hurt to reinforce the notion that URLs can be 
location-indepedent.

Keith

To: Sam Sun <[email-masked]>
cc: [email-masked], [email-masked]
Subject: [URN] Re: URN/URL spec issues... 
Date: Fri, 31 Oct 1997 21:45:46 -0800
From: "Roy T. Fielding" <[email-masked]>
Sender: [email-masked]
Reply-To: "Roy T. Fielding" <[email-masked]>

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

It does make the least restrictions.  In 2.4.2 it says

   A URI is always in an "escaped" form, since escaping or unescaping
   a completed URI might change its semantics.  Normally, the only
   time escape encodings can safely be made is when the URI is being
   created from its component parts; each component may have its own
   set of characters which are reserved, so only the mechanism
   responsible for generating or interpreting that component can
   determine whether or not escaping a character will change its
   semantics. Likewise, a URI must be separated into its components
   before the escaped characters within those components can be safely
   decoded.

which is saying that whether or not a character is actually reserved
is a property of the resource namespace of the individual URI.  Some
schemes may require a single set of reserved characters, but most do not.
The only time that the reserved set is "known" is when it is a requirement
of a particular component within a particular scheme's namespace.

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

The greatest common denominator (the set of syntax and semantics that
allows both to be compliant and yet describe as much as possible so
that implementers do not have to duplicate their work).  That means

   a) sufficient syntax to distinguish them from surrounding context;

   b) algorithms that must be common to all URI namespaces that allow
      relative references;

   c) common rationale and examples of use.

In other words, the things a URI reference handler needs to know even
if it does not understand the semantics of a particular scheme, which
is the common case for URI-enabled applications that are designed for
extensibility.

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

That's certainly what I think of in terms of a URL, but calling it a
"common understanding" depends on who you talk to.  Introducing the
term URI allows us to change the definition of URL such that it does
refer to network locations only.  Keep in mind that these things were
originally called Web Addresses, and later UDIs, and then URIs, so it's
not as if this is anything new.

The problem, of course, is that not all location-independent URI's fit
within the URN syntax, and thus the conceptual difference between URN 
and URL is as clear as mud.

.....Roy