Subject: Re: [URN] NAPTR status
From: Michael Mealling <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Sat, 30 May 1998 21:16:23 -0400 (EDT)

John C. Mallery said this:
> I have been thinking a little about the tree structure used to
> delegate URN space in NAPTR. The problem is that we're always
> going to the root and descending the pointer structure to
> find the right resolver.

Yep. But as designed the root records very long times to live.
Someone had better have a really good reason for changing a record
in the root once its there.

> A better approach would have us climbing the tree from some
> known starting point, like the resolver at my site, and reaching
> the root only when no resolvers on the way up the tree know the resolver
> for the URN scheme.

NAPTR, as well as any RDS, is meant as the resolution step of last resort.
The firs step in the algorithm is to check locally for any known caches
or other hints.

Also, since the root is cached for very long periods of time, the local
resolver will have that answer. I.e. in DNS, all of your requests go
to your local nameserver first, then the root if it doesn't have the
answer. In the case of NAPTR, once a root query is cached in your local
nameserver you shouldn't query the root until the nameserver is restarted
or changes.

> An even better approach would be to perform all the discovery within
> URN resolver space.  This must wait until we have considerably wider
> deployment of resolvers.

Can you explain what you mean by "within URN resolver space" a bit
more?

> One of the key issues is that the number of resources will always
> be a couple of orders of magnitude larger than the number of servers.
> Thus, we can hardly expect DNS to voluntarily address scaling problems
> for a larger problem which they do not own.

DNS records do not point at resources, they point to resolvers. Once you
find an answer it is valid until a time to live expires. I.e. in http,
once you get an A record for the host in the URL you don't keep hitting
DNS over and over again. In NAPTR (as in any RDS) once you resolve
a URN you can send a new URN back through the resolver process that
will hopefully use the hints it cached from the last resolution step.

> Another key issue is cache management for resolver discovery information.
> The present story is that we hope DNS is doing the right thing for us.

DNS is only half the story. But from my tests it's half works and works
well. The other half is cache managment in browsers and libraries.
My hacking on win32 has shown that Microsoft's cache management needs
some work in order to really do URN caching correctly. I'm just now
getting into the guts of Netscape's cache system.

-MM

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

Date: Fri, 29 May 1998 20:11:56 -0400
To: Ron Daniel <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: RE: [URN] NAPTR status
Cc: Larry Masinter <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Ron,

Good to have you back!

I have been thinking a little about the tree structure used to
delegate URN space in NAPTR. The problem is that we're always
going to the root and descending the pointer structure to
find the right resolver.

A better approach would have us climbing the tree from some
known starting point, like the resolver at my site, and reaching
the root only when no resolvers on the way up the tree know the resolver
for the URN scheme.

An even better approach would be to perform all the discovery within
URN resolver space.  This must wait until we have considerably wider
deployment of resolvers.

One of the key issues is that the number of resources will always
be a couple of orders of magnitude larger than the number of servers.
Thus, we can hardly expect DNS to voluntarily address scaling problems
for a larger problem which they do not own.

Another key issue is cache management for resolver discovery information.
The present story is that we hope DNS is doing the right thing for us.

I would be interested in your views on the issues.

Regards,  John

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

Date: Fri, 29 May 1998 20:18:39 -0700 (PDT)
From: "John A. Kunze" <[email-masked]>
To: [email-masked]
Subject: Re: [URN] NA id request - wanting a specific number
Sender: [email-masked]
Reply-To: "John A. Kunze" <[email-masked]>

> From [email-masked] Fri May 29 07:45 PDT 1998
>  > I'm setting up a prototype URN resolution service for the US National
>  > Library of Medicine (NLM).  First off we need a Namespace ID (NID).
>  > 
>  > The NID that I'm requesting is the string
>  > 
>  > 	"1000"
> 
> Nice number.  Who gets "2000" or other great numbers: "0".."20"?  
> 
> My point being that if all you have to label things with is numbers,
> then people will assign meaning to the numbers.

Completely aside from questions about the merits of numeric NIDs,
I specifically requested "1000" because that's our Handle System Name
Authority string.

It would be awfully convenient to have the same number within both schemes.

-John

From: <[email-masked]>
Date: Fri, 29 May 1998 10:49:24 -0400 (EDT)
To: "John A. Kunze" <[email-masked]>
Cc: [email-masked]
Subject: [URN] NA id request - wanting a specific number
Sender: [email-masked]
Reply-To: <[email-masked]>

John A. Kunze writes:
 > I'm setting up a prototype URN resolution service for the US National
 > Library of Medicine (NLM).  First off we need a Namespace ID (NID).
 > 
 > The NID that I'm requesting is the string
 > 
 > 	"1000"

Nice number.  Who gets "2000" or other great numbers: "0".."20"?  

My point being that if all you have to label things with is numbers,
then people will assign meaning to the numbers.  Why did you pick
"1000"?  People assign meaning to numbers even if they don't really have
to, though it is relatively rare.  (A couple examples: the TV show named
after a zip code, the Boston cafe named after the original street
address.) So numeric ids do not really avoid the problem of semantic
drift - they merely push it off to another level.

On the other hand, numeric ids are harder to remember, harder to assign
meaning to, and people will be more inclined to use identifiers that are
easier to deal with.  I understood that people who are arguing for
numeric ids are also assuming there will be a layer of human-friendly
ids on top of them, but I have never heard a proposal (or half-baked
idea) for how that higher-level layer of ids will work, and more
importantly, how they will avoid the same problems that other
semantically rich ids have.

The system of DNS names and IP numbers is a good example to learn from,
actually.  You all know how it works, but I'm not sure we all learned
the same thing.  The IP number of a machine can be changed, or inversely
the machine that an IP number is associated with can change.  IP numbers
are rarely used by humans, however, and the DNS system was set up to map
to IP numbers.  DNS names can change for the same IP number, but more
typically, multiple DNS names map to the same IP number and the same DNS
name may map to a different IP number over its lifetime.  So DNS names
are very much like the names of resources, but the resources in this
case are whole machines.  The DNS system supports very scalable
resolution, primarily because it is hiearchical, but the management of
DNS name "assignment" has never properly delt with the issue of
conflicts.

By the way, perhaps a hidden assumption behind the URN work is that
resources smaller than whole machines (e.g. documents and services) need
to be separated from the whole machines.  It is not that the identifiers
of whole machines cannot be "location-independent" names - DNS names are
exactly that.  More generally, resources need to be independent of the
*collections* they are contained within since they may be eventually
removed from those collections.  (A machine or host is a sort of
collection too.)  Perhaps this is why people object to any hierarchical
name system.  But creating a set of naming authorities each with its own
flat name space does not really solve this problem since each flat name
space is still a collection that the resources need to be independent
of; eventually some of the naming authorities will fail.  The only
solution that avoids collections altogether is to have only one flat
name space for all resources.  But then we have a serious problem
achieving scalable resolution.

 > As an aside, in discussing
 > 
 > 	http://www.ietf.org/internet-drafts/draft-ietf-urn-nid-req-03.txt
 > 
 > with Leslie, she had the idea that when the requestor doesn't specify a
 > NID, that the number assigned by the IANA-like body should be prefixed, say
 > 
 > 	iana-NNNNNN

I believe the only way that numeric ids could work to avoid conflicts is
to assign them.  Better avoid re-assigning numbers too, but that should
not be a problem as long as the number of digits can grow indefinitely.
But then, alphanumeric ids could be assigned too.  Consider license
plate "numbers".  Then consider vanity plates.

So I believe the issue of numeric ids is a red herring.  The real issue
is whether ids are assigned, or if they are chosen, how conflicts are
resolved. The proper way to deal with top-level name space conflict
issues is to inherit another system for dealing with such conflicts,
such as the trademark system.  Or if you want to set up your own system
for dealing with conflicts, it better be at least as good.

--
Daniel LaLiberte
 [email-masked]  (was: [email-masked])
 [email-masked]

Date: Thu, 28 May 1998 15:01:07 -0700 (PDT)
From: "John A. Kunze" <[email-masked]>
To: [email-masked]
Subject: [URN] NA id request - wanting a specific number
Sender: [email-masked]
Reply-To: "John A. Kunze" <[email-masked]>

I'm setting up a prototype URN resolution service for the US National
Library of Medicine (NLM).  First off we need a Namespace ID (NID).

The NID that I'm requesting is the string

	"1000"
	
(That is, the string consists of the four characters '1', '0', '0', '0'.)

This string of digits serves better than a string of identifying
characters, such as "NLM", because of the need to assign names that will
persist long after the NLM has been (in a hypothetical future) renamed
following privatization, and when advertizers who might use its URN's
will be sued for trademark infringment by a major beverage producer called
National Lager Manufacturing, which will have become known as "NLM". ;-)

As an aside, in discussing

	http://www.ietf.org/internet-drafts/draft-ietf-urn-nid-req-03.txt

with Leslie, she had the idea that when the requestor doesn't specify a
NID, that the number assigned by the IANA-like body should be prefixed, say

	iana-NNNNNN

somehow so as not to conflict with requestors of pure numbers.  I second
that idea.

-John

---------------------------------------------------------------------------
John A. Kunze                  +1 510-525-8575    UCSF Medical Informatics
530 Parnassus Ave, Box 0840    [email-masked]   University of California/
San Francisco, CA  94143-0840  Fax: 415-476-4653  Nat'l Library of Medicine
----------------------- UC San Francisco and US NLM -----------------------

From: Ron Daniel <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked]
Subject: RE: [URN] NAPTR status
Date: Fri, 22 May 1998 08:59:32 -0700
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Larry says:
> there are
> significantly different issues for the use of DNS in NAPTR
> and the general DNS security issues addressed in DNSSEC.
> 
[Ron Daniel]  Such as?

> So you need to address those. Once you address those issues,
> will "using DNS with DNSSEC and additional security measures"
> actually turn out to be the most "graceful" mechanism for
> handling URN resolution?
> 
[Ron Daniel]  First, I am not convinced that NAPTR records
have significantly different security requirements than any
other DNS record. (There are additional security considerations
when we look at the entire resolution process, but 2168 doesn't
specify the entire resolution process, only the part of it
concerning how to find a resolver). Second, any search for the
"most graceful" mechanism is doomed because it is impossible to
prove that a more graceful mechanism doesn't exist. All we can
hope for is an "acceptably graceful" mechanism, and the
acceptance criteria on that is, of course, rough consensus.

Regards,
Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
415.222.0100 fax 415.222.0150 
[email-masked]
http://www.datafusion.net

>  

From: "Larry Masinter" <[email-masked]>
To: "Ron Daniel" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] NAPTR status
Date: Thu, 21 May 1998 14:56:18 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> [Ron Daniel]  Wait a sec Larry. 2168 defines a particular
> DNS resource record. This has very strong implications
> for what is and is not in scope for its security
> considerations section. Most of what is in scope has
> already been covered by DNSSEC. Issues on how to
> deal with security past the lifetime of DNS are not
> in scope.
> 
> There is work to be done in the security considerations
> section, but lets not try to do more than needs to be
> done.

Even if you presume that DNS will be around forever, there are
significantly different issues for the use of DNS in NAPTR
and the general DNS security issues addressed in DNSSEC.

So you need to address those. Once you address those issues,
will "using DNS with DNSSEC and additional security measures"
actually turn out to be the most "graceful" mechanism for
handling URN resolution?

Larry

From: Ron Daniel <[email-masked]>
To: "'Larry Masinter'" <[email-masked]>
Cc: [email-masked]
Subject: RE: [URN] NAPTR status
Date: Thu, 21 May 1998 08:56:46 -0700
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

> I don't think that the current 'security considerations' of RFC 2168
> are
> adequate
> for a standards track document, and I think it is likely that it would
> exceed
> the schedule you have in mind to actually develop an adequate approach
> for
> dealing with the long-term security issues, while still addressing
> the goals (e.g., that the mechanisms be 'graceful').
> 
[Ron Daniel]  Wait a sec Larry. 2168 defines a particular
DNS resource record. This has very strong implications
for what is and is not in scope for its security
considerations section. Most of what is in scope has
already been covered by DNSSEC. Issues on how to
deal with security past the lifetime of DNS are not
in scope.

There is work to be done in the security considerations
section, but lets not try to do more than needs to be
done.

Regards,
Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
415.222.0100 fax 415.222.0150 
[email-masked]
http://www.datafusion.net

From: "Larry Masinter" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>, "Karen R. Sollins" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: [URN] NAPTR status
Date: Wed, 20 May 1998 23:50:40 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

I don't think that the current 'security considerations' of RFC 2168 are
adequate
for a standards track document, and I think it is likely that it would exceed
the schedule you have in mind to actually develop an adequate approach for
dealing with the long-term security issues, while still addressing
the goals (e.g., that the mechanisms be 'graceful').

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

Date: Wed, 20 May 1998 16:20:49 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] another NID definitions document issue
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

One other issue that has come up is that someone has specifically asked
for a NID that is a number -- i.e., a particular number that is relevant
to the namespace they have (notably, the number that is used to designate
it in another context).

I don't particularly see any problem with this, and wonder if we would
be better off making the assigned namespace id's a little more distinctly
assigned than simply a number -- perhaps

	"iana-" 1*(<digit>)

for the assigned namespace ids, e.g.,

	urn:iana-0168:somethingspecific

Is this useful, or is it too clever by half?

Leslie.

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

  "You can lead people to facts, but              Leslie Daigle
       you cannot make them think."               
                                                  Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

Date: Wed, 20 May 1998 16:16:38 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Ron Daniel <[email-masked]>
cc: [email-masked]
Subject: [URN] Re: comments on "URN Namespace Definition Mechanisms draft
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hi Ron,

Nice to have you back :->

On Wed, 20 May 1998, Ron Daniel wrote:
> Some draft-ietf-urn-nid-req-03.txt, aka "URN Namespace Definition
> Mechanisms"

Thanks for the comments; these seem pretty straightforward, so I'll 
incorporate them in the next draft of the document.

Leslie.

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

  "You can lead people to facts, but              Leslie Daigle
       you cannot make them think."               
                                                  Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: Ron Daniel <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [URN] comments on "URN Namespace Definition Mechanisms draft
Date: Wed, 20 May 1998 10:03:48 -0700
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi all,

Some draft-ietf-urn-nid-req-03.txt, aka "URN Namespace Definition
Mechanisms"

In general, having an IANA-like body register namespaces is the
way to go.

> 3.0 URN Namespace Definition Template

The sections of the template look OK, we will learn more about these
over time but they are a very good start.

> 5.0 Example

> Declaration of structure:
>
>        The identifier structure is as follows:
>        
>
>        FQDN:<assigned string>

I suggest that the urn:inet: prefix should also appear in the request.

>        where FQDN is a fully-qualified domain name, and the
>        assigned string is conformant to URN syntax requirements.

Oh, one other field to add to the template is a listing of any RFCs that
govern the syntax of the namespace or fields in the names. In this case,
some of the basic domain names specs should be cited to let people know
what is and is not a legal FQDN. Also, this example should cite the
relevant RFCs.

>Identifier uniqueness considerations:
>        
>        Uniqueness is guaranteed as long as the assigned
>        string is never reassigned for a given FQDN.    

If we were reviewing the INET proposal as an RFC-track document, I would
regard this section on considerations as inadequate. FQDNs are not
unique
over time. In fact the guarantee is pretty much that if you don't keep
paying your bills, your domain name will be sold out from under you.
Given
that, the INET namespace needs additional information to prevent
collisions.

>Identifier persistence considerations:
>
>        Persistence of identifiers is dependent upon suitable
>        delegation of resolution at the level of "FQDN"s.

Here again, this is an inadequate discussion. First, it is not clear
just
what is meant by this statement (though I can guess, I should not have
to).
Second, given that FQDNs are not necessarily unique over time, something
needs to talk about what to do when a new organization gets another's
old
domain. 

> Rules for Lexical Equivalence:
>
>        Nothing in particular.

Nope. The "urn", "inet", and "FQDN" fields are case-insensitive.
information after the "FQDN" field should be regarded as case-
sensitive.

>Conformance with URN Syntax:
>
>        No special considerations.

I'd like to see more information on limits on what is a legal name that
can be assigned by the holder of the FQDN. At a minimum there needs to
be
a citation to the URN syntax RFC.

>Validation mechanism:
>
>        None specified.

Hmmm.

>Scope:
>        
>        Global.

From: Ron Daniel <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [URN] comments on "URN Namespace Definition Mechanisms draft
Date: Wed, 20 May 1998 10:03:48 -0700
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi all,

Some draft-ietf-urn-nid-req-03.txt, aka "URN Namespace Definition
Mechanisms"

In general, having an IANA-like body register namespaces is the
way to go.

> 3.0 URN Namespace Definition Template

The sections of the template look OK, we will learn more about these
over time but they are a very good start.

> 5.0 Example

> Declaration of structure:
>
>        The identifier structure is as follows:
>        
>
>        FQDN:<assigned string>

I suggest that the urn:inet: prefix should also appear in the request.

>        where FQDN is a fully-qualified domain name, and the
>        assigned string is conformant to URN syntax requirements.

Oh, one other field to add to the template is a listing of any RFCs that
govern the syntax of the namespace or fields in the names. In this case,
some of the basic domain names specs should be cited to let people know
what is and is not a legal FQDN. Also, this example should cite the
relevant RFCs.

>Identifier uniqueness considerations:
>        
>        Uniqueness is guaranteed as long as the assigned
>        string is never reassigned for a given FQDN.    

If we were reviewing the INET proposal as an RFC-track document, I would
regard this section on considerations as inadequate. FQDNs are not
unique
over time. In fact the guarantee is pretty much that if you don't keep
paying your bills, your domain name will be sold out from under you.
Given
that, the INET namespace needs additional information to prevent
collisions.

>Identifier persistence considerations:
>
>        Persistence of identifiers is dependent upon suitable
>        delegation of resolution at the level of "FQDN"s.

Here again, this is an inadequate discussion. First, it is not clear
just
what is meant by this statement (though I can guess, I should not have
to).
Second, given that FQDNs are not necessarily unique over time, something
needs to talk about what to do when a new organization gets another's
old
domain. 

> Rules for Lexical Equivalence:
>
>        Nothing in particular.

Nope. The "urn", "inet", and "FQDN" fields are case-insensitive.
information after the "FQDN" field should be regarded as case-
sensitive.

>Conformance with URN Syntax:
>
>        No special considerations.

I'd like to see more information on limits on what is a legal name that
can be assigned by the holder of the FQDN. At a minimum there needs to
be
a citation to the URN syntax RFC.

>Validation mechanism:
>
>        None specified.

Hmmm.

>Scope:
>        
>        Global.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-ietf-05.txt
Date: Wed, 20 May 1998 09:56:22 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

	Title		: A URN Namespace for IETF Documents
	Author(s)	: R. Moats
	Filename	: draft-ietf-urn-ietf-05.txt
	Pages		: 24
	Date		: 19-May-98
	
   A system for Uniform Resource Names (URNs) must be capable of
   supporting new naming systems.  As an example of proposing a new
   namespace, this document proposes the 'ietf' namespace.  This
   namespace consists of the RFC family of documents (RFCs, STDs, FYIs,
   and BCPs) developed by the IETF and published by the RFC editor and
   the minutes of working groups (WG) and birds of a feather (BOF)
   meetings that occur during IETF conferences.  Both the current URN
   framework and URN syntax support this namespace.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urn-ietf-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-ietf-05.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: ftp.ietf.org
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-ietf-05.txt

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

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

--OtherAccess--

--NextPart--

From: Ron Daniel <[email-masked]>
To: "'Leslie Daigle'" <[email-masked]>, "Karen R. Sollins" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [URN] NAPTR status
Date: Tue, 19 May 1998 15:41:04 -0700
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi folks, its nice to be back. For those of you who have
not heard, I'm no longer at Los Alamos, and my new
employer (Datafusion, in San Francisco) has at least
some interest in URNs.

> On Fri, 15 May 1998, Karen R. Sollins wrote:
> > I am more than a little surprised that you want to move NAPTR to
> > standards track.  It wasn't standards track, and I don't think it
> > should be.  It really is experimental.  We do not have enough
> > experience with NAPTR or other documented alternatives to say that
> > this should be THE standard or even A standard.
> 
[Ron Daniel]  Having been experimental
is no reason for keeping something off the standards
track. However, it is equally important to note that
we went for experimental status on NAPTR for some
very specific reasons - mostly because it was messing around
with DNS and we CANNOT jepordize the operation of that
little bit of infrastructure. 

What we have learned during the experimental period is that
NAPTR is not hostile to DNS, at least at the small scales it
has been used so far.

And Leslie asked:
>  
> At the end of the day, is it better to think of NAPTR as an immature
> specification, or part of some research effort?
> 
[Ron Daniel]  While I consider myself a researcher for the
most part, NAPTR was not intended to be a research effort,
but was intended to be a protocol. It needs further scrutiny,
but the scrutiny so far has not turned up horrible problems.
Make no mistake - there have been problems that have turned
up, but they are all about apparent incompatabilities between
NAPTR implementations in different versions of BIND. Those
interfere with zone transfers, but have not posed threats
to the general stability of DNS.

To investigate NAPTR further will require broader deployment
and interoperation. It seems appropriate to deal with that
on the standards track, with the understanding that NAPTR is
at the beginning of the standardization process, not the end.

Later,

Ron Daniel Jr.
DATAFUSION, Inc.
139 Townsend Street, Ste. 100
San Francisco, CA  94107
415.222.0100 fax 415.222.0150 
[email-masked]
http://www.datafusion.net

Date: Tue, 19 May 1998 17:47:27 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: "Karen R. Sollins" <[email-masked]>
cc: [email-masked], [email-masked]
Subject: [URN] NAPTR status
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

This topic needs significant wg input -- so, people, please respond with
your viewpoints!

On Fri, 15 May 1998, Karen R. Sollins wrote:
> I am more than a little surprised that you want to move NAPTR to
> standards track.  It wasn't standards track, and I don't think it
> should be.  It really is experimental.  We do not have enough
> experience with NAPTR or other documented alternatives to say that
> this should be THE standard or even A standard.

This sums up neatly where the document is currently at (i.e., _not_
standards-track) and is a good starting point for the discussion that
needs to be had before this could be anything more than a proposed
idea.  I will outline below _why_ I propose it at this juncture, and
we can see where to go from there.  

The proposal to move the NAPTR document to standards-track stems from 
the perspective that URN-resolving systems are coming on-line _now_, and
implementations are being planned.  In the absence of anything else, 
either NAPTR will be coded to,  or URNs will simply die for lack of
a defined system that people can pick up and implement today.

It is my understanding that the NAPTR system is generally stable, and
well-understood, for what it does.  There are very real concerns about
how well it will scale, depending on the specific namespaces and requirements
that are thrown at it in real life -- but I'll argue that those are
operational requirements that can only be quantified by, well, operation.

Given that the expectation is that people _will_ use it, rather than
have it become a de facto standard, I argue that it's better for us to
put what we have on the standards-track, have it properly-scrutinized
and subject to appropriate updates to meet real needs as they arise.  This
does _not_ preclude the development of other, better RDS mechanisms that
would make better long-term standards, but it may sync up better with
reality.

Food for thought, from RFC2026, which defines the RFC documents:

On the subject of draft standards (the first step in the standards process):

   A Proposed Standard specification is generally stable, has resolved
   known design choices, is believed to be well-understood, has received
   significant community review, and appears to enjoy enough community
   interest to be considered valuable.  However, further experience
   might result in a change or even retraction of the specification
   before it advances.
[snip]
   Implementors should treat Proposed Standards as immature
   specifications.  It is desirable to implement them in order to gain
   experience and to validate, test, and clarify the specification.
   However, since the content of Proposed Standards may be changed if
   problems are found or better solutions are identified, deploying
   implementations of such standards into a disruption-sensitive
   environment is not recommended.

On the subject of experimental documents:

   The "Experimental" designation typically denotes a specification that
   is part of some research or development effort.  Such a specification
   is published for the general information of the Internet technical
   community and as an archival record of the work, subject only to
   editorial considerations and to verification that there has been
   adequate coordination with the standards process (see below).  

At the end of the day, is it better to think of NAPTR as an immature
specification, or part of some research effort?

Leslie.

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

  "You can lead people to facts, but              Leslie Daigle
       you cannot make them think."               
                                                  Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

To: "Ryan Moats" <[email-masked]>
cc: "Cynthia Clark" <[email-masked]>, "URN mailing list" <[email-masked]>
Subject: [URN] Re: draft-ietf-urn-ietf-05.txt 
Date: Tue, 19 May 1998 15:44:21 -0400
From: Cynthia Clark <[email-masked]>
Sender: [email-masked]
Reply-To: Cynthia Clark <[email-masked]>

I've just made a minor editorial change by replacing 
the third paragraph of the Status of this Memo section:
 
 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
 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
 (US West Coast).
 
Please use this one for the future reference.  Please note that
I've removed "ds.internic.net" from this paragraph mainly due to
the fact it's no longer in service.
 
Any questions (or concerns) about any drafts should be sent
directly to me at <[email-masked]>
 
I'll send the announcement sometime tomorrow or next day.

Regards,
 
Cynthia
------------------------------------------------------
Cynthia Clark, IETF Internet-Drafts Administrator
E-mail:   <[email-masked]>
-------------------------------------------------------

From: "Ryan Moats" <[email-masked]>
To: "i-d editor" <[email-masked]>
Cc: "URN mailing list" <[email-masked]>
Date: Tue, 19 May 98 10:57:12 -0600
Priority: Normal
Subject: [URN] draft-ietf-urn-ietf-05.txt
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Included is draft-ietf-urn-ietf-05.txt.  Please replace -04 in the archives.

Thanks,
Ryan Moats

=======cut here

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

                   A URN Namespace for IETF Documents
                  Filename: draft-ietf-urn-ietf-05.txt

Status of This Memo

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

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

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

Abstract

   A system for Uniform Resource Names (URNs) must be capable of
   supporting new naming systems.  As an example of proposing a new
   namespace, this document proposes the "ietf" namespace.  This
   namespace consists of the RFC family of documents (RFCs, STDs, FYIs,
   and BCPs) developed by the IETF and published by the RFC editor and
   the minutes of working groups (WG) and birds of a feather (BOF)
   meetings that occur during IETF conferences.  Both the current URN
   framework and URN syntax support this namespace.

0.1 Changes from -02

   This document has been restructured to use the template proposed in
   draft-ietf-urn-nid-req-03.txt.  Example Perl scripts for resolving
   this namespace have been supplied in an Appendix.

Expires 11/30/98                                                [Page 1]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

0.2 Changes from -03

   Text was added to the template clarifying persistence and uniqueness.
   Support for the BCP document series added to the examples and the
   ABNF.

0.3 Changes from -04

   More clarifications for the persistence section.  In addition,
   cleaned up some typos and ensured that the Appendix examples are
   functional

1. Introduction

   This document proposes the "ietf" namespace, which consists of the
   RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the
   IETF and published by the RFC editor and the minutes of working
   groups (WG) and birds of a feather (BOF) meetings that occur during
   IETF conferences.

   The namespace specification is for a formal namespace.

2. Specification Template

     Namespace ID:

          "ietf" requested.

     Declared registrant of the namespace:

          Ryan Moats
          [email-masked]

     Declaration of structure:

          The identifier has the following ABNF [2] specification:

          NSS = (family ":" number) / ("mtg-" number "-" wgbofname)
          family = "rfc" / "std" / "fyi" / "bcp"
          number = 1*DIGIT
          wgbofname = 1*LETDIGIT
          LETDIGIT = DIGIT / %x41-%x5a / %x61-%x7a
          DIGIT = %x30-%x39

          If the IESG (or it successor) adds a new document
          series, this ABNF specification will need to be
          updated.  Further, if a working group or BOF is
          created that used characters outside the range of this

Expires 11/30/98                                                [Page 2]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

          ABNF specification, this specification will need to be
          updated.  Any system intended to resolve names for
          this namespace should be written with the awareness
          that this could occur at any time.

     Identifier uniqueness considerations:

          Because the rfc-editor assigns the RFC number uniquely
          these URNs are unique.  Since the mapping between RFCs
          and other rfc-editor document series (STDs, FYIs or
          BCPs) is not necessarily one-to-one, uniqueness of
          STDs, FYIs and BCPs are defined based on the document
          mappings maintained by the RFC Editor (the index files
          "rfc-index.txt", "fyi-index.txt", "bcp-index.txt" and
          "std-index.txt") are defined to be the definitive
          statement of the assignment of RFC Family URNs in this
          namespace.  The meeting minutes portion of the
          namespace is guaranteed unique because the URN
          includes the sequence number of the IETF conference.

     Identifier persistence considerations:

          Persistence of the URNs of this namespace is
          independent of the mutability of the underlying
          documents.  A URN once assigned will never be
          reassigned to a different resource; the assignment is
          persistent and immutable.  Distinct from this, the
          resources identified as RFCs are immutable, whereas
          the other sorts of documents, STDs, FYIs, and BCPs are
          not.  They may be composites of one or more RFCs and
          the set of RFCs that comprise them may change with
          time.  It is important to note that this mutability of
          some resources is independent of the immutability of
          URN assignment to a resource.

     Process of identifier assignment:

          Assignment of URNs from this namespace occurs in two
          ways.  The first is when a new RFC, FYI, STD or BCP is
          passed by the IESG and published by the RFC
          Editor. This new document will have a new series
          number and will therefore define a new URN.  The
          document mappings maintained by the RFC Editor (the
          index files "rfc-index.txt", "fyi-index.txt",
          "bcp-index.txt" and "std-index.txt") are defined to be
          the definitive statement of the assignment of RFC
          Family URNs in this namespace.

Expires 11/30/98                                                [Page 3]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

          The second way a URN is assigned is when a working
          group or birds of a feather files meeting minutes as
          part of an IETF conference.  The list of minutes
          maintained by the IETF for each working group and
          conference in the subtree pointed at by the URL
          ftp://ietf.org/ietf/ is considered the definitive
          assignment of URNs for working group or birds of a
          feather minutes.

     Process of identifier resolution:

          A mirrored copy of the underlying documentation is
          required to resolve these URNs.  Resolution via
          HTTP is accomplished by a set of simple Perl cgi-bin
          scripts presented in Appendix A.

     Rules for Lexical Equivalence:

          The entire URN is case-insensitive.

     Conformance with URN Syntax:

          There are no additional characters reserved.

     Validation mechanism:

          None specified.

     Scope:

          Global.

3. Security Considerations

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

4. Acknowledgments

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

Expires 11/30/98                                                [Page 4]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

4. References

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

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

[2]         D. Crocker, P. Overell, "Augmented BNF for Syntax Specifica-
            tions: ABNF," RFC 2234, November 1997.

5. Author's Address

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

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

Appendix A.  Example Resolution Scripts

   The following scripts are examples that can be used for resolving
   URNs in this namespace.

A.1 I2C

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 URC resolver for the ietf namespace
     #

     my(%cite) = (
       rfc => "/ftp/rfc/rfc-index.txt",
       fyi => "/ftp/fyi/fyi-index.txt",
       std => "/ftp/std/std-index.txt",
       bcp => "/ftp/rfc/bcp-index.txt"
     );
     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",

Expires 11/30/98                                                [Page 5]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
         print "Status: 200 OK\r\n";
         print "Content-type: text/html\r\n\r\n";
         print "<HTML>\n<TITLE>Citation for $urn</TITLE>\n";
         print "<BODY>\n";
         print "<H1><A HREF=\"$link\">$urn</A>:</H1>\n";
         print "Minutes of the $sesnam working group from the " . &end($ietfnum) . " IETF";
         print "</BODY>\n</HTML>\n";
         return;
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
         print "Status: 200 OK\r\n";
         print "Content-type: text/html\r\n\r\n";
         print "<HTML>\n<TITLE>Citation for $urn</TITLE>\n";
         print "<BODY>\n";
         print "<H1><A HREF=\"$link\">$urn</A>:</H1>\n";
         print "Minutes of the $sesnam working group from the " . &end($ietfnum) . " IETF";
         print "</BODY>\n</HTML>\n";
         return;
       }
       &urn_error("404 Not Found\n");
     }

     sub end {
       my($inarg)=@_;
       return $inarg . "st" if ($inarg =~ /1$/);
       return $inarg . "nd" if ($inarg =~ /2$/);

Expires 11/30/98                                                [Page 6]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       return $inarg . "rd" if ($inarg =~ /3$/);
       return $inarg . "th";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       if (!defined $cite{$scheme}) {
         &urn_error("404 Not Found\n");
       }

       $flag = 0;
       open(INPUT, "$cite{$scheme}");
       while (<INPUT>) {
         $flag = 1 if (/^0*$value /);
         if ($flag == 1) {
           last if (/^$/);
           chop;
           push @bib,$_;
         }
       }

       if ($scheme ne "rfc") {
         print "Status: 200 OK\r\n";
         print "Content-type: text/html\r\n\r\n";
         $bib[0] =~ s/^[0-9]*\s*/<B>/;
         for ($i=0; $i<=$#bib; $i+=1) {
           last if ($bib[$i] =~ s/\./.<\/B>/);
         }
         for ($i=0;$i<=$#bib;$i+=1) {
           $k=$bib[$i];
           while ($k =~ /(fyi|std|rfc|bcp)([0-9]+)(.*)/i) {
             push @ref,"$1$2";
             $k=$3;
           }
           $done="";
           foreach $j (@ref) {
             next if ($done =~ $j);
             $done .= "$j ";
             $l = $j;
             $l =~ tr/A-Z/a-z/;
             $link=&make_link("$l");
             $bib[$i] =~ s/$j/<A HREF="$link">$j<\/A>/g;
           }
         }
         print "<HTML>\n<TITLE>Citation for $urn</TITLE>\n";

Expires 11/30/98                                                [Page 7]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

         print "<BODY>\n";
         $link=&make_link("$scheme$value");
         print "<H1><A HREF=\"$link\">$scheme$value</A>:</H1>\n";
         foreach $i (@bib) {
           print "$i\n";
         }
         print "</BODY>\n</HTML>\n";
       } else {
         print "Status: 200 OK\r\n";
         print "Content-type: text/html\r\n\r\n";
         $bib[0] =~ s/^[0-9]*\s*//;
         $j=0;
         for ($i=0; $i<=$#bib; $i+=1) {
           $j += ($bib[$i] =~ s/, "/, <B>"/);
           $j += ($bib[$i] =~ s/",/"<\/B>,/);
         }
         for ($i=0;$i<=$#bib;$i+=1) {
           $k=$bib[$i];
           while ($k =~ /(fyi\s|std\s|rfc|bcp)([0-9]+)(.*)/i) {
             push @ref,"$1$2";
             $k=$3;
           }
           $done="";
           foreach $j (@ref) {
             next if ($done =~ $j);
             $done .= "$j ";
             $l = $j;
             $l =~ s/\s//g;
             $l =~ tr/A-Z/a-z/;
             $link=&make_link("$l");
             $bib[$i] =~ s/$j/<A HREF="$link">$j<\/A>/g;
           }
         }
         print "<HTML>\n<TITLE>Citation for $urn</TITLE>\n";
         print "<BODY>\n";
         $link=&make_link("$scheme$value");
         print "<H1><A HREF=\"$link\">$scheme$value</A>:</H1>\n";
         foreach $i (@bib) {
           print "$i\n";
         }
         print "</BODY>\n</HTML>\n";
       }
     }

     sub make_link {
       my($sc);
       my($inarg)=@_;
       ($sc=$1) if ($inarg =~ /([a-z]*)/);

Expires 11/30/98                                                [Page 8]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       return "/$sc/$inarg.ps" if (-e "/ftp/$sc/$inarg.ps");
       return "/$sc/$inarg.html" if (-e "/ftp/$sc/$inarg.html");
       return "/$sc/$inarg.txt";
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "Status: $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2C $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URC resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     };

A.2 I2L

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 URL resolver for the ietf namespace
     #

     my(%pathbase) = (
       rfc => "rfc/rfc",
       fyi => "fyi/fyi",
       std => "std/std",
       bcp => "bcp/bcp",
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";

Expires 11/30/98                                                [Page 9]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
         print "Status: 302 Moved temporarily\n";
         print "Location: $link\n";
         return;
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
         print "Status: 302 Moved temporarily\n";
         print "Location: $link\n";
         return;
       }
       &urn_error("404 Not Found\n");
     }

     sub end {
       my($inarg)=@_;
       return $inarg . "st" if ($inarg =~ /1$/);
       return $inarg . "nd" if ($inarg =~ /2$/);
       return $inarg . "rd" if ($inarg =~ /3$/);
       return $inarg . "th";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       &urn_error("404 Not Found\n")if (!defined $pathbase{$scheme});
       my($txttry)="/ftp/$pathbase{$scheme}$value.txt";
       my($pstry)="/ftp/$pathbase{$scheme}$value.ps";
       my($htmltry)="/ftp/$pathbase{$scheme}$value.html";
     MIME_SWITCH: {
         if ($accept =~ /application\/postscript/ && -f $pstry) {
           print "Status: 302 Moved temporarily\n";
           print "Location: http://$host/$pathbase{$scheme}$value.ps\n\n";

Expires 11/30/98                                               [Page 10]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

           last MIME_SWITCH;
         }
         if ($accept =~ /text\/html/ && -f $htmltry) {
           print "Status: 302 Moved temporarily\n";
           print "Location: http://$host/$pathbase{$scheme}$value.html\n\n";
           last MIME_SWITCH;
         }
         if ($accept =~ /\*\/\*|text\/plain/ && -f $txttry) {
           print "Status: 302 Moved temporarily\n";
           print "Location: http://$host/$pathbase{$scheme}$value.txt\n\n";
           last MIME_SWITCH;
         }
         &urn_error("404 Not Found\n");
       }
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "Status: $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2L $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URL resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     }

A.3 I2Ls

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 URLs resolver for the ietf namespace
     #

     my(@urls);

     my(%pathbase) = (
       rfc => "rfc/rfc",
       fyi => "fyi/fyi",
       std => "std/std",
       bcp => "bcp/bcp"
     );

Expires 11/30/98                                               [Page 11]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
         $link=~s/^\/ftp\///;
         my($ftplink)="ftp://$host/$link";
         my($httplink)="http://$host/$link";
         my($glink)="gopher://$host:70/0/$link";
         if ($accept =~ /text\/uri-list/) { #look for text/uri-list, otherwise text/html
           print "Status: 200 OK\n";
           print "Content-type: text/uri-list\n\n\n";
           print "#$urn\n";
           print "$ftplink\n";
           print "$httplink\n";
           print "$glink\n";
         }
         if ($accept =~ /\*\/\*|text\/html/) {
           print "Status: 200 OK\n";
           print "Content-type: text/html\n\n<HTML>\n";
           print "<head><title>URN Resolution: I2Ls</title></head>\n";
           print "<BODY>\n";
           print "<h1>URN $urn resolves to the following URLs:</h1>\n";
           print "<hr><ul>\n";
           print "<a href=\"$ftplink\">$ftplink</a>\n";
           print "<a href=\"$httplink\">$httplink</a>\n";

Expires 11/30/98                                               [Page 12]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

           print "<a href=\"$glink\">$glink</a>\n";
           print "</UL>\n</body>\n</HTML>\n";
         }
         return;
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
         $link=~s/^\/ftp\///;
         my($ftplink)="ftp://$host/$link";
         my($httplink)="http://$host/$link";
         my($glink)="gopher://$host:70/0/$link";
         if ($accept =~ /text\/uri-list/) { #look for text/uri-list, otherwise text/html
           print "Status: 200 OK\n";
           print "Content-type: text/uri-list\n\n\n";
           print "#$urn\n";
           print "$ftplink\n";
           print "$httplink\n";
           print "$glink\n";
         }
         if ($accept =~ /\*\/\*|text\/html/) {
           print "Status: 200 OK\n";
           print "Content-type: text/html\n\n<HTML>\n";
           print "<head><title>URN Resolution: I2Ls</title></head>\n";
           print "<BODY>\n";
           print "<h1>URN $urn resolves to the following URLs:</h1>\n";
           print "<hr><ul>\n";
           print "<a href=\"$ftplink\">$ftplink</a>\n";
           print "<a href=\"$httplink\">$httplink</a>\n";
           print "<a href=\"$glink\">$glink</a>\n";
           print "</UL>\n</body>\n</HTML>\n";
         }
         return;
       }
       &urn_error("404 Not Found\n");
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       &urn_error("404 Not Found\n")if (!defined $pathbase{$scheme});
       my($try)="/ftp/$pathbase{$scheme}$value.txt";
       if (-f $try) {
         push(@urls, "http://$host/$pathbase{$scheme}$value.txt");
         push(@urls, "ftp://$host/$pathbase{$scheme}$value.txt");
         push(@urls, "gopher://$host:70/0/$pathbase{$scheme}$value.txt");
       }

Expires 11/30/98                                               [Page 13]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       $try="/ftp/$pathbase{$scheme}$value.ps";
       if (-f $try) {
         push(@urls, "http://$host/$pathbase{$scheme}$value.ps");
         push(@urls, "ftp://$host/$pathbase{$scheme}$value.ps");
         push(@urls, "gopher://$host:70/0/$pathbase{$scheme}$value.ps");
       }
       $try="/ftp/$pathbase{$scheme}$value.html";
       if (-f $try) {
         push(@urls, "http://$host/$pathbase{$scheme}$value.html");
         push(@urls, "ftp://$host/$pathbase{$scheme}$value.html");
       }

       &urn_error("404 Not Found\n") if ($#urls == -1);

     MIME_SWITCH: {
         if ($accept =~ /text\/uri-list/) { #look for text/uri-list, otherwise text/html
           print "Status: 200 OK\n";
           print "Content-type: text/uri-list\n\n\n";
           print "#$urn\n";
           foreach $i (@urls) {
             print "$i\n";
           }
           last MIME_SWITCH;
         }
         if ($accept =~ /\*\/\*|text\/html/) {
           print "Status: 200 OK\n";
           print "Content-type: text/html\n\n<HTML>\n";
           print "<head><title>URN Resolution: I2Ls</title></head>\n";
           print "<BODY>\n";
           print "<h1>URN $urn resolves to the following URLs:</h1>\n";
           print "<hr><ul>\n";
           foreach $i (@urls) {
             print "<LI><A HREF=\"$i\">$i</A>\n";
           }
           print "</UL>\n</body>\n</HTML>\n";
           last MIME_SWITCH;
         }
       }
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "Status: $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2Ls $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URL resolution failed for the URN:</h1>\n";

Expires 11/30/98                                               [Page 14]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     }

A.4 I2Ns

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 URNs resolver for the ietf namespace
     #

     my(%cite) = (
       rfc => "/ftp/rfc/rfc-index.txt",
       fyi => "/ftp/fyi/fyi-index.txt",
       std => "/ftp/std/std-index.txt",
       bcp => "/ftp/rfc/bcp-index.txt"
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";

Expires 11/30/98                                               [Page 15]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       if (-f $link) {
         if ($accept =~ /text\/uri-list/) {
             print "Status: 200 OK\n";
             print "Content-type: text/uri-list\n\n\n";
             print "#$urn\n";
             return;
         }
         if ($accept =~ /\*\/\*|text\/html/) {
           print "Status: 200 OK\n";
           print "Content-type: text/html\n\n<HTML>\n";
           print "<head><title>URN Resolution: I2Ns</title></head>\n";
           print "<BODY>\n";
           print "<h1>URN $urn resolves to the following URNs:</h1>\n";
           print "<hr><ul>\n";
           print "</UL>\n</body>\n</HTML>\n";
           return;
         }
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
         if ($accept =~ /text\/uri-list/) {
             print "Status: 200 OK\n";
             print "Content-type: text/uri-list\n\n\n";
             print "#$urn\n";
             return;
         }
         if ($accept =~ /\*\/\*|text\/html/) {
             print "Status: 200 OK\n";
             print "Content-type: text/html\n\n<HTML>\n";
             print "<head><title>URN Resolution: I2Ns</title></head>\n";
             print "<BODY>\n";
             print "<h1>URN $urn resolves to the following URNs:</h1>\n";
             print "<hr><ul>\n";
             print "</UL>\n</body>\n</HTML>\n";
             return;
         }
       }
       &urn_error("404 Not Found\n");
     }

     sub end {
       my($inarg)=@_;
       return $inarg . "st" if ($inarg =~ /1$/);
       return $inarg . "nd" if ($inarg =~ /2$/);
       return $inarg . "rd" if ($inarg =~ /3$/);
       return $inarg . "th";
     }

Expires 11/30/98                                               [Page 16]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       if (!defined $cite{$scheme}) {
         &urn_error("404 Not Found\n");
       }

       $flag = 0;
       open(INPUT, "$cite{$scheme}");
       while (<INPUT>) {
         $flag = 1 if (/^0*$value /);
         if ($flag == 1) {
           last if (/^$/);
           chop;
           push @bib,$_;
         }
       }

       $k=join " ",@bib;
       while ($k =~ /(\S*)\s*(fyi|std|rfc|bcp)\s*([0-9]+)(.*)/i) {
         $k=$4;
         $a=$2; $b=$3;
         if (($a ne $scheme || $b ne $value) && ($1 !~ /obso/i)){
           $a =~ tr/A-Z/a-z/;
           $b =~ s/^0*//;
           push @ref,"urn:ietf:$a:$b";
         }
       }

     MIME_SWITCH: {
         if ($accept =~ /text\/uri-list/) {
             print "Status: 200 OK\n";
             print "Content-type: text/uri-list\n\n\n";
             print "#$urn\n";
             foreach $i (@ref) {
                 print "$i\n";
             }
             last MIME_SWITCH;
         }
       if ($accept =~ /\*\/\*|text\/html/) {
         print "Status: 200 OK\n";
         print "Content-type: text/html\n\n<HTML>\n";
         print "<head><title>URN Resolution: I2Ns</title></head>\n";
         print "<BODY>\n";
         print "<h1>URN $urn resolves to the following URNs:</h1>\n";
         print "<hr><ul>\n";

Expires 11/30/98                                               [Page 17]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

             foreach $i (@ref) {
                 print "<li>$i: Click to resolve using\n";
                 print "<a href=\"http://$host:$port/uri-res/I2C?$i\">I2C</a>,\n";
                 print "<a href=\"http://$host:$port/uri-res/I2L?$i\">I2L</a>,\n";
                 print "<a href=\"http://$host:$port/uri-res/I2Ls?$i\">I2Ls</a>,\n";
                 print "<a href=\"http://$host:$port/uri-res/I2R?$i\">I2R</a>,\n";
                 print "<a href=\"http://$host:$port/uri-res/I2Rs?$i\">I2Rs</a>\n";
             }
         print "</UL>\n</body>\n</HTML>\n";
       }
     }
     }

     sub make_link {
       my($sc);
       my($inarg)=@_;
       ($sc=$1) if ($inarg =~ /([a-z]*)/);
       return "/$sc/$inarg.ps" if (-e "/ftp/$sc/$inarg.ps");
       return "/$sc/$inarg.html" if (-e "/ftp/$sc/$inarg.html");
       return "/$sc/$inarg.txt";
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "Status: $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2Ns $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URC resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     };

A.5 I2R

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 resource resolver for the ietf namespace
     #

     my(%pathbase) = (
       rfc => "rfc/rfc",

Expires 11/30/98                                               [Page 18]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       fyi => "fyi/fyi",
       std => "std/std",
       bcp => "bcp/bcp"
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
           print "Status: 200 OK\n";
           print "Content-type: text/plain\n\n";
           open(FILE, "$link");
           while (<FILE>) {
               print $_;
           }
           close FILE;
         return;
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
           print "Status: 200 OK\n";
           print "Content-type: text/plain\n\n";
           open(FILE, "$link");
           while (<FILE>) {
               print $_;
           }

Expires 11/30/98                                               [Page 19]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

           close FILE;
         return;
       }
       &urn_error("404 Not Found\n");
     }

     sub end {
       my($inarg)=@_;
       return $inarg . "st" if ($inarg =~ /1$/);
       return $inarg . "nd" if ($inarg =~ /2$/);
       return $inarg . "rd" if ($inarg =~ /3$/);
       return $inarg . "th";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       &urn_error("404 Not Found\n")if (!defined $pathbase{$scheme});
       my($txttry)="/ftp/$pathbase{$scheme}$value.txt";
       my($pstry)="/ftp/$pathbase{$scheme}$value.ps";
       my($htmltry)="/ftp/$pathbase{$scheme}$value.html";
     MIME_SWITCH: {
         if ($accept =~ /application\/postscript/ && -f $pstry) {
           print "Status: 200 OK\n";
           print "Content-type: application/postscript\n\n";
           open(FILE, "$pstry");
           while (<FILE>) {
               print $_;
           }
           close FILE;
           last MIME_SWITCH;
         }
         if ($accept =~ /text\/html/ && -f $htmltry) {
             print "Status: 200 OK\n";
             print "Content-type: text/html\n\n";
             open(FILE, "$htmltry");
             while (<FILE>) {
                 print $_;
             }
             close FILE;
             last MIME_SWITCH;
         }
         if ($accept =~ /\*\/\*|text\/plain/ && -f $txttry) {
             print "Status: 200 OK\n";
             print "Content-type: text/plain\n\n";
             open(FILE, "$txttry");

Expires 11/30/98                                               [Page 20]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

             while (<FILE>) {
                 print $_;
             }
             close FILE;
             last MIME_SWITCH;
         }
         &urn_error("404 Not Found\n");
       }
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "Status: $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2R $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URL resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     }

A.6 I2Rs

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 resources resolver for the ietf namespace
     #

     my(@urls);

     my(%pathbase) = (
       rfc => "rfc/rfc",
       fyi => "fyi/fyi",
       std => "std/std",
       bcp => "bcp/bcp"
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",

Expires 11/30/98                                               [Page 21]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       my(@vers,$i);
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
           push(@vers,$link);
       }
       $link="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
           push(@vers,$link);
       }
       &urn_error("404 Not Found\n") if ($#vers==-1);

       print "Status: 200 OK\n";
       print "Content-type: multipart/alternative; boundary=endpart\n\n";
       foreach $i (@vers) {
           print "--endpart\n";
           if ($i =~ /html$/) {
               print "Content-Type: text/html\n\n";
           }
           if ($i =~ /txt$/) {
               print "Content-Type: text/plain\n\n";
           }
           if ($i =~ /ps$/) {
               print "Content-Type: application/postscript\n\n";
           }
           open(FILE, "$i");
           while (<FILE>) {
               print "$_";
           }
           close FILE;

Expires 11/30/98                                               [Page 22]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       }
       print "--endpart\n";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link,@vers);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       &urn_error("404 Not Found\n")if (!defined $pathbase{$scheme});
       my($try)="/ftp/$pathbase{$scheme}$value.txt";
       if (-f $try) {
           push(@vers, $try);
       }
       $try="/ftp/$pathbase{$scheme}$value.ps";
       if (-f $try) {
           push(@vers, $try);
       }
       $try="/ftp/$pathbase{$scheme}$value.html";
       if (-f $try) {
           push(@vers, $try);
       }
       print "Status: 200 OK\n";
       print "Content-type: multipart/alternative; boundary=endpart\n\n";
       foreach $i (@vers) {
           print "--endpart\n";
           if ($i =~ /html$/) {
               print "Content-Type: text/html\n\n";
           }
           if ($i =~ /txt$/) {
               print "Content-Type: text/plain\n\n";
           }
           if ($i =~ /ps$/) {
               print "Content-Type: application/postscript\n\n";
           }
           open(FILE, "$i");
           while (<FILE>) {
               print "$_";
           }
           close FILE;
       }
       print "--endpart\n";
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "Status: $code";

Expires 11/30/98                                               [Page 23]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2Rs $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URL resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     }

Expires 11/30/98                                               [Page 24]

From: Rob Cameron <[email-masked]>
Date: Sun, 17 May 1998 09:43:30 -0700 (PDT)
To: [email-masked]
Sender: [email-masked]
Reply-To: Rob Cameron <[email-masked]>

In considering the implemenation of a URN resolution service
for USINs, I have a question about the I=I operation.  This operation
is currently specified in draft-ietf-urn-resolution-services-06.txt
to require a return value of TRUE or FALSE.  Is there any way
to indicate a value of "I don't know"?

For example, I am contemplating a USIN service that has enough
knowledge to answer TRUE for an I=I request of the following URNs.

urn:USIN:S.ACM/TOPLAS:16@1811
urn:USIN:ISSN/0164-0925:16(6)@1811

Here, the system knows that S.ACM/TOPLAS and ISSN/0164-0925 are
equivalent codes for the same journal and that because TOPLAS is
paginated by volume, the issue number (6) may be omitted when
specifying an article by page number.

However, the system may not initially have the knowledge required
to specify that the following USINs are equivalent:

urn:USIN:S.ACM/TOPLAS:16@1811|ref(17)
urn:USIN:S.ACM/TODS:6@351

Here, these USINs are equivalent because reference 17 of the TOPLAS
article is indeed a reference to the TODS article.  In the initial
development of a USIN system, there probably won't be enough 
information to verify this.

Thus, in support of the USIN system (and any other system that does
not have complete knowledge of the denotation space of the identifiers
involved), I can't implement an I=I service without some way of
indicating "Don't Know" as an alternative to TRUE or FALSE.

I suppose that could be done as some kind of error condition, except
that it does not really represent an error on the client side;  it
is a perfectly reasonable request to ask whether to (correct) USINs
are equivalent.

Robert D. Cameron, Associate Professor           [email-masked]
School of Computing Science
Simon Fraser University
Burnaby, B.C., Canada  V5A 1S6
Internet Electronic Library Project
http://elib.cs.sfu.ca/

Date: Fri, 15 May 1998 18:31:43 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [URN] A URN WG Status report
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

I am more than a little surprised that you want to move NAPTR to
standards track.  It wasn't standards track, and I don't think it
should be.  It really is experimental.  We do not have enough
experience with NAPTR or other documented alternatives to say that
this should be THE standard or even A standard.

			Karen

Date: Fri, 15 May 1998 16:22:58 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Ryan Moats <[email-masked]>
cc: "[email-masked]" <[email-masked]>
Subject: Re: [URN] A URN WG Status report
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Fri, 15 May 1998, Ryan Moats wrote:
> >   URN Syntax 
> >      Status:  Proposed Standard Protocol
> >      Proposed actions:  ask to move to Draft Standard
> 
> This has no date on it, so I assume that you are thinking of either:

Actually, this is a point that I intended to bring up specifically for
discussion on the mailing list, to get some input, before making
an action plan for taking care of it.  Similarly for the proposal to
move NAPTR to the standards track.  Dates can follow ;-)

Leslie.

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

  "You can lead people to facts, but              Leslie Daigle
       you cannot make them think."               
                                                  Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: "Ryan Moats" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 15 May 98 14:21:21 -0600
Priority: Normal
Subject: Re: [URN] A URN WG Status report
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

>   URN Syntax 
>      Status:  Proposed Standard Protocol
>      Proposed actions:  ask to move to Draft Standard

This has no date on it, so I assume that you are thinking of either:

1) shutting down the WG and letting the follow on group handle it
2) waiting until the registration documents are finished before adding
this to our docket.

I don't care which, I'm just satisfying my curiosity.

Ryan

Date: Fri, 15 May 1998 14:52:35 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], Patrik Faltstrom <[email-masked]>
Subject: [URN] A URN WG Status report
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hello all,

Many thanks to the folks who contributed info about the URN work that they
have done.  Attached is a survey, or "status report" on the work of this
group and the systems that have been built around this work.

I've outlined which documents remain to be finished (and have bravely
assigned target dates :->  There are a couple of existing RFCs that should
perhaps be re-examined in terms of their status.

Leslie.

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

  "You can lead people to facts, but              Leslie Daigle
       you cannot make them think."               
                                                  Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

============================================================
URN Status Report
============================================================
Leslie L. Daigle
IETF URN WG Co-Chair
May 15, 1998.

----------------------------------------
Working Group Documentation
----------------------------------------

The required documentation is just about finished -- minor changes required
to some documents, and one (small) document left to construct.  There
is some discussion about progressing some of the RFCs that have been out
for a year.  Details follow.

Current Internet-Drafts:
-----------------------

   URN Namespace Definition Mechanisms 
      Work required:
	. Concrete references to appropriate "IANA-like" body
	. Minor textual revisions
      Target date:
	. June 1, 1998
	
   URI Resolution Services Necessary for URN Resolution 
      Work required:
	. minor editorial changes, requested by AD
	. resubmission for (experimental) RFC
      Target date:
	. June 1, 1998.

   A URN Namespace for IETF Documents 
      Work required:
	. minor editorial changes (done)
	. final concordance with Namespace Definition Mechanisms
	  paper (if changes necessary)
      Target date:
	. June 15, 1998.

Documents still Required:
------------------------

   NAPTR Registration Procedures document
      Target date:  June 15, 1998.

Request For Comments (RFCs): 
---------------------------

   URN Syntax 
      Status:  Proposed Standard Protocol
      Proposed actions:  ask to move to Draft Standard

   Resolution of Uniform Resource Identifiers using the Domain Name System 
   (RFC2168)
      Status:  Experimental Protocol
      Proposed actions:  ask to move to standards-track; though it may
	not be the best global NID, the proposed implementation seems 
	stable within itself.
     
   A Trivial Convention for using HTTP in URN Resolution (RFC 2169) 
      Status:  Experiemental Protocol
      Proposed action:  none

   Architectural Principles of Uniform Resource Name Resolution (RFC 2276) 
      Status:  Informational
      Proposed action: none

   Using Existing Bibliographic Identifiers as Uniform Resource Names 
   (RFC 2288)
      Status:  Informational
      Proposed action: none

----------------------------------------
Related Work
----------------------------------------

Apart from implementations developed specifically in conjunction with the
URN WG, related initiatives have developed software and/or naming systems
that are complementary to, and potentially with, URNs.

CNRI's Handles:
--------------

Put forward as one of the original proposals for implementing the URN
concept, the Handles technology is being pursued by CNRI as a 

"[...]distributed computer system which stores names, or handles, of digital 
 items and which can quickly resolve those names into the information 
 necessary to locate and access the items. It was designed by CNRI as a 
 general purpose global system for the reliable management of information on 
 networks such as the Internet over long periods of time[...]" 
 (see http://www.handle.net)

The particular implementation choices make this system more applicable for
some needs of URNs than others (hence the decision to pursue a more 
framework-oriented solution to URNs within the IETF).  One of the applications
for which it is being used is the Digital Object Identifier, described below.

See http://www.handle.net/  for more information about CNRI's Handles.

DOIs ("Digital Object Identifiers"):
-----------------------------------

Now supported through the "International DOI Foundation", this is an 
initiative to address the Publishing Industry's needs for identification
and manipulation of electronic documents.  DOIs are still in evolution;
although the syntax and management issues seem to be pretty much fixed, 
the full machinery for supporting digital commerce for the publishing
industry awaits clearer definition of that community's specific requirements.

Formally introduced at the Frankfurt Bookfair in October, 1997, several
publishers have started testing DOIs, and tens of thousands have been
assigned as part of their projects.

The current DOI system is based on CNRI's Handle technology.  A couple of 
sample DOIs are:

Elsevier:
	10.1016/S1384107697000225  which is resolvable through

	http://hdl.handle.net/10.1016/S1384107697000225

Wiley:
	10.1002/0002-8231(199601)47:1<1:SPOTEO>2.3.TX;2-K  which is resolvable
	through

	http://doi.wileynpt.com/10.1002/0002-8231(199601)47:1<1:SPOTEO>2.3.TX;2-K

As I understand it, the "10." identifies the only top-level being used
by the DOI Foundation currently, and the 4 digits afterwards indicate the 
specific publisher which is responsible for the assignment/management of the 
remainder of the DOI.  

The expectation is that DOIs, will be put forward as a URN namespace to allow 
integration with general URI software.  For example,

	urn:doi:10.1016/S1384107697000225 

See http://www.doi.org/  for more details about DOIs and the IDF.

Persistent Document Identifiers (PDIs)

Developed for US government document series, PDIs are intended primarily as 
permanent identifiers for archival reference to long-lived documents, and
tackle many specific problems related to that activity (including 
intracollection fragment references, etc).  They are expected to be made 
available as a URN namespace, and have already been deployed -- see
 
	http://www.pub.whitehouse.gov

to see the system in action.  For example, 

	pdi://oma.eop.gov.us/1993/1/21/1.header.1

is resolved through the proxy:

	http://www.pub.whitehouse.gov/uri-res/I2R?urn:pdi://oma.eop.gov.us/1993/1/21/1.header.1

This system is documented in:

	http://www.ietf.org/internet-drafts/draft-mallery-urn-pdi-00.txt

W3 Identifier Resolution Extensions (WIRE)

This work, still very experimental in nature, explores the possibility of
incorporating resolution extensions directly into the HTTP protocol, through
the use of new redirect mechanisms.

See:

       http://www.ietf.org/internet-drafts/draft-girod-w3-id-res-ext-00.txt
       http://www.ietf.org/internet-drafts/draft-girod-urn-res-using-wire-00.txt

----------------------------------------
Technology
----------------------------------------

Apart from the extensions to BIND to support the NAPTR DNS record, (available
in distributions of BIND for the past couple of years), most of the technology 
that has been developed for URNs has been proprietary and/or prototype in 
nature.  See below for more information on specific prototype projects.

Prototype source code has been made available (see Ryan Moats' IETF namespace
document) that demonstrates the feasibility of using the URN resolution
methods outlined by this group.  

Beyond that, a user-installable software patch will be available (Michael 
Mealling, Network Solutions Inc) to enable Microsoft's Internet Explorer
to handle URIs of the form "URN:". The expectation is that future versions of 
Netscape (the source for which is now available) will incorporate this 
extension.  There is no indication that Microsoft's Internet Explorer won't 
follow suit...

----------------------------------------
Prototype/Deployed Systems
----------------------------------------

Live systems:
------------

"National Bibliography Numbers (NBNs)", Juha Hakala, National Library of Finland 
In the context of creating a large-scale index of web resources (Nordic
Web Index), this work has focused on using NBNs (identifiers assigned
to items that do not have ISBNs, or ISSNs) within URNs to form a permanent
identifier for web documents.  

Currently, the initiative is integrated with the overall Nordic Web Indexing
Project (national web indexes for Nordic countries).  A web page is available
for obtaining a URN for resources within the scope of Finland and Sweden, 
and users are encouraged to use that identifier within the metadata of
their documents so that search services will pick it up.  "Resolution" is 
currently handled through the NWI project's search pages -- i.e., searching 
for a particular URN will yield the "hits" of documents that contain it/refer 
to it.

The NBN namespace is set up to assign 8 000 identifiers this year; the
space will be extended if need exceeds that bound.

The NBN URN generator service went live on May 5, 1998.  The URN-assignment
page for resources in Finland and Sweden is:

	Finnish:
	   http://linnea.helsinki.fi/cgi-bin/urn.pl 
	English:
	   http://www.lub.lu.se/cgi-bin/nmurn.pl

Explanatory information is available from:

	http://www.lub.lu.se/metadata/URN-help.html

Software components:
-------------------

Michael Mealling, Network Solutions Inc ([email-masked])

This is a user-installable extension that enables Microsoft's Internet
Explorer to handle URIs of the form "URN:".  It supports the I2R, I2L,
I2Ls and I2C services (allowing the user to configure whether a dialog
is popped up to select an L for I2Ls, or one is picked at random), and
the thttp, rwhois, and rcds (when stabilized) protocols.

This code has been tested against the thttp server used by Ryan Moats.

Ryan Moats, AT&T ([email-masked])

Perl scripts for I2C, I2L, I2Ls, I2Ns, I2R, I2Rs resolution of the
proposed "IETF" namespace, using the thttp protocol.  This code is 
available as part of the IETF namespace Internet-Draft.

Ryan also has what he describes as a "proof of concept" URN browser
written in perl.

Experimental prototype systems:
------------------------------

Renato Ianella, DSTC Pty ([email-masked])

The DSTC did some work a couple of years ago on a simple URN 
resolver.  It was done before any of the URN documents were really
finalized, so it never got beyond prototype state, but it was
tested for interoperability with Dirk van Gulik's system (no info
currently available); each system could resolve the other's URNs.  
Approximately 30 URNs were assigned, with URC metadata stored in an X.500 
database.

Some of this work is described in a conference paper:

	http://www.dstc.edu.au/RDU/reports/APweb96/index.html

A key lesson from the work was the critical need for browser support
for URNs in order to facilitate use and promotion of the identifiers.

Dirk Willem van Gulik, JRC ([email-masked])

[No info available]

Ron Daniel Jr., Ed Balas, LANL

This focused on the development of a URN library (Ed Balas), which will be
made publicly available, and has already been used as the inspiration for
some of the software tools mentioned above. The software does a first
check for "known" namespaces, falling back to NAPTR if namespaces are not
recognized locally.  Resolution is done through thttp.  Only a few URNs
were assigned/resolved as part of this experimental project.

Key lesson learned:  "Maintenance, maintenance, maintenance".

Date: Wed, 6 May 1998 15:24:56 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-ietf-05.txt
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

   My question about "isoc" vs. "ietf" derives from the 
   RFC documentation at http://www.isi.edu/rfc-editor/overview.html
   which suggests that RFCs may be produced either by the IETF or
   by individual submission to the RFC Editor.

But, those documents submitted to the RFC Editor are still going
through an IETF process, not an ISOC process.

			Karen

From: Rob Cameron <[email-masked]>
Date: Wed, 6 May 1998 09:29:17 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-ietf-05.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Rob Cameron <[email-masked]>

My question about "isoc" vs. "ietf" derives from the 
RFC documentation at http://www.isi.edu/rfc-editor/overview.html
which suggests that RFCs may be produced either by the IETF or
by individual submission to the RFC Editor.

Date: Wed, 6 May 1998 11:04:53 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-ietf-05.txt
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

I agree that we should probably stick with "ietf", for the id for the
namespace.  First, we are doing this with the implicit (maybe
explicit) agreement of the IETF not the ISOC.  We really don't want to
get them involved in this particular namespace.  Second, in Munich we
had a lengthy discussion about assigning only numbers as NIDs because
people shouldn't be reading meaning into them.  I for one would like
to see us move in that direction, away from human meaningful ids, at
this level of abstraction.

So, now I've argued both sides of the coin - that it should be "ietf"
and that it shouldn't, but I can see no good reason for it being "isoc".

			Karen

Date: Wed, 6 May 1998 10:08:22 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Rob Cameron <[email-masked]>
cc: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-ietf-05.txt
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Tue, 5 May 1998, Rob Cameron wrote:
> In principle, my understanding is that these documents are
> managed under the auspices of the Internet Society.  Would not
> "isoc" be a better namespace?

I'd argue that "IETF" is actually a clearer/better label in that the
namespace is about the documentation produced by the IETF, as opposed
to all ISOC-managed or ISOC-specific documentation.

Leslie.

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

  "You can lead people to facts, but              Leslie Daigle
       you cannot make them think."               
                                                  Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: "Ryan Moats" <[email-masked]>
To: "Rob Cameron" <[email-masked]>
Cc: "URN mailing list" <[email-masked]>
Date: Wed, 06 May 98 09:00:05 -0600
Priority: Normal
Subject: Re: [URN] Pre-release of draft-ietf-urn-ietf-05.txt
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Tue, 5 May 1998 13:30:28 -0700 (PDT), Rob Cameron wrote:

>Some comments/questions.
>
>In principle, my understanding is that these documents are
>managed under the auspices of the Internet Society.  Would not
>"isoc" be a better namespace?

That's part of the fun of this namespace.  I'm not married to the IETF
name, although the minutes probably belong there rather than in ISOC.

>I note that there is a date computation that generates strings
>like "98jan".  Is there not a way to avoid the Y2K problem here?

This is an artifact of how minutes are currently stored.  If the minutes 
store structure changes, then this will change.  The resolver itself
has no Y2K limitation except for those imposed by underlying data stores.

And no, I'm not going to rework the IETF minute strcuture just for this.

Ryan

From: Rob Cameron <[email-masked]>
Date: Tue, 5 May 1998 13:30:28 -0700 (PDT)
To: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-ietf-05.txt
Sender: [email-masked]
Reply-To: Rob Cameron <[email-masked]>

Some comments/questions.

In principle, my understanding is that these documents are
managed under the auspices of the Internet Society.  Would not
"isoc" be a better namespace?

I note that there is a date computation that generates strings
like "98jan".  Is there not a way to avoid the Y2K problem here?

Rob Cameron
Universal Serial Item Name Project
http://elib.cs.sfu.ca/USIN/

From: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Date: Tue, 05 May 98 11:09:41 -0600
Priority: Normal
Subject: [URN] Pre-release of draft-ietf-urn-ietf-05.txt
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Here is a pre-release of ietf-05.txt.  I've made some
changes based on some comments.  I'll be double checking
the Perl scripts in the appendix and submitting to the
I-D editor in a week or two...

Ryan

==========cut here

Internet-Draft                                                Ryan Moats
draft-ietf-urn-ietf-05.txt                                          AT&T
Expires in six months                                           May 1998
pl 10.0i

                   A URN Namespace for IETF Documents
                  Filename: draft-ietf-urn-ietf-05.txt

Status of This Memo

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

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

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

Abstract

   A system for Uniform Resource Names (URNs) must be capable of
   supporting new naming systems.  As an example of proposing a new
   namespace, this document proposes the "ietf" namespace.  This
   namespace consists of the RFC family of documents (RFCs, STDs, FYIs,
   and BCPs) developed by the IETF and published by the RFC editor and
   the minutes of working groups (WG) and birds of a feather (BOF)
   meetings that occur during IETF conferences.  Both the current URN
   framework and URN syntax support this namespace.

0.1 Changes from -02

   This document has been restructured to use the template proposed in
   draft-ietf-urn-nid-req-03.txt.  Example Perl scripts for resolving
   this namespace have been supplied in an Appendix.

0.2 Changes from -03

   Text was added to the template clarifying persistence and uniqueness.
   Support for the BCP document series added to the examples and the
   ABNF.

Expires 11/30/98                                                [Page 1]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

0.3 Changes from -04

   More clarifications for the persistence section.  In addition,
   cleaned up some typos and ensured that the Appendix examples are
   functional

1. Introduction

   This document proposes the "ietf" namespace, which consists of the
   RFC family of documents (RFCs, STDs, FYIs, and BCPs) developed by the
   IETF and published by the RFC editor and the minutes of working
   groups (WG) and birds of a feather (BOF) meetings that occur during
   IETF conferences.

   The namespace specification is for a formal namespace.

2. Specification Template

     Namespace ID:

          "ietf" requested.

     Declared registrant of the namespace:

          Ryan Moats
          [email-masked]

     Declaration of structure:

          The identifier has the following ABNF [2] specification:

          NSS = (family ":" number) / ("mtg-" number "-" wgbofname)
          family = "rfc" / "std" / "fyi" / "bcp"
          number = 1*DIGIT
          wgbofname = 1*LETDIGIT
          LETDIGIT = DIGIT / %x41-%x5a / %x61-%x7a
          DIGIT = %x30-%x39

          If the IESG (or it successor) adds a new document
          series, this ABNF specification will need to be
          updated.  Further, if a working group or BOF is
          created that used characters outside the range of this
          ABNF specification, this specification will need to be
          updated.  Any system intended to resolve names for
          this namespace should be written with the awareness
          that this could occur at any time.

     Identifier uniqueness considerations:

          Because the rfc-editor assigns the RFC number uniquely
          these URNs are unique.  Since the mapping between RFCs
          and other rfc-editor document series (STDs, FYIs or
          BCPs) is not necessarily one-to-one, uniqueness of
          STDs, FYIs and BCPs are defined based on the document

Expires 11/30/98                                                [Page 2]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

          mappings maintained by the RFC Editor (the index files
          "rfc-index.txt", "fyi-index.txt", "bcp-index.txt" and
          "std-index.txt") are defined to be the definitive
          statement of the assignment of RFC Family URNs in this
          namespace.  The meeting minutes portion of the
          namespace is guaranteed unique because the URN
          includes the sequence number of the IETF conference.

     Identifier persistence considerations:

          Persistence of the URNs of this namespace is
          independent of the mutability of the underlying
          documents.  A URN once assigned will never be
          reassigned to a different resource; the assignment is
          persistent and immutable.  Distinct from this, the
          resources identified as RFCs are immutable, whereas
          the other sorts of documents, STDs, FYIs, and BCPs are
          not.  They may be composites of one or more RFCs and
          the set of RFCs that comprise them may change with
          time.  It is important to note that this mutability of
          some resources is independent of the immutability of
          URN assignment to a resource.

     Process of identifier assignment:

          Assignment of URNs from this namespace occurs in two
          ways.  The first is when a new RFC, FYI, STD or BCP is
          passed by the IESG and published by the RFC
          Editor. This new document will have a new series
          number and will therefore define a new URN.  The
          document mappings maintained by the RFC Editor (the
          index files "rfc-index.txt", "fyi-index.txt",
          "bcp-index.txt" and "std-index.txt") are defined to be
          the definitive statement of the assignment of RFC
          Family URNs in this namespace.

          The second way a URN is assigned is when a working
          group or birds of a feather files meeting minutes as
          part of an IETF conference.  The list of minutes
          maintained by the IETF for each working group and
          conference in the subtree pointed at by the URL
          ftp://ietf.org/ietf/ is considered the definitive
          assignment of URNs for working group or birds of a
          feather minutes.

     Process of identifier resolution:

          A mirrored copy of the underlying documentation is
          required to resolve these URNs.  Resolution via
          HTTP is accomplished by a set of simple Perl cgi-bin
          scripts presented in Appendix A.

     Rules for Lexical Equivalence:

Expires 11/30/98                                                [Page 3]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

          The entire URN is case-insensitive.

     Conformance with URN Syntax:

          There are no additional characters reserved.

     Validation mechanism:

          None specified.

     Scope:

          Global.

3. Security Considerations

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

4. Acknowledgments

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

4. References

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

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

[2]         D. Crocker, P. Overell, "Augmented BNF for Syntax Specifica-
            tions: ABNF," RFC 2234, November 1997.

5. Author's Address

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

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

Expires 11/30/98                                                [Page 4]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

Appendix A.  Example Resolution Scripts

   The following scripts are examples that can be used for resolving
   URNs in this namespace.

A.1 I2C

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 URC resolver for the ietf namespace
     #

     my(%cite) = (
       rfc => "/ftp/rfc/rfc-index.txt",
       fyi => "/ftp/fyi/fyi-index.txt",
       std => "/ftp/std/std-index.txt",
       bcp => "/ftp/rfc/bcp-index.txt"
     );
     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
         print "HTTP/1.0 200 OK\r\n";
         print "Content-type: text/html\r\n\r\n";
         print "<HTML>\n<TITLE>Citation for $urn</TITLE>\n";
         print "<BODY>\n";
         print "<H1><A HREF=\"$link\">$urn</A>:</H1>\n";
         print "Minutes of the $sesnam working group from the " . &end($ietfnum) . " IETF";
         print "</BODY>\n</HTML>\n";

Expires 11/30/98                                                [Page 5]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

         return;
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
         print "HTTP/1.0 200 OK\r\n";
         print "Content-type: text/html\r\n\r\n";
         print "<HTML>\n<TITLE>Citation for $urn</TITLE>\n";
         print "<BODY>\n";
         print "<H1><A HREF=\"$link\">$urn</A>:</H1>\n";
         print "Minutes of the $sesnam working group from the " . &end($ietfnum) . " IETF";
         print "</BODY>\n</HTML>\n";
         return;
       }
       &urn_error("404 Not Found\n");
     }

     sub end {
       my($inarg)=@_;
       return $inarg . "st" if ($inarg =~ /1$/);
       return $inarg . "nd" if ($inarg =~ /2$/);
       return $inarg . "rd" if ($inarg =~ /3$/);
       return $inarg . "th";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       if (!defined $cite{$scheme}) {
         &urn_error("404 Not Found\n");
       }

       $flag = 0;
       open(INPUT, "$cite{$scheme}");
       while (<INPUT>) {
         $flag = 1 if (/^0*$value /);
         if ($flag == 1) {
           last if (/^$/);
           chop;
           push @bib,$_;
         }
       }

       if ($scheme ne "rfc") {
         print "HTTP/1.0 200 OK\r\n";
         print "Content-type: text/html\r\n\r\n";
         $bib[0] =~ s/^[0-9]*\s*/<B>/;
         for ($i=0; $i<=$#bib; $i+=1) {
           last if ($bib[$i] =~ s/\./.<\/B>/);
         }
         for ($i=0;$i<=$#bib;$i+=1) {
           $k=$bib[$i];
           while ($k =~ /(fyi|std|rfc|bcp)([0-9]+)(.*)/i) {

Expires 11/30/98                                                [Page 6]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

             push @ref,"$1$2";
             $k=$3;
           }
           $done="";
           foreach $j (@ref) {
             next if ($done =~ $j);
             $done .= "$j ";
             $l = $j;
             $l =~ tr/A-Z/a-z/;
             $link=&make_link("$l");
             $bib[$i] =~ s/$j/<A HREF="$link">$j<\/A>/g;
           }
         }
         print "<HTML>\n<TITLE>Citation for $urn</TITLE>\n";
         print "<BODY>\n";
         $link=&make_link("$scheme$value");
         print "<H1><A HREF=\"$link\">$scheme$value</A>:</H1>\n";
         foreach $i (@bib) {
           print "$i\n";
         }
         print "</BODY>\n</HTML>\n";
       } else {
         print "HTTP/1.0 200 OK\r\n";
         print "Content-type: text/html\r\n\r\n";
         $bib[0] =~ s/^[0-9]*\s*//;
         $j=0;
         for ($i=0; $i<=$#bib; $i+=1) {
           $j += ($bib[$i] =~ s/, "/, <B>"/);
           $j += ($bib[$i] =~ s/",/"<\/B>,/);
         }
         for ($i=0;$i<=$#bib;$i+=1) {
           $k=$bib[$i];
           while ($k =~ /(fyi\s|std\s|rfc|bcp)([0-9]+)(.*)/i) {
             push @ref,"$1$2";
             $k=$3;
           }
           $done="";
           foreach $j (@ref) {
             next if ($done =~ $j);
             $done .= "$j ";
             $l = $j;
             $l =~ s/\s//g;
             $l =~ tr/A-Z/a-z/;
             $link=&make_link("$l");
             $bib[$i] =~ s/$j/<A HREF="$link">$j<\/A>/g;
           }
         }
         print "<HTML>\n<TITLE>Citation for $urn</TITLE>\n";
         print "<BODY>\n";
         $link=&make_link("$scheme$value");
         print "<H1><A HREF=\"$link\">$scheme$value</A>:</H1>\n";
         foreach $i (@bib) {
           print "$i\n";
         }

Expires 11/30/98                                                [Page 7]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

         print "</BODY>\n</HTML>\n";
       }
     }

     sub make_link {
       my($sc);
       my($inarg)=@_;
       ($sc=$1) if ($inarg =~ /([a-z]*)/);
       return "/$sc/$inarg.ps" if (-e "/ftp/$sc/$inarg.ps");
       return "/$sc/$inarg.html" if (-e "/ftp/$sc/$inarg.html");
       return "/$sc/$inarg.txt";
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "HTTP/1.0 $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2C $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URC resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     };

A.2 I2L

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 URL resolver for the ietf namespace
     #

     my(%pathbase) = (
       rfc => "rfc/rfc",
       fyi => "fyi/fyi",
       std => "std/std",
       bcp => "bcp/bcp",
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

Expires 11/30/98                                                [Page 8]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
         print "HTTP/1.0 302 Moved temporarily\n";
         print "Location: $link\n";
         return;
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
         print "HTTP/1.0 302 Moved temporarily\n";
         print "Location: $link\n";
         return;
       }
       &urn_error("404 Not Found\n");
     }

     sub end {
       my($inarg)=@_;
       return $inarg . "st" if ($inarg =~ /1$/);
       return $inarg . "nd" if ($inarg =~ /2$/);
       return $inarg . "rd" if ($inarg =~ /3$/);
       return $inarg . "th";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       &urn_error("404 Not Found\n")if (!defined $pathbase{$scheme});
       my($txttry)="/ftp/$pathbase{$scheme}$value.txt";
       my($pstry)="/ftp/$pathbase{$scheme}$value.ps";
       my($htmltry)="/ftp/$pathbase{$scheme}$value.html";
     MIME_SWITCH: {
         if ($accept =~ /application\/postscript/ && -f $pstry) {
           print "HTTP/1.0 302 Moved temporarily\n";
           print "Location: http://$host/$pathbase{$scheme}$value.ps\n\n";
           last MIME_SWITCH;
         }
         if ($accept =~ /text\/html/ && -f $htmltry) {
           print "HTTP/1.0 302 Moved temporarily\n";

Expires 11/30/98                                                [Page 9]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

           print "Location: http://$host/$pathbase{$scheme}$value.html\n\n";
           last MIME_SWITCH;
         }
         if ($accept =~ /\*\/\*|text\/plain/ && -f $txttry) {
           print "HTTP/1.0 302 Moved temporarily\n";
           print "Location: http://$host/$pathbase{$scheme}$value.txt\n\n";
           last MIME_SWITCH;
         }
         &urn_error("404 Not Found\n");
       }
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "HTTP/1.0 $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2L $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URL resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     }

A.3 I2Ls

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 URLs resolver for the ietf namespace
     #

     my(@urls);

     my(%pathbase) = (
       rfc => "rfc/rfc",
       fyi => "fyi/fyi",
       std => "std/std",
       bcp => "bcp/bcp"
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",

Expires 11/30/98                                               [Page 10]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
         $link=~s/^\/ftp\///;
         my($ftplink)="ftp://$host/$link";
         my($httplink)="http://$host/$link";
         my($glink)="gopher://$host:70/0/$link";
         if ($accept =~ /text\/uri-list/) { #look for text/uri-list, otherwise text/html
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/uri-list\n\n\n";
           print "#$urn\n";
           print "$ftplink\n";
           print "$httplink\n";
           print "$glink\n";
         }
         if ($accept =~ /\*\/\*|text\/html/) {
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/html\n\n<HTML>\n";
           print "<head><title>URN Resolution: I2Ls</title></head>\n";
           print "<BODY>\n";
           print "<h1>URN $urn resolves to the following URLs:</h1>\n";
           print "<hr><ul>\n";
           print "<a href=\"$ftplink\">$ftplink</a>\n";
           print "<a href=\"$httplink\">$httplink</a>\n";
           print "<a href=\"$glink\">$glink</a>\n";
           print "</UL>\n</body>\n</HTML>\n";
         }
         return;
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
         $link=~s/^\/ftp\///;
         my($ftplink)="ftp://$host/$link";
         my($httplink)="http://$host/$link";
         my($glink)="gopher://$host:70/0/$link";
         if ($accept =~ /text\/uri-list/) { #look for text/uri-list, otherwise text/html
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/uri-list\n\n\n";
           print "#$urn\n";
           print "$ftplink\n";

Expires 11/30/98                                               [Page 11]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

           print "$httplink\n";
           print "$glink\n";
         }
         if ($accept =~ /\*\/\*|text\/html/) {
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/html\n\n<HTML>\n";
           print "<head><title>URN Resolution: I2Ls</title></head>\n";
           print "<BODY>\n";
           print "<h1>URN $urn resolves to the following URLs:</h1>\n";
           print "<hr><ul>\n";
           print "<a href=\"$ftplink\">$ftplink</a>\n";
           print "<a href=\"$httplink\">$httplink</a>\n";
           print "<a href=\"$glink\">$glink</a>\n";
           print "</UL>\n</body>\n</HTML>\n";
         }
         return;
       }
       &urn_error("404 Not Found\n");
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       &urn_error("404 Not Found\n")if (!defined $pathbase{$scheme});
       my($try)="/ftp/$pathbase{$scheme}$value.txt";
       if (-f $try) {
         push(@urls, "http://$host/$pathbase{$scheme}$value.txt");
         push(@urls, "ftp://$host/$pathbase{$scheme}$value.txt");
         push(@urls, "gopher://$host:70/0/$pathbase{$scheme}$value.txt");
       }
       $try="/ftp/$pathbase{$scheme}$value.ps";
       if (-f $try) {
         push(@urls, "http://$host/$pathbase{$scheme}$value.ps");
         push(@urls, "ftp://$host/$pathbase{$scheme}$value.ps");
         push(@urls, "gopher://$host:70/0/$pathbase{$scheme}$value.ps");
       }
       $try="/ftp/$pathbase{$scheme}$value.html";
       if (-f $try) {
         push(@urls, "http://$host/$pathbase{$scheme}$value.html");
         push(@urls, "ftp://$host/$pathbase{$scheme}$value.html");
       }

       &urn_error("404 Not Found\n") if ($#urls == -1);

     MIME_SWITCH: {
         if ($accept =~ /text\/uri-list/) { #look for text/uri-list, otherwise text/html
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/uri-list\n\n\n";
           print "#$urn\n";
           foreach $i (@urls) {
             print "$i\n";
           }

Expires 11/30/98                                               [Page 12]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

           last MIME_SWITCH;
         }
         if ($accept =~ /\*\/\*|text\/html/) {
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/html\n\n<HTML>\n";
           print "<head><title>URN Resolution: I2Ls</title></head>\n";
           print "<BODY>\n";
           print "<h1>URN $urn resolves to the following URLs:</h1>\n";
           print "<hr><ul>\n";
           foreach $i (@urls) {
             print "<LI><A HREF=\"$i\">$i</A>\n";
           }
           print "</UL>\n</body>\n</HTML>\n";
           last MIME_SWITCH;
         }
       }
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "HTTP/1.0 $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2Ls $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URL resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     }

A.4 I2Ns

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 URNs resolver for the ietf namespace
     #

     my(%cite) = (
       rfc => "/ftp/rfc/rfc-index.txt",
       fyi => "/ftp/fyi/fyi-index.txt",
       std => "/ftp/std/std-index.txt",
       bcp => "/ftp/rfc/bcp-index.txt"
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",

Expires 11/30/98                                               [Page 13]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
         if ($accept =~ /text\/uri-list/) {
             print "HTTP/1.0 200 OK\n";
             print "Content-type: text/uri-list\n\n\n";
             print "#$urn\n";
             return;
         }
         if ($accept =~ /\*\/\*|text\/html/) {
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/html\n\n<HTML>\n";
           print "<head><title>URN Resolution: I2Ns</title></head>\n";
           print "<BODY>\n";
           print "<h1>URN $urn resolves to the following URNs:</h1>\n";
           print "<hr><ul>\n";
           print "</UL>\n</body>\n</HTML>\n";
           return;
         }
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
         if ($accept =~ /text\/uri-list/) {
             print "HTTP/1.0 200 OK\n";
             print "Content-type: text/uri-list\n\n\n";
             print "#$urn\n";
             return;
         }
         if ($accept =~ /\*\/\*|text\/html/) {
             print "HTTP/1.0 200 OK\n";
             print "Content-type: text/html\n\n<HTML>\n";
             print "<head><title>URN Resolution: I2Ns</title></head>\n";
             print "<BODY>\n";
             print "<h1>URN $urn resolves to the following URNs:</h1>\n";
             print "<hr><ul>\n";
             print "</UL>\n</body>\n</HTML>\n";

Expires 11/30/98                                               [Page 14]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

             return;
         }
       }
       &urn_error("404 Not Found\n");
     }

     sub end {
       my($inarg)=@_;
       return $inarg . "st" if ($inarg =~ /1$/);
       return $inarg . "nd" if ($inarg =~ /2$/);
       return $inarg . "rd" if ($inarg =~ /3$/);
       return $inarg . "th";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       if (!defined $cite{$scheme}) {
         &urn_error("404 Not Found\n");
       }

       $flag = 0;
       open(INPUT, "$cite{$scheme}");
       while (<INPUT>) {
         $flag = 1 if (/^0*$value /);
         if ($flag == 1) {
           last if (/^$/);
           chop;
           push @bib,$_;
         }
       }

       $k=join " ",@bib;
       while ($k =~ /(\S*)\s*(fyi|std|rfc|bcp)\s*([0-9]+)(.*)/i) {
         $k=$4;
         $a=$2; $b=$3;
         if (($a ne $scheme || $b ne $value) && ($1 !~ /obso/i)){
           $a =~ tr/A-Z/a-z/;
           $b =~ s/^0*//;
           push @ref,"urn:ietf:$a:$b";
         }
       }

     MIME_SWITCH: {
         if ($accept =~ /text\/uri-list/) {
             print "HTTP/1.0 200 OK\n";
             print "Content-type: text/uri-list\n\n\n";
             print "#$urn\n";
             foreach $i (@ref) {
                 print "$i\n";
             }
             last MIME_SWITCH;

Expires 11/30/98                                               [Page 15]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

         }
       if ($accept =~ /\*\/\*|text\/html/) {
         print "HTTP/1.0 200 OK\n";
         print "Content-type: text/html\n\n<HTML>\n";
         print "<head><title>URN Resolution: I2Ns</title></head>\n";
         print "<BODY>\n";
         print "<h1>URN $urn resolves to the following URNs:</h1>\n";
         print "<hr><ul>\n";
             foreach $i (@ref) {
                 print "<li>$i: Click to resolve using\n";
                 print "<a href=\"http://$host:$port/uri-res/I2C?$i\">I2C</a>,\n";
                 print "<a href=\"http://$host:$port/uri-res/I2L?$i\">I2L</a>,\n";
                 print "<a href=\"http://$host:$port/uri-res/I2Ls?$i\">I2Ls</a>,\n";
                 print "<a href=\"http://$host:$port/uri-res/I2R?$i\">I2R</a>,\n";
                 print "<a href=\"http://$host:$port/uri-res/I2Rs?$i\">I2Rs</a>\n";
             }
         print "</UL>\n</body>\n</HTML>\n";
       }
     }
     }

     sub make_link {
       my($sc);
       my($inarg)=@_;
       ($sc=$1) if ($inarg =~ /([a-z]*)/);
       return "/$sc/$inarg.ps" if (-e "/ftp/$sc/$inarg.ps");
       return "/$sc/$inarg.html" if (-e "/ftp/$sc/$inarg.html");
       return "/$sc/$inarg.txt";
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "HTTP/1.0 $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2Ns $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URC resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     };

A.5 I2R

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 resource resolver for the ietf namespace
     #

Expires 11/30/98                                               [Page 16]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

     my(%pathbase) = (
       rfc => "rfc/rfc",
       fyi => "fyi/fyi",
       std => "std/std",
       bcp => "bcp/bcp"
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {
       my($ietfnum, $sesnam) = @_;
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/plain\n\n";
           open(FILE, "$link");
           while (<FILE>) {
               print $_;
           }
           close FILE;
         return;
       }
       my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
           print "HTTP/1.0 200 OK\n";
           print "Content-type: text/plain\n\n";
           open(FILE, "$link");
           while (<FILE>) {
               print $_;
           }
           close FILE;
         return;
       }
       &urn_error("404 Not Found\n");

Expires 11/30/98                                               [Page 17]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

     }

     sub end {
       my($inarg)=@_;
       return $inarg . "st" if ($inarg =~ /1$/);
       return $inarg . "nd" if ($inarg =~ /2$/);
       return $inarg . "rd" if ($inarg =~ /3$/);
       return $inarg . "th";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       &urn_error("404 Not Found\n")if (!defined $pathbase{$scheme});
       my($txttry)="/ftp/$pathbase{$scheme}$value.txt";
       my($pstry)="/ftp/$pathbase{$scheme}$value.ps";
       my($htmltry)="/ftp/$pathbase{$scheme}$value.html";
     MIME_SWITCH: {
         if ($accept =~ /application\/postscript/ && -f $pstry) {
           print "HTTP/1.0 200 OK\n";
           print "Content-type: application/postscript\n\n";
           open(FILE, "$pstry");
           while (<FILE>) {
               print $_;
           }
           close FILE;
           last MIME_SWITCH;
         }
         if ($accept =~ /text\/html/ && -f $htmltry) {
             print "HTTP/1.0 200 OK\n";
             print "Content-type: text/html\n\n";
             open(FILE, "$htmltry");
             while (<FILE>) {
                 print $_;
             }
             close FILE;
             last MIME_SWITCH;
         }
         if ($accept =~ /\*\/\*|text\/plain/ && -f $txttry) {
             print "HTTP/1.0 200 OK\n";
             print "Content-type: text/plain\n\n";
             open(FILE, "$txttry");
             while (<FILE>) {
                 print $_;
             }
             close FILE;
             last MIME_SWITCH;
         }
         &urn_error("404 Not Found\n");
       }
     }

Expires 11/30/98                                               [Page 18]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "HTTP/1.0 $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2R $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URL resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     }

A.6 I2Rs

     #!/usr/local/bin/perl

     use strict;

     #
     # this is a URN 2 resources resolver for the ietf namespace
     #

     my(@urls);

     my(%pathbase) = (
       rfc => "rfc/rfc",
       fyi => "fyi/fyi",
       std => "std/std",
       bcp => "bcp/bcp"
     );

     my(%number2date) = (
       41 => "98apr",
       40 => "97dec", 39 => "97aug", 38 => "97apr",
       37 => "96dec", 36 => "96jun", 35 => "96mar",
       34 => "95dec", 33 => "95jul", 32 => "95apr",
       31 => "94dec", 30 => "94jul", 29 => "94mar",
       28 => "93nov", 27 => "93jul", 26 => "93mar",
       25 => "92nov", 24 => "92jul", 23 => "92mar",
       22 => "91nov", 21 => "91jul", 20 => "91mar",
       19 => "90dec" );

     my($wgpath) = "/ftp/ietf";
     my($urn) = $ENV{'QUERY_STRING'};
     my($host) = $ENV{'SERVER_NAME'}; #get my host name for ftp: URLs
     my($accept) = $ENV{'HTTP_ACCEPT'}; #this is the "Accept:" HTTP header

     (&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(\w*):(\d*)/i);
     (&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(\d*)-(\w*)/i);
     &urn_error("400 Bad Request\n");

     sub resolve2 {

Expires 11/30/98                                               [Page 19]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       my($ietfnum, $sesnam) = @_;
       my(@vers,$i);
       &urn_error("404 Not Found\n") if (!defined $number2date{$ietfnum});
       my($date)=$number2date{$ietfnum};
       my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
       if (-f $link) {
           push(@vers,$link);
       }
       $link="$wgpath/$date/$sesnam-minutes-$date.txt";
       if (-f $link) {
           push(@vers,$link);
       }
       &urn_error("404 Not Found\n") if ($#vers==-1);

       print "HTTP/1.0 200 OK\n";
       print "Content-type: multipart/alternative; boundary=endpart\n\n";
       foreach $i (@vers) {
           print "--endpart\n";
           if ($i =~ /html$/) {
               print "Content-Type: text/html\n\n";
           }
           if ($i =~ /txt$/) {
               print "Content-Type: text/plain\n\n";
           }
           if ($i =~ /ps$/) {
               print "Content-Type: application/postscript\n\n";
           }
           open(FILE, "$i");
           while (<FILE>) {
               print "$_";
           }
           close FILE;
       }
       print "--endpart\n";
     }

     sub resolve1 {
       my($flag,@bib,$i,$k,$j,$done,@ref);
       my($l,$link,@vers);
       my($scheme, $value) = @_;
       $scheme =~ tr/A-Z/a-z/;
       &urn_error("404 Not Found\n")if (!defined $pathbase{$scheme});
       my($try)="/ftp/$pathbase{$scheme}$value.txt";
       if (-f $try) {
           push(@vers, $try);
       }
       $try="/ftp/$pathbase{$scheme}$value.ps";
       if (-f $try) {
           push(@vers, $try);
       }
       $try="/ftp/$pathbase{$scheme}$value.html";
       if (-f $try) {
           push(@vers, $try);
       }

Expires 11/30/98                                               [Page 20]

INTERNET DRAFT     A URN Namespace for IETF Documents           May 1998

       print "HTTP/1.0 200 OK\n";
       print "Content-type: multipart/alternative; boundary=endpart\n\n";
       foreach $i (@vers) {
           print "--endpart\n";
           if ($i =~ /html$/) {
               print "Content-Type: text/html\n\n";
           }
           if ($i =~ /txt$/) {
               print "Content-Type: text/plain\n\n";
           }
           if ($i =~ /ps$/) {
               print "Content-Type: application/postscript\n\n";
           }
           open(FILE, "$i");
           while (<FILE>) {
               print "$_";
           }
           close FILE;
       }
       print "--endpart\n";
     }

     sub urn_error {
       my($code) = @_; #store failure code here...

       print "HTTP/1.0 $code";
       print "Content-type: text/html\n\n<HTML>\n";
       print "<head><title>URN Resolution: I2Rs $code</title></head>\n";
       print "<BODY>\n";
       print "<h1>URN to URL resolution failed for the URN:</h1>\n";
       print "<hr><h3>$urn</h3>\n";
       print "</body>\n";
       print "</html>\n";
       exit;
     }

Expires 11/30/98                                               [Page 21]