Subject: [URN] No meeting -- definitive
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Date: Mon, 30 Mar 1998 13:51:41 -0500 (EST)

Hello all,

The URN meeting at the Los Angeles IETF has officially been cancelled.
We didn't have any agenda items focused on moving us forward on our
milestones, and meeting space is at a premium for the whole IETF. 

This is not to say that there is nothing happening with URNs; I will
undertake to provide an update report after this week.

Michael Mealling has a demo of an InternetExplorer URN add-on;
he's keen to demonstrate it this week to anyone who's interested
in seeing it.

Leslie.

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

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

Date: Sun, 29 Mar 1998 01:54:00 -0500
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] New drafts concerning identifier resolution in HTTP
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

   Having had a chance to read over these drafts, I've got a few comments,
   some more general than others.

   Firstly, I think this is an interesting proposal for URI resolution
   that is better-integrated with HTTP than tHTTP -- I wish you godspeed
   in getting this incorporated into the HTTP protocol spec :-> 

   Secondly, I think it would benefit this group to discuss this proposal
   in more detail -- it clearly does solve some of the problems of tHTTP
   and NAPTR, but I think it, too, has specific realms of applicability 
   (there's no such thing as a perfect RDS/resolution server?).

Thanks for the comments and typos..  I agree that there is still a lot
of work here, bugs, areas where clarity is lacking..!  More discussion
would be a very good thing..

I haven't had time to address in the document the major issues brought
up here, but in this message I will try to clarify the major issues.

	- Lewis

   So, some specfic comments of my own:

   [..]

   Paragraph 2 talks about resolving by asking the "right server" to
   resolve a URI.  What defines the "right server"?  This touches on
   a key point that needs clarification, I think, which is the resolution
   hint information update model.  There is a paragraph at the end of
   section 1.2 talking about using "signed RDF" to ensure the authenticity
   of  information, but I don't think that adequately addresses the fact
   that your model of resolution starts _somewhere_ (e.g., a local proxy
   server) and works out from there on a "buddy" system -- authenticity
   is locally-relative.  This is useful in providing cached and proxy'ed
   information, but I have concerns that it doesn't guarantee that you get
   to the information that the _publisher_ of the URN wants you to believe
   is authoritative.  In the NAPTR model, there is a chain of delegation
   of record control, however poorly secured that is.

This is a very interesting and difficult problem...  and it is not
currently covered very well in this document.  However I think that
the idea of relying on an end-to-end verification mechanism after the
resolution takes place is a fairly sound one, because it makes it
easier for proxies to operate and generally reduces the overhead of
providing these security features.  It also makes verification
optional; the client can ask for the verifier or not.

The key to securing a name resolution is in verifying that the name
really was delegated to the "terminal" resolver.  As you point out,
this requires a record of a chain of delegations, each authenticating
the key of the delegatee.  Such a proof hinges entirely on having the
right root key for the official root namespace owner, and requires
verifying the signatures on every delegation from the root to the
terminal resolver.  (I believe this is in essence the architecture
used by DNSSEC.)

There are two problems with passing this information around during the
resolution process.  One is that there may be several protocols in
operation, and they each would need to add this kind of functionality
in order to make it work -- the proof is no good if it's missing a
link.  Another is that this stuff is really complicated and hard to
think about, and easy to implement wrong.  In many cases it is
sensitive to the slightest wrong bit as well.  Another is that if the
client doesn't care about security there will need to be a standard
way to propagate that information through the resolution process.

So the intent with WIRE is to rely on the publisher to construct a
proof that convinces the client that the resource that arrived really
is named by the right URN.  In order to implement this, we would like
to have some kind of standard format for describing and signing a
delegation, integrated with the appropriate parts of the internet
security infrastructure.  The publisher then collects up a set of
linked delegation verifiers, and the client can check them using a
well-known root public key.  A minimal format would include the URN
and the public key data for the next resolver.  So a chain might be

	{URN,PK1}+Signature{rootKey}
	{URN,PK2}+Signature{PK1}
	{URN,PK3}+Signature{PK2}
	{URN,SHA of resource}+Signature{PK3}

Of course, any upstream resolver can spoof a URN, but this is always a
problem if you begin with the assumption that you don't know who is
supposed to own the resource.  Assuming that the resource is the
object of the resolution process, if the client already knows the
correct owner of the resource, the final segment suffices.

The obvious problem with this is that every URN secured this way needs
to be signed by the root key.  Clearly some mechanism for making a
single verifier work for whole spaces is needed.  At the same time we
would like the resolution mechanism to have a high degree of
flexibility, which makes describing the spaces difficult.  One
approach would be to define an incomplete set of space-description
schemes, and require the clients to understand them in order to verify
the proof.  A browser could easily have a plug-in interface to extend
this set of schemes.  One simple one is wildcards (like '*').  This
would suffice for the needs of the root registry, for example.  A
scheme based on a regular expression plus a target string would
suffice for NAPTR; execute the regex and verify that it matches the
target.

Does this idea sound useful/feasible?

There is a lot here to be worked out.. but it seemed like something
like this was the only feasible way to implement security for a
mechanism that allowed proxies.  Note that the key here is having some
way to pass the information back to the client.  If a standard format
existed it could easily be passed back to or generated by the client
along the way, and verified after the resolution is complete.

   URN Resolution Using WIRE

   As you've already said yourself, this document needs to refer more
   directly to the URI services document.  This may suggest adjustments
   to the services document, but this one should definitely address which
   services are being made available (explicitly or implicitly), and how
   the different error conditions/result types are handled.  

The document needs to do a better job of giving examples of how the
mechanisms can be used to provide these services.  These examples
should make it clear that the things people want to do are supported
fairly comfortably.  I tend to look at resolution services more like a
typing model, i.e. a meta-resource is being served that supports these
"services" as methods.  These method calls are intended to be conveyed
to a WIRE resolver as '?' arguments.  I like this approach because it
generalizes nicely and avoids the question of whether the resource on
the other end is the picture or a list of URLs of the picture -- in
this model it is an object with two methods: "give me URLs" and "give
me a picture".  I was hoping that we could use a space of URNs to
register new type identifiers.  

However in general this effort got sidetracked away from resolution
services (which was what it started out to do) into other areas so
not as much work has been done in that area.. any ideas?

   Along the lines of the question about the hint update model above, there
   should be an elaboration of how a namespace/part of a namespace gets
   itself registered within the WIRE system -- e.g., is there a top-level
   authoritative WIRE resolver?   Is it NAPTR?  I.e., come at this from
   the perspective of a book publisher that wants to know what to do
   to get its URNs resolved (properly) using WIRE -- what does that publisher
   need to know/do?

This question has been raised by other readers so it certainly needs
clarification on this point.  The document was written from the
perspective that NAPTR is used as a top-level service, and WIRE is one
possible protocol to indicate with the "p" flag.  It would not be
feasible to mirror the data served through NAPTR; furthermore, while
WIRE can be used to proxy NAPTR lookups there is a subtle reason why
WIRE cannot be used as a gateway to NAPTR in a non-proxy sense.
Briefly, the reason is that NAPTR requires the client to try
alternatives in the event of failure to resolve, and this feature is
provided with the intention of providing default or "fallback"
options.  Although a WIRE client is free to try alternatives in this
way, it is not required (the client is free to give up), so this
cannot be used as a technique to specify fallback options.

This means that if we want a _correct_ implementation, we can't set up
a WIRE resovler that performs the first NAPTR lookup and returns a 350
pointing to a different resolver.

However, this was not the intent -- the setup we envisioned was 
that WIRE be used as a gateway protocol to support emerging protocols, 
but that clients and proxy servers that use WIRE would all know
NAPTR as a "native" protocol.  

Thus, if a client uses a proxy, WIRE might be used to interface to
that proxy.  That proxy would use NAPTR as the top-level mechanism.  A
NAPTR record might tell the proxy to contact a WIRE server somewhere,
etc. and the WIRE client algorithm is used.  At some further point a
350 response might pop the proxy back into NAPTR.  Or it might pop the
proxy into THTTP, or into some other as yet undetermined protocol.
The main idea is that for those undetermined protocols WIRE can be
used as a fallback option in the case that the proxy doesn't know
them.

If the client does not use a proxy, then the client starts with NAPTR
and the situtation is the same as above.

   Section 1.4:  As I understand it, you want to remove the distinction between
   the discovery of a resolver, and resolver software itself.  While I think
   that may be a fine thing within your architecture, I disagree that this
   is "clearer".  Functionally, the steps are different, if nothing else than
   in terms of who (publisher, namespace owner, delegatee) gets to update
   which information and provide what services.  There are, in fact, 3
   distinct levels, that I believe are important for discussion of 
   architecture:

	   . (global) NID registration, which permits the discovery of
	   . naming authorities, which permit the discovery of
	   . local resolution servers

   Having said that, I don't disagree that an implementation may find it
   convenient to collapse these into a single system.

Right..  and a WIRE implementation is not really required to collapse
them, although it does have the option to do so.  Basically it becomes
a multidimensional tradeoff between convenience, reliability,
political concerns, and ability to maintain the data in an orderly
fashion.  Whether it makes sense to collapse or stratify these
functions, either case can be implemented within this framework.  For
example, one could use WIRE only as a terminal resolver; such a server
would never return a 350 code.  This case should have equivalent
functionality to THTTP.

As for clarity of the model, I don't know.  I thought that previous
ways I had looked at it were much more complicated, and this one is at
least simpler...

   Section 3.4, last text paragraph:  "To switching back to NAPTR," -- should
     that be "To switch back to WIRE,"?

The grammar is incorrect, but it intended to give an example of how a
350 response can redirect a client to continue the resolution using
NAPTR.

NOTE: The latest versions of these documents are maintained on the web
site.  Minor updates are indicated by alphabetic extensions to the
version number (i.e. 00 is now 00b).

http://phobos.lcs.mit.edu/wire.html
http://phobos.lcs.mit.edu/urn-wire.html

- Lewis

Date: Sun, 29 Mar 1998 00:01:52 -0500
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: About the NID document [Was Re: [URN] no meeting?]
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

                                          Part of the intention of the informal 
   namespaces was to make it fairly easy to get a perfectly-functional namespace 
   (e.g., for specific purposes, such as within particular applications), thereby
   reducing the load of proposals for formal namespaces with a requested
   NID.

I see where I was confused now.. my concern was to avoid bloat in the
NID registries, but informal NIDs are not necessarily included in NID
services?  

Perhaps a little more text might clarify this.  Although specifying a
policy for managing (for example) the urn.net registry is outside the
scope of this document, an example of such a policy might help clarify
the intentions behind the differences in level of service.

Would such an example policy be:

Exp'tal:  ???  not guaranteed to be unique... ignored?

Informal: annual registration fee paid to registry

Formal:   one-time registration fee and fee for changes to registration 
          information;  In addition, for each formal NID registered, 
          annual fees are waived for one additional informal registation, 
          to support backwards compatibility
          
A few more questions:

 . what is the advantage of experimental vs. informal, if there is no 
   guarantee of uniqueness in the experimental space and registration
   in informal is unrestricted?

 . what is the advantage of formal vs. informal?

 . (or is the answer to both of the above "vanity"?)

 . is there an expectation that a well-behaved NID service (e.g. urn.net)
   provides information on the complete set of formal NIDs?

- Lewis

Date: Thu, 26 Mar 1998 22:09:07 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Lewis Girod <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] New drafts concerning identifier resolution in HTTP
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Sat, 14 Mar 1998, Lewis Girod wrote:
> 
> With the help of some of the people in the W3C, John and I and some
> students here have put together two drafts describing an extension to
> HTTP.  While the specification has a way to go in terms of addressing
> all the issues raised at the last meeting, I see a number of positive

Having had a chance to read over these drafts, I've got a few comments,
some more general than others.

Firstly, I think this is an interesting proposal for URI resolution
that is better-integrated with HTTP than tHTTP -- I wish you godspeed
in getting this incorporated into the HTTP protocol spec :-> 

Secondly, I think it would benefit this group to discuss this proposal
in more detail -- it clearly does solve some of the problems of tHTTP
and NAPTR, but I think it, too, has specific realms of applicability 
(there's no such thing as a perfect RDS/resolution server?).

So, some specfic comments of my own:

WIRE - W3 Identifier Resolution Extensions

The first paragraph of section 1.2 is kind of empty -- "... In this
section we present a new, clearer resolution model."  Clearer than what?
<evil grin>

Paragraph 2 talks about resolving by asking the "right server" to
resolve a URI.  What defines the "right server"?  This touches on
a key point that needs clarification, I think, which is the resolution
hint information update model.  There is a paragraph at the end of
section 1.2 talking about using "signed RDF" to ensure the authenticity
of  information, but I don't think that adequately addresses the fact
that your model of resolution starts _somewhere_ (e.g., a local proxy
server) and works out from there on a "buddy" system -- authenticity
is locally-relative.  This is useful in providing cached and proxy'ed
information, but I have concerns that it doesn't guarantee that you get
to the information that the _publisher_ of the URN wants you to believe
is authoritative.  In the NAPTR model, there is a chain of delegation
of record control, however poorly secured that is.

Section 1.4, last line:  "non-terminals" should be "non-terminal"

Section 2.3:  the grammar (at least in the copy from your web page; haven't
  seen the one that hit the repository) has some peculiarities of
  " and \ -- maybe I'm just tired, but

	quote-relative-uri = "\"" relative-uri "=""

  seems unbalanced to me.

Section 5, first paragraph:  "more than one delegations" should be
   "more than one delegation"

URN Resolution Using WIRE

As you've already said yourself, this document needs to refer more
directly to the URI services document.  This may suggest adjustments
to the services document, but this one should definitely address which
services are being made available (explicitly or implicitly), and how
the different error conditions/result types are handled.  

Also, as long as you're referring to HTTP error codes, it would also be 
useful to have a table (appendix?) of the ones mentioned.

Along the lines of the question about the hint update model above, there
should be an elaboration of how a namespace/part of a namespace gets
itself registered within the WIRE system -- e.g., is there a top-level
authoritative WIRE resolver?   Is it NAPTR?  I.e., come at this from
the perspective of a book publisher that wants to know what to do
to get its URNs resolved (properly) using WIRE -- what does that publisher
need to know/do?

Section 1.3.1, paragraph 2:  refers to "resolution services" in 
  reference "[10]" -- is that perhaps actually "[12]"?

Section 1.4:  As I understand it, you want to remove the distinction between
the discovery of a resolver, and resolver software itself.  While I think
that may be a fine thing within your architecture, I disagree that this
is "clearer".  Functionally, the steps are different, if nothing else than
in terms of who (publisher, namespace owner, delegatee) gets to update
which information and provide what services.  There are, in fact, 3
distinct levels, that I believe are important for discussion of 
architecture:

	. (global) NID registration, which permits the discovery of
	. naming authorities, which permit the discovery of
	. local resolution servers

Having said that, I don't disagree that an implementation may find it
convenient to collapse these into a single system.

Section 3.4, last text paragraph:  "To switching back to NAPTR," -- should
  that be "To switch back to WIRE,"?

Leslie.

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

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

Date: Thu, 26 Mar 1998 21:42:39 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: Lewis Girod <[email-masked]>
cc: [email-masked]
Subject: About the NID document [Was Re: [URN] no meeting?]
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hi Lewis,

On Tue, 24 Mar 1998, Lewis Girod wrote:
> One question that came to mind when I read the namespace draft was
> whether the three delineations in section 4.0 are really necessary.
> It seemed to me that the cases covered by types I and II can just
> as easily be implemented within a sufficently open namespace, such as 
> the INET namespace given in the example in section 5.

As I understand it, you're proposing that the whole notion of informal
namespacse could be handled as "partitions" of some suitably-openminded
namespace.

The concerns I have with that are:

	. as it stands, it's the namespace that gets registered in
	  a (some) top-level registry(ies) for an RDS.  So, these
	  informal namespaces would have to be seen as partitions of
	  a namespace which has itself registered in the places
	  of interest to the informal namespace owner (e.g., in NAPTR)

	. depending on the RDS in question, this may or may not leave
	  the informal namespace owner with suitable control over
	  how their namespace partition is managed

Beyond the assumption of multiple RDSs, the informal namespace is immediately 
subjected to the control (or lack thereof) of the governing namespace; the 
informal one can never be any _better_ than that.

This might work for short-term fixes as a namespace was being put
through the more formal process and getting a requested NID, but I don't think
it would work for long-term things.  Part of the intention of the informal 
namespaces was to make it fairly easy to get a perfectly-functional namespace 
(e.g., for specific purposes, such as within particular applications), thereby
reducing the load of proposals for formal namespaces with a requested
NID.

So, implementationally they might collapse, but I would argue that
pragmatically, they don't.

Leslie.

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

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

Date: Tue, 24 Mar 1998 20:25:34 -0500
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] no meeting?
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

Hi,

One question that came to mind when I read the namespace draft was
whether the three delineations in section 4.0 are really necessary.
It seemed to me that the cases covered by types I and II can just
as easily be implemented within a sufficently open namespace, such as 
the INET namespace given in the example in section 5.

Something like INET allows anyone with a DNS server to make their
namespace visible to the world by just adding the appropriate NAPTR
record.  Presumably there are no guarantees implied about the
persistence of urn:inet:*.  However, an organization can use INET to
begin the "formal" process, by demonstrating an operating resolution
mechanism that resolves their namespace prefixed by
urn:inet:my.domain.com:.

Once the bugs are worked out, and they go through the formal RFC
process, a permanent NID (and mapping in urn.net) can be established.
They would still need to support the "pre-nid" names via the old
mechanism, which is hopefully fairly easy to do.  Of course, any other
"temporary" approach (i.e. the "informal" or "experimental"
registrations) would have the same requirement, assuming that a
permanent NID is eventually assigned.  This was why I was wondering
if there was other reasoning behind the "informal/experimental"
registrations.

	- Lewis

From: "Ryan Moats" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "LDAP Service Deployment Working Group" <[email-masked]>, "URN mailing list" <[email-masked]>
Date: Tue, 24 Mar 98 10:15:15 -0600
Priority: Normal
Subject: [URN] Fwd: Draft WASRV BOF announcement
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

My apologies if you receive this announcement more than once.
This BOF in LA might be of interest to folks on these lists.  It is
currently scheduled for 1530-1730 Thursday in the Avalon room
(but check your schedules when you arrive for changes :-)

  There has been recent interest in mechanisms for discovery of services 
  across the global internet. Such interest has manifested itself in 
  numerous papers, standards proposals, and commercial tools. However, 
  what is meant by wide area service location seems to vary in all cases.
  The organizers of the WASRV BOF will advocate a set of architectural
  principals for a successful wide area service location system.  

  In brief, discovery should not require a priori knowledge or configuration
  to perform, should be based on attribute based search criteria and 
  allow rapid, scalable access to service information.  Services should
  be discoverable only when they are actually available and ideally 
  advertise themselves automatically.

  These principals will be discussed and proposals for solutions to 
  the wide area service location problem will be presented.  The goal
  of the BOF is to determine whether there is sufficient interest in 
  the problem, as we agree to define it, and whether the technical 
  proposals presented will arrive at a feasible technical solution.

  Please see http://www.bell-labs.com/mailing-lists/wasrv/ for a list
  of documents including "WASRV Architectural Principles" which describe
  in detail the issues believe a chartered WASRV WG in the Internet area 
  should address.

Date: Tue, 24 Mar 1998 07:35:44 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: re no meeting [URN]
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

I won't be there, but I like the latest draft and I'm happy to
agree that we're all but done.

Regards,

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

Date: Tue, 24 Mar 1998 09:50:09 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: [URN] no meeting?
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hey!  I will allow the resounding silence surrounding my call for agenda items
to suggest that people are quite happy with the status quo of the
documents, and there is in fact nothing to discuss in LA.

Previous experience suggests that, if we get together for a meeting, we
will in fact find plenty of material to disagree about, and impede our
own forward progress.

So, if no one can suggest concrete agenda items, per my message of last
Thursday (attached), I'll tell the IESG that we're all-but-done and
that we're relinquishing the meeting slot that I mistakenly reserved
for us.

Thanks,
Leslie.

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

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

[Leslie's message of Thu, Mar 19, 1998]

Hello all,

I'd like to put together the agenda for our meeting in LA.  There are
some points which previous experience suggests might be fruitful in
terms of generation of discussion, but I'd like to flush out issues 
_now_ so that we can have an organized meeting session.

I don't want to stifle discussion or suppress creativity, but I remarked
during the Washington meeting that the discussion would have been
more useful if we'd had time to talk about/think about the points 
beforehand.  After all, if the issues are THAT important to people, 
I'm confident you can invest 5 minutes in writing them down and sharing
them now!

What I'd like to ask you is to send any issues you currently perceive
as needing discussion to the mailing list before Thursday of next week.
Hopefully, this will give us a "leg up" on discussion before the meeting.
I will circulate a draft agenda at (or about) 5pm EST on Thursday,
March 26.

If issues don't make it onto that agenda, I reserve the right to be
ruthless about cutting off discussion of them during the meeting.

To help people get into gear for this, here's a little of what
I think might generate discussion points:

As the documents stand now, this group is essentially done with the
bulk of its work.  The proposal for the outstanding issue of contention
is (from draft-ietf-urn-nid-req-02.txt):

	. x- is reserved for "experimental" NIDs
	. there is a straightforward, mechanical method whereby anyone
	  can get a NID assigned (where the NID will be some sequence of
	  numbers)
	. there is a slightly more formal, yet mechanical, method
	  for achieving assignment of requested NID strings.

Once we finish with the final details of this draft (e.g., where to
submit the required detail), we can thus expect to see URNs "go live",
and urns such as:

	urn:x-myspace:who-needs-hierarchy-anyway
	urn:0123486999:somepublisher-cooking.chocolate.12340-666
	urn:catspace:dinner.mouse.munch.munch.munch
	urn:pdi://oma.eop.gov/1997/09/01.text.2

appearing shortly thereafter.

I think this is a workable proposal; unless there is further discussion
that yields a better, suitable, implementable proposal, this is how
things will go forward.

So, discussion item, anyone?

Thanks,
Leslie.

Date: Tue, 24 Mar 1998 09:50:09 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: [URN] no meeting?
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>
Status: R

Hey!  I will allow the resounding silence surrounding my call for agenda items
to suggest that people are quite happy with the status quo of the
documents, and there is in fact nothing to discuss in LA.

Previous experience suggests that, if we get together for a meeting, we
will in fact find plenty of material to disagree about, and impede our
own forward progress.

So, if no one can suggest concrete agenda items, per my message of last
Thursday (attached), I'll tell the IESG that we're all-but-done and
that we're relinquishing the meeting slot that I mistakenly reserved
for us.

Thanks,
Leslie.

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

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

[Leslie's message of Thu, Mar 19, 1998]

Hello all,

I'd like to put together the agenda for our meeting in LA.  There are
some points which previous experience suggests might be fruitful in
terms of generation of discussion, but I'd like to flush out issues 
_now_ so that we can have an organized meeting session.

I don't want to stifle discussion or suppress creativity, but I remarked
during the Washington meeting that the discussion would have been
more useful if we'd had time to talk about/think about the points 
beforehand.  After all, if the issues are THAT important to people, 
I'm confident you can invest 5 minutes in writing them down and sharing
them now!

What I'd like to ask you is to send any issues you currently perceive
as needing discussion to the mailing list before Thursday of next week.
Hopefully, this will give us a "leg up" on discussion before the meeting.
I will circulate a draft agenda at (or about) 5pm EST on Thursday,
March 26.

If issues don't make it onto that agenda, I reserve the right to be
ruthless about cutting off discussion of them during the meeting.

To help people get into gear for this, here's a little of what
I think might generate discussion points:

As the documents stand now, this group is essentially done with the
bulk of its work.  The proposal for the outstanding issue of contention
is (from draft-ietf-urn-nid-req-02.txt):

	. x- is reserved for "experimental" NIDs
	. there is a straightforward, mechanical method whereby anyone
	  can get a NID assigned (where the NID will be some sequence of
	  numbers)
	. there is a slightly more formal, yet mechanical, method
	  for achieving assignment of requested NID strings.

Once we finish with the final details of this draft (e.g., where to
submit the required detail), we can thus expect to see URNs "go live",
and urns such as:

	urn:x-myspace:who-needs-hierarchy-anyway
	urn:0123486999:somepublisher-cooking.chocolate.12340-666
	urn:catspace:dinner.mouse.munch.munch.munch
	urn:pdi://oma.eop.gov/1997/09/01.text.2

appearing shortly thereafter.

I think this is a workable proposal; unless there is further discussion
that yields a better, suitable, implementable proposal, this is how
things will go forward.

So, discussion item, anyone?

Thanks,
Leslie.

Date: Thu, 19 Mar 1998 10:33:50 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: [URN] Agenda Planning
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Hello all,

I'd like to put together the agenda for our meeting in LA.  There are
some points which previous experience suggests might be fruitful in
terms of generation of discussion, but I'd like to flush out issues 
_now_ so that we can have an organized meeting session.

I don't want to stifle discussion or suppress creativity, but I remarked
during the Washington meeting that the discussion would have been
more useful if we'd had time to talk about/think about the points 
beforehand.  After all, if the issues are THAT important to people, 
I'm confident you can invest 5 minutes in writing them down and sharing
them now!

What I'd like to ask you is to send any issues you currently perceive
as needing discussion to the mailing list before Thursday of next week.
Hopefully, this will give us a "leg up" on discussion before the meeting.
I will circulate a draft agenda at (or about) 5pm EST on Thursday,
March 26.

If issues don't make it onto that agenda, I reserve the right to be
ruthless about cutting off discussion of them during the meeting.

To help people get into gear for this, here's a little of what
I think might generate discussion points:

As the documents stand now, this group is essentially done with the
bulk of its work.  The proposal for the outstanding issue of contention
is (from draft-ietf-urn-nid-req-02.txt):

	. x- is reserved for "experimental" NIDs
	. there is a straightforward, mechanical method whereby anyone
	  can get a NID assigned (where the NID will be some sequence of
	  numbers)
	. there is a slightly more formal, yet mechanical, method
	  for achieving assignment of requested NID strings.

Once we finish with the final details of this draft (e.g., where to
submit the required detail), we can thus expect to see URNs "go live",
and urns such as:

	urn:x-myspace:who-needs-hierarchy-anyway
	urn:0123486999:somepublisher-cooking.chocolate.12340-666
	urn:catspace:dinner.mouse.munch.munch.munch
	urn:pdi://oma.eop.gov/1997/09/01.text.2

appearing shortly thereafter.

I think this is a workable proposal; unless there is further discussion
that yields a better, suitable, implementable proposal, this is how
things will go forward.

So, discussion item, anyone?

Thanks,
Leslie.

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

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-resolution-services-06.txt
Date: Mon, 16 Mar 1998 08:21:30 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

	Title		: URI Resolution Services Necessary for URN Resolution
	Author(s)	: M. Mealling, R. Daniel
	Filename	: draft-ietf-urn-resolution-services-06.txt
	Pages		: 11
	Date		: 13-Mar-98
	
Retrieving the resource identified by a Uniform Resource Identifier
(URI) [1] is only one of the operations that can be performed on a URI.
One might also ask for and get a list of other identifiers that are
aliases for the original URI or a bibliographic description of the
resource the URI denotes, for example. This applies to both Uniform
Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform
Resource Characteristics (URCs) are discussed in this document but only
as descriptions of resources rather than identifiers.
 
A service in the network providing access to a resource may provide
one or some of these options, but it need not provide all of them. This
memo specifies an initial set of these operations that can be used to
describe the interactions provided by a given access service. It also
suggests guidelines that should be adhered to when those operations
are encoded in a protocol.

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-resolution-services-06.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-resolution-services-06.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

--OtherAccess--

--NextPart--

Date: Sat, 14 Mar 1998 21:53:27 -0500
From: Lewis Girod <[email-masked]>
To: [email-masked]
Subject: [URN] New drafts concerning identifier resolution in HTTP
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

Hi Folks,

If you recall from the December meeting, John Mallery enumerated some
deficiencies in the THTTP convention for URN resolution.  THTTP is
nice because it is easy to add URN resolution to an existing server
using only the CGI interface.  Some of the issues raised at the
meeting included a need for clarification in the mapping from error
cases to response codes and for clarification about the behavior of a
resolver in response to other methods such as HEAD and PUT.  (see
http://kbcw.ai.mit.edu/talks/1997-12-11-ietf-urn-pdi/sld012.htm )
One approach that seemed plausible was to try to specify an extension
to HTTP intended to support URN resolution.

With the help of some of the people in the W3C, John and I and some
students here have put together two drafts describing an extension to
HTTP.  While the specification has a way to go in terms of addressing
all the issues raised at the last meeting, I see a number of positive
aspects:

* In my opinion, the model of resolution underlying the mechanism is 
  pretty solid

* The extensions to HTTP are minimal: 1 new redirection code and
  1 new header, which can be fit into the new "Optional" header
  (see http://www.w3.org/Protocols/HTTP/ietf-http-ext/).

* The extension generalizes to URIs but includes the mechanisms 
  necessary for URN resolution: it provides a way to delegate
  authority and doesn't make assumptions about the syntax of the
  identifiers.

The drafts were submitted yesterday just under the wire, so they are
probably stuck in the backlog... in the meantime they can be retrieved
from:

draft-girod-w3-id-res-ext-00.txt
  http://phobos.lcs.mit.edu/wire.html

draft-girod-urn-res-using-wire-00.txt
  http://phobos.lcs.mit.edu/urn-wire.html

The first draft describes the HTTP extensions in general, referring
only to URI resolution.  The second describes a way to leverage the
extensions for URN resolution.

Questions, comments, flames welcome..

--
Lewis Girod
[email-masked]

From: "Ryan Moats" <[email-masked]>
To: "Peter Koch" <[email-masked]>
Cc: "URN mailing list" <[email-masked]>
Date: Sat, 14 Mar 98 13:50:32 -0600
Priority: Normal
Subject: [URN] Re: New "ietf" draft and -04 draft...
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Fri, 13 Mar 1998 18:04:05 +0100, Peter Koch wrote:

>
>> While you are right that it could, I need to check to see if it has a separat
>>e "bcp-index.txt" file
>
>this one is indeed missing from the usual archives. Maybe we can ask the RFC
>Editor.

I looked around, and found the bcp-index file at venera.isi.edu, so I've added
baby processing to the resolver (it should all work, but without a full bcp mirror, I can't
verify it).

I went ahead and added the text Peter and I were discussing.
The ABNF and the appendix now have the code for handling BCP's.

I'll probably wait until after LA to resubmit this, but here it is
on the mailing list for the WG's perusal and comments before/at
LA.

Ryan

==========

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

                   A URN Namespace for IETF Documents
                  Filename: draft-ietf-urn-ietf-04.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 9/30/98                                                 [Page 1]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 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.

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:

Expires 9/30/98                                                 [Page 2]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

          Because the rfc-editor assigns the RFC number uniquely
          these URNs are unique.  Since the mapping between RFCs
          and other rfc-editor docuent 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 dependent
          on the persistence of the underlying documents. The
          fundamental difference between RFCs on one hand and
          STDs, FYIs, or BCPs on the other is that only RFCs are
          real, even persistent, documents while the others are
          just names for sets of one or more RFCs which may
          change over time.

     Process of identifier assignment:

          Assignment of URNs from this namespace occur 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:

Expires 9/30/98                                                 [Page 3]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

          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.

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," Internet Draft (work in progress), January
            1997.

Expires 9/30/98                                                 [Page 4]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

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 => "/ds/home/jayhawk/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

Expires 9/30/98                                                 [Page 5]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     (&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";
         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");

Expires 9/30/98                                                 [Page 6]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       }

       $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) {
             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*//;

Expires 9/30/98                                                 [Page 7]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

         $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]*)/);
       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";

Expires 9/30/98                                                 [Page 8]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       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) = (
       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};

Expires 9/30/98                                                 [Page 9]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       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";
           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;
         }

Expires 9/30/98                                                [Page 10]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

         &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) = (
       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 9/30/98                                                [Page 11]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 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) {
         $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";

Expires 9/30/98                                                [Page 12]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

           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;
       }
       &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);

Expires 9/30/98                                                [Page 13]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     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";
           }
           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: 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.4 I2Ns

     #!/usr/local/bin/perl

     use strict;

     #

Expires 9/30/98                                                [Page 14]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     # 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 => "/ds/home/jayhawk/bcp-index.txt"
     );

     my(%number2date) = (
       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) {
         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";

Expires 9/30/98                                                [Page 15]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

           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";
             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) {

Expires 9/30/98                                                [Page 16]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

           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;
         }
       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://dsm0.ds.internic.net:8080/uri-res/I2C?$i\">I2C</a>,\n";
                 print "<a href=\"http://dsm0.ds.internic.net:8080/uri-res/I2L?$i\">I2L</a>,\n";
                 print "<a href=\"http://dsm0.ds.internic.net:8080/uri-res/I2Ls?$i\">I2Ls</a>,\n";
                 print "<a href=\"http://dsm0.ds.internic.net:8080/uri-res/I2R?$i\">I2R</a>,\n";
                 print "<a href=\"http://dsm0.ds.internic.net:8080/uri-res/I2Rs?$i\">I2Rs</a>\n";
             }
         print "</UL>\n</body>\n</HTML>\n";
       }
     }
     }

     sub make_link {

Expires 9/30/98                                                [Page 17]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       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
     #

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

     my(%number2date) = (
       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 9/30/98                                                [Page 18]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 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 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");
     }

     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 {

Expires 9/30/98                                                [Page 19]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       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");
       }
     }

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

       print "HTTP/1.0 $code";
       print "Content-type: text/html\n\n<HTML>\n";

Expires 9/30/98                                                [Page 20]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       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.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) = (
       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 9/30/98                                                [Page 21]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 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) {

Expires 9/30/98                                                [Page 22]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

           push(@vers, $try);
       }
       $try="/ftp/$pathbase{$scheme}$value.html";
       if (-f $try) {
           push(@vers, $try);
       }
       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: 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;
     }

Expires 9/30/98                                                [Page 23]

Date: Fri, 13 Mar 1998 17:42:35 -0800
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] URN persistence language
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Larry Masinter wrote:

| I suggest perusing the web pages "Achieving integrity of long-persistence data by using replication and continual testing"
| 
| http://ltt-www.lcs.mit.edu/ltt-www/Unpublished/Replication/repl.html
| 
| I think the design of a stable long-persistence storage for data is criterial for having
| persistence in URNs.

I'm perusing the documents before this group.  They talk about persistence
of URNs, not of the information (data) they name.  In one case this seems
to be what is intended, in the other, not.  We need to get them in synch.

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

From: "Larry Masinter" <[email-masked]>
To: "Terry Allen" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] URN persistence language
Date: Fri, 13 Mar 1998 17:35:19 PST
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

I suggest perusing the web pages "Achieving integrity of long-persistence data by using replication and continual testing"

http://ltt-www.lcs.mit.edu/ltt-www/Unpublished/Replication/repl.html

I think the design of a stable long-persistence storage for data is criterial for having
persistence in URNs.

Date: Fri, 13 Mar 1998 08:28:17 -0800
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] URN persistence language
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Kenneth wrote:

| This a reasonable requirement, but just so that people have the
| right perspective: building 100% fail safe systems are very hard.
| I think we can accomplish a fairly reliable system, with some
| discrete checkpoint where we can do some bookkeeping. I think the
| below problem can be solved with a good session manager integrated
| with the workflow service.
| 

Absolutely.  "We have no idea what you're talking about, you'll
have to start over" is an acceptable response, so long as it isn't
the only one the system can give.

| At 06:36 PM 3/12/98 -0800, Terry Allen wrote:
| >Andy wrote:
| >
| >>These functional requirement also seems to over lap the the
| >"choreography / work flow stuff" we talked about. How can I find out
| >what the state of my PO is? (ie waiting for authorization)
| >                                                       
| >Yes, and the very problem you mention is something the OTP folks
| >are worried about wrt restarting a transaction.  Suppose things die,
| >on the other end, and after waiting until my patience runs out I
| >ask "what is the state of foo" and get back an answer like "well,
| >we had a foo around here but thought it was comatose".  I want to
| >be able to say "revive that foo and let's pick up where we left
| >off".
| >
| >
| >
| >Regards, Terry
| >
| --
| Kenneth Persson         Happy Hacker              CNGroup is hiring!
| [email-masked]     CNGroup, Inc.             GUI, Transport, XML
| +1 650 858 7715         4005 Miranda Avenue #150  Server, CORBA, EDI,
| http://www.cngroup.com  Palo Alto, CA 94304       ERP/SAP, Java
| 

Regards,

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

From: "Ryan Moats" <[email-masked]>
To: "Peter Koch" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Fri, 13 Mar 98 09:08:23 -0600
Priority: Normal
Subject: Re: [URN] New "ietf" draft
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Fri, 13 Mar 1998 14:25:20 +0100, Peter Koch wrote:

>
>>           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
>
>the BCP subseries could be added here.

While you are right that it could, I need to check to see if it has a separate "bcp-index.txt" file
for making resolution easier.  If so, it's trivial to add.  If not, it will take me a little bit.  I expect
that I can have an answer (and I new -04 pre release draft) out by the IETF in LA.
I won't submit a new draft to the i-d editor until after LA though.

>>      Identifier uniqueness considerations:
>> 
>>           Because the rfc-editor assigns the RFC, FYI and STD
>>           number uniquely these URNs are unique.  The meeting
>>           minutes portion of the namespace is guaranteed unique
>>           because the URN includes the sequence number of the
>>           IETF conference
>
>The discussion of uniqueness of "std" (and "fyi", this also holds for "bcp")
>identifiers has gone leaving this unclear. The only mails on this topic
>I found in my "urn"-archive were from May last year, so I apologize
>should I have missed something here. Is the following paragraph intended
>to cover this issue?

Good point.  I think I got a little lazy moving from one version to the other.  I'll stick some
text pointing this out in here as part of the -04 pre release draft.

>>     Identifier persistence considerations:
>>
>>          Persistence of the URNs of this namespace is dependent
>>          on the persistence of the underlying documents.
>
>The fundamental difference between "rfc" on one hand and "std", "fyi", and
>"bcp" on the other is that only RFCs are real, even persistent, documents
>while the others are just names for sets of one or more RFCs which may
>change over time. 

If you don't mind, I'll add this text (or a close variant) to this section because I think
it explains things quite nicely.

Ryan

To: "Ryan Moats" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [URN] New "ietf" draft 
Date: Fri, 13 Mar 1998 14:25:20 +0100
From: Peter Koch <[email-masked]>
Sender: [email-masked]
Reply-To: Peter Koch <[email-masked]>

>           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

the BCP subseries could be added here.

>      Identifier uniqueness considerations:
> 
>           Because the rfc-editor assigns the RFC, FYI and STD
>           number uniquely these URNs are unique.  The meeting
>           minutes portion of the namespace is guaranteed unique
>           because the URN includes the sequence number of the
>           IETF conference

The discussion of uniqueness of "std" (and "fyi", this also holds for "bcp")
identifiers has gone leaving this unclear. The only mails on this topic
I found in my "urn"-archive were from May last year, so I apologize
should I have missed something here. Is the following paragraph intended
to cover this issue?

>     Identifier persistence considerations:
>
>          Persistence of the URNs of this namespace is dependent
>          on the persistence of the underlying documents.

The fundamental difference between "rfc" on one hand and "std", "fyi", and
"bcp" on the other is that only RFCs are real, even persistent, documents
while the others are just names for sets of one or more RFCs which may
change over time. 

-Peter

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-nid-req-03.txt
Date: Fri, 13 Mar 1998 08:11:02 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

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

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-urn-nid-req-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-nid-req-03.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-ietf-03.txt
Date: Fri, 13 Mar 1998 08:09:18 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

	Title		: A URN Namespace for IETF Documents
	Author(s)	: R. Moats
	Filename	: draft-ietf-urn-ietf-03.txt
	Pages		: 23
	Date		: 12-Mar-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, and
   FYIs) 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-03.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-ietf-03.txt

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

--OtherAccess--

--NextPart--

From: "Ryan Moats" <[email-masked]>
To: "Internet Drafts Editor" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 12 Mar 98 13:30:53 -0600
Priority: Normal
Subject: [URN] New "ietf" draft
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Here is a new draft to replace draft-ietf-urn-ietf-02.txt in the repository.

Ryan Moats

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

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

                   A URN Namespace for IETF Documents
                  Filename: draft-ietf-urn-ietf-03.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, and
   FYIs) 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. 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 9/30/98                                                 [Page 1]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

1. Introduction

   This document proposes the "ietf" namespace, which consists of the
   RFC family of documents (RFCs, STDs, and FYIs) 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"
          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, FYI and STD
          number uniquely these URNs are unique.  The meeting
          minutes portion of the namespace is guaranteed unique
          because the URN includes the sequence number of the
          IETF conference

Expires 9/30/98                                                 [Page 2]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     Identifier persistence considerations:

          Persistence of the URNs of this namespace is dependent
          on the persistence of the underlying documents.

     Process of identifier assignment:

          Assignment of URNs from this namespace occur in two
          ways.  The first is when a new RFC, FYI or STD 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",
          "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:

          The entire URN is case-insensitive.

     Conformance with URN Syntax:

          There are no additional characters reserved.

     Validation mechanism:

          None specified.

     Scope:

Expires 9/30/98                                                 [Page 3]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

          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," Internet Draft (work in progress), January
            1997.

5. Author's Address

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

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

Appendix A.  Example Resolution Scripts

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

A.1 I2C

Expires 9/30/98                                                 [Page 4]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     #!/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"
     );
     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";
         return;
       }

Expires 9/30/98                                                 [Page 5]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       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>/);

Expires 9/30/98                                                 [Page 6]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

         }
         for ($i=0;$i<=$#bib;$i+=1) {
           $k=$bib[$i];
           while ($k =~ /(fyi|std|rfc)([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";
         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)([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");

Expires 9/30/98                                                 [Page 7]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

             $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]*)/);
       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) = (

Expires 9/30/98                                                 [Page 8]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

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

     my(%number2date) = (
       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 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$/);

Expires 9/30/98                                                 [Page 9]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       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";
           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

Expires 9/30/98                                                [Page 10]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     #!/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"
     );

     my(%number2date) = (
       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 "HTTP/1.0 200 OK\n";
           print "Content-type: text/uri-list\n\n\n";

Expires 9/30/98                                                [Page 11]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

           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";
           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");

Expires 9/30/98                                                [Page 12]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     }

     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";
           }
           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";
           }

Expires 9/30/98                                                [Page 13]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

           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: 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.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"
     );

     my(%number2date) = (
       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'};

Expires 9/30/98                                                [Page 14]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     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";
             return;
         }

Expires 9/30/98                                                [Page 15]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       }
       &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)\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/;
           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) {

Expires 9/30/98                                                [Page 16]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

                 print "$i\n";
             }
             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: 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://dsm0.ds.internic.net:8080/uri-res/I2C?$i\">I2C</a>,\n";
                 print "<a href=\"http://dsm0.ds.internic.net:8080/uri-res/I2L?$i\">I2L</a>,\n";
                 print "<a href=\"http://dsm0.ds.internic.net:8080/uri-res/I2Ls?$i\">I2Ls</a>,\n";
                 print "<a href=\"http://dsm0.ds.internic.net:8080/uri-res/I2R?$i\">I2R</a>,\n";
                 print "<a href=\"http://dsm0.ds.internic.net:8080/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

Expires 9/30/98                                                [Page 17]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     #!/usr/local/bin/perl

     use strict;

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

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

     my(%number2date) = (
       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;
       }

Expires 9/30/98                                                [Page 18]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

       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");
     }

     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 $_;

Expires 9/30/98                                                [Page 19]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

             }
             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");
       }
     }

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

Expires 9/30/98                                                [Page 20]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

     );

     my(%number2date) = (
       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) = @_;
       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";

Expires 9/30/98                                                [Page 21]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 1998

           }
           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);
       }
       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";

Expires 9/30/98                                                [Page 22]

INTERNET DRAFT     A URN Namespace for IETF Documents         March 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: 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;
     }

Expires 9/30/98                                                [Page 23]

From: "Ryan Moats" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 12 Mar 98 13:26:14 -0600
Priority: Normal
Subject: Re: [URN] first next step
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Tue, 10 Mar 1998 22:23:08 -0500 (EST), Leslie Daigle wrote:

>I am attaching a reworking of the draft on Namespace ID's.  This
>draft mostly just incorporates edits from discussion in December --
>the "required information" has been pulled into one section, and the
>"top-level" namespace has been dropped.  I have added some explanatory
>text and an example (sorry, Terry; it's not so short anymore :-)
>

It's still short compared to the new ietf draft that I'm sending to the
list and the i-d editor later today.  I've added the example Perl scripts
for resolution, so it is now 23 pages long.

Ryan

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-resolution-services-05.txt
Date: Thu, 12 Mar 1998 09:48:22 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

	Title		: URI Resolution Services Necessary for URN Resolution
	Author(s)	: M. Mealling, R. Daniel
	Filename	: draft-ietf-urn-resolution-services-05.txt
	Pages		: 11
	Date		: 11-Mar-98
	
Retrieving the resource identified by a Uniform Resource Identifier
(URI) [3] is only one of the operations that can be performed on a URI.
One might also ask for and get a list of other identifiers that are
aliases for the original URI or a bibliographic description of the
resource the URI denotes, for example. This applies to both Uniform
Resource Names (URNs) and Uniform Resource Locators (URLs). Uniform
Resource Characteristics (URCs) are discussed in this document but only
as descriptions of resources rather than identifiers.
 
A service in the network providing access to a resource may provide
one or some of these options, but it need not provide all of them. This
memo specifies an initial set of these functions, to be used to
describe the functions provided by any given access service and the
requirements that must be met when those operations are encoded in a
protocol.

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-resolution-services-05.txt".
A URL for the Internet-Draft is:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-resolution-services-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: ds.internic.net
	
	US West Coast: ftp.isi.edu

Internet-Drafts are also available by mail.

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 10 Mar 1998 22:23:08 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] first next step
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

I am attaching a reworking of the draft on Namespace ID's.  This
draft mostly just incorporates edits from discussion in December --
the "required information" has been pulled into one section, and the
"top-level" namespace has been dropped.  I have added some explanatory
text and an example (sorry, Terry; it's not so short anymore :-)

The one issue that was _not_ resolved by the end of the December IETF meet
was the actual "NID" string.  There were arguments for "just assign
a string and avoid potential legal issues", and there are arguments
for leaving it as outlined in this document (marketability, accessibility,
a carrot for providing more formal information in RFCs etc).

This document is open for comments; it is one of the few remaining
things we need to get done, so let's find the issues that need solving
and find pragmatic work-arounds!

Leslie.

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

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

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

      URN Namespace Definition Mechanisms

Status of this Document

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

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

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

0.0 Abstract

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

0.1 Foreword to this Edition

For the purposes of this document, an "IANA-like" entity is assumed to
exist.  Anywhere the term "IANA" appears, consider it a pointer to
whatever organization or entity exists to handle Internet
registration/assignment tasks.

Still notably absent:

	. where to _send_ and/or _discuss_ the declarations
	  defined here
	. process mechanisms for assigning/obtaining specific NIDs.

These details must wait until there is general resolution re.
Internet assigned numbers.

1.0 Introduction

Uniform Resource Names (URNs) are resource identifiers with the
specific requirements for enabling location independent
identification of a resource, as well as longevity of reference.
There are 2 assumptions that are key to this document:

Assumption #1:

   Assignment of a URN is a managed process.

   I.e., not all strings that conform to URN syntax are necessarily
   valid URNs.  A URN is assigned according to the rules of a 
   particular namespace (in terms of syntax, semantics, and process).

Assumption #2:

   The space of URN namespaces is managed.
   
   I.e., not all syntactically correct URN namespaces (per the URN
   syntax definition)  are valid URN namespaces.  A URN namespace
   must have a recognized definition in order to be valid.

The purpose of this document is to outline a mechanism and provide a
template for explicit namespace definition, along with the mechanism
for associating an identifier (called a "Namespace ID", or NID) which
is registered with the IANA.

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

2.0 What is a URN Namespace?

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

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

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

The development of an identifier structure, and thereby a collection
of identifiers, is a process that is inherently dependent on the needs
of the identifiers, how they will be assigned, and the uses to which
they will be put.  All of these issues are specific to the individual
community seeking to define a namespace (e.g., publishing community,
association of booksellers, protocol developers, etc); they are beyond
the scope of the IETF URN work.

This document outlines the processes by which a collection of
identifiers satisfying certain constraints (uniqueness of assignment,
etc) can become a bona fide URN namespace by obtaining a NID.  In a
nutshell, a template for the definition of the namespace is completed
for deposit with IANA, and a NID is assigned.  The details of the
process and possibilities for NID strings are outlined below; first, a
template for the definition is provided.

3.0 URN Namespace Definition Template

Definition of a URN namespace is accomplished by completing the
following information template.  Apart from providing a mechanism
for disclosing structure of the URN namespace, this information
is designed to be useful for

	. entities seeking to have a URN assigned in a namespace
	  (if applicable)
        . entities seeking to provide URN resolvers for a namespace 
	  (if applicable)

This is particularly important for communities evaluating the
possibility of using a portion of an existing URN namespace rather 
than creating their own.

Information in the template is as follows:

Namespace ID:
	
	Assigned by IANA.  In some contexts, a particular one
	may be requested (see below).

Declared registrant of the namespace:  

	Name and e-mail address.

Declaration of structure:

	This section should outline any structural features of
	identifiers in this namespace.  At the very least, this
	description may be used to introduce terminology used in
	other sections.  This structure may also be used for
	determining realistic caching/shortcuts approaches; suitable 
	caveats should be provided.

	Answers might include, but are not limited to:

	. the structure is opaque (no exposition)
	. a regular expression for parsing the identifier into
	  components, including naming authorities

Identifier uniqueness considerations:
	
	This section should address the requirement that 
	URN identifiers be assigned uniquely -- they are assigned
	to at most one resource, and are not reassigned.

	Possible answers include, but are not limited to:

	. exposition of the structure of the identifiers, and
	  partitioning of the space of identifiers amongst 
	  assignment authorities
	. identifiers are assigned sequentially
	. information is withheld; the namespace is opaque

Identifier persistence considerations:

	Although non-reassignment of URN identifiers ensures
	that a URN will persist in identifying a particular
	resource even after the "lifetime of the resource", 
	some consideration should be given to the persistence
	of the usability of the URN.  This is particularly
	important in the case of URN namespaces providing 
	global resolution.

	Possible answers include, but are not limited to:

	. quality of service considerations

Process of identifier assignment:

	This section should detail the mechanisms and or authorities
	for assigning URNs to resources.  It should make clear whether
	assignment is completely open, or if limited, how
	to become an assigner of identifiers, and/or get one
	assigned by existing assignment authorities.  Answers
	could include, but are not limited to:

	. assignment is completely open, following a particular
	  algorithm
	. assignment is delegated to authorities recognized by
	  a particular organization (e.g., the Digital Object
	  Identifier Foundation controls the DOI assignment space and 
	  its delegation)
	. assignment is completely closed (e.g., for a private
	  organization)

Process for identifier resolution:

	If a namespace is intended to be accessible for global
	resolution, it must be registerd in an RDS (Resolution
	Discovery System, see [RFC2276]) such as NAPTR.  Resolution
	then proceeds according to standard URI resolution processes,
	and the mechanisms of the RDS.  What this section should
	outline is the requirements for becoming a recognized resolver 
	of URNs in this namespace (and being so-listed in the RDS
	registry).

	Answers may include, but are not limited to:

	. the namespace is not listed with an RDS; this is not
	  relevant
	. resolution mirroring is completely open, with a mechanism
	  for updating an appropriate RDS
	. resolution is controlled by entities to which assignment
	  has been delegated

Rules for Lexical Equivalence:

	If there are particular algorithms for determining
	equivalence between two URN strings in this namespace,
	rules can be provided here.  

	Some examples include:
	
	. mappings between different character set encodings
	. equivalence between hyphenated and non-hyphenated
	  groupings in the identifier string

Conformance with URN Syntax:

	This section should outline any special considerations
	required for conforming with the URN syntax.  This is
	particularly applicable in the case of legacy naming
	systems that are used in the context of URNs.

	For example, if a namespace is used in contexts other 
	than URNs, it may have a more generous character set than is 
	immediately available with URNs.  This section should flag this
	issue and outline necessary mappings to conform to 
	URN syntax.  (E.g., see the section on SICIs in [RFC2288]).

Validation mechanism:

	Apart from attempting resolution of a URN, a URN namespace
	may provide mechanism for "validating" a URN -- i.e., 
	determining whether a given string is currently a
	validly-assigned URN.  For example, even if an ISBN
	URN namespace is created, it is not clear that
	all ISBNs will translate directly into "assigned URNs".

	A validation mechanims might be:

	. a syntax grammar
	. an on-line service
	. an off-line service

Scope:
	
	This section should outline the scope of the use of the
	identifiers in this namespace.  Apart from considerations
	of private vs. public namespaces, this section is critical
	in evaluating the applicability of a requested NID.  For
	example, a namespace claiming to deal in "social security
	numbers" should have a global scope and address all 
	social security number structures (unlikely).  On the
	other hand, at a national level, it is reasonable to
	posit a URN namespace for "this nation's social security
	numbers".

4.0 URN Namespace Registration and NID Assignment

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

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

	  I. Experimental: These are not registered with IANA. They
	        take the form

		x<NID>

	 II. Informal:  These are registered with IANA (see Section ??), and
		are assigned a number sequence as an identifier.

	III. Formal:  These are processed through a full RFC review 
	 	process.  The NID may be any valid NID string
		that does not start with "x" (see Type I above), and
		doesn't clash with an existing, registered NID.

		The two-letter country codes are reserved
		for availability for national registrations.

5.0 Example

A generic "Internet" namespace has been posited throughout recent
discussions of URNs. This namespace might be defined as follows:

Namespace ID:
	
	"INET" requested.
	
Declared registrant of the namespace:  

	T. Cat
	[email-masked]

Declaration of structure:

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

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

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

Identifier persistence considerations:

	Persistence of identifiers is dependent upon suitable
	delegation of resolution at the level of "FQDN"s.

Process of identifier assignment:

	Assignment of these URNs delegated to individual domain
	name holders (for FQDNs).  The holder of the FQDN registration
	is required to maintain an entry (or delegate it) in the
	NAPTR RDS.  Within each of these delegated name partitions,
	the string may be assigned per local requirements.

	e.g.  urn:inet:thinkincat.com:001203

Process for identifier resolution:

	Domain name holders are responsible for operating or
	delegating resolution servers for the FQDN in which they
	have assigned URNs.

Rules for Lexical Equivalence:

	Nothing in particular.

Conformance with URN Syntax:

	No special considerations.

Validation mechanism:

	None specified.

Scope:
	
	Global.

6.0 Security Considerations

This document largely focuses on providing mechanisms for the
declaration of public information.  Nominally, these declarations
should be of relatively low security profile, however there is
always the danger of "spoofing" and providing mis-information.
Information in these declarations should be taken as advisory.

7.0 References

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

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

[RFC2288] C. Lynch, C. Preston & R. Daniel, "Using Existing 
    Bibliographic Identifiers as Uniform Resource Names", RFC 2288,
    February 1998.

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

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

[RFC2276] K. Sollins, "Architectural Principles of Uniform Resource 
    Name Resolution", RFC 2276, January 1998.

8.0 Authors' Addresses

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

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

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

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

Date: Tue, 10 Mar 1998 22:17:36 -0500 (EST)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] Status and Steps Forward
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

There were some outstanding issues that didn't get resolved at the
Washington IETF meeting; I've been holding off on discussion of them
as the discussion of URI syntax and semantics documentation prevailed,
but if we are to have a constructive meeting in LA, there is
work to be done now...

Document status:

Since the December IETF, we've had two more documents go forward
as RFCs:

   Architectural Principles of Uniform Resource Name Resolution (RFC    
   2276)
   Using Existing Bibliographic Identifiers as Uniform Resource Names    
   (RFC 2288) 

and the draft

   URI Resolution Services Necessary for URN Resolution 

is almost there; the ADs had some constructive criticism.  One
more iteration should do it.

The only remaining issues on the table for this working group are:

	1. Namespace definition/identification  
	2. Namespace registration within the NAPTR RDS

These are all that remains between us and fully-functional use of URNs;  
apart from any experimental servers/services that may exist, there are
real-world applications waiting on this (national libraries ready to
deploy on-line systems that use URNs, etc).

We're almost there!

I think we can (have to) finish with "1." by the end of (shortly after)
the upcoming IETF meeting.  "2." is pretty mechanical once "1." has
been done, and assuming the IETF resolves what it's doing with registration
mechanisms in a general way -- i.e., there's little for us to discuss
at this point.  All we can do at this point is assume that there will be
some IANA-like body capable of performing the necessary assignment
tasks.

Of what remains in "1.", there are a few potential ratholes.  But,
if we are to see URNs deployed, we will have to nail down some working 
solutions -- solutions that are implementable now, and yet define a clear 
path for future extension once we have more practical experience.

In a separate message, I will outline the state of discussion on the
issues in Namespace Definition, and attempt to provide a framework
for discussion.

Leslie.

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

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

From: "Sam X. Sun" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Scalability of Handle Resolution (was Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS)
Date: Wed, 4 Mar 1998 01:35:43 -0500
Sender: [email-masked]
Reply-To: "Sam X. Sun" <[email-masked]>

>Sam X. Sun writes:
>> In the current Handle System implementation, the global handle service
>> primarily serves as the referral service to direct the handle resolution
to
>> the responsible local handle service based on the handle's naming
authority.
>> The local handle service, which could be homed in any individual
>> organization from any country, is responsible for the handles registered
>> under its registered naming authority.

Daniel LaLiberte wrote:

>OK, so you now have a two-level hierarchy. That's better, but if it
>ends up being a successful service, the number of handle services listed
>at the top level will also become large. Why not allow any number of
>delegations to happen? If no more than one delegation is ever used,
>there is no harm done.

This is a very good question, and there have been many debates over this
issue. The conclusion is that there are benefits from either way of doing
it. Allowing unlimited number of delegations could definitely reduce the
load for the global handle service. But it does introduce more complexity in
terms of implementation (more delegations, more situations to consider),
namespace management (more delegations, more complexity in terms of
namespace dependency), and potentially more round trips (I guess if I were
to choose between network latency vs. machine latency, I will choose machine
latency because it's much easier to improve.).

It is worth noting that any handle service, global or not, doesn't have to
be a single machine. Each handle service can be configured to consist of
many handle servers, each of the server can be running from an independent
machine, and they all work together to serve the naming authority of the
handle service. The global handle service can consist of many independent
server machines (there are four right now) to handle the top level. The
number of server machines for any (global) handle service can be added as
the requirement goes up. This should allow them to deal with the large
number of handles on any local handle service, or registered naming
authorities on the global handle service. The hashing algorithm pre-decides,
before the request is sent out, which handle server within any handle
service is responsible for any handle or naming authority, hence there's no
extra round trip required to decide the server within any service.

Daniel LaLiberte wrote:

>There is not really any functional difference between what you are
>evolving toward with the handle system and what DNS already has. There
>is a performance difference in that handle servers and clients use hash
>lookup to find information more quickly. Combining hierarchical
>resolution with hash lookup at each level could provide the best of both
>worlds.

DNS and Handle System are all name services, but serving different purposes.
The consensus from the IETF DNS working group seems that it serves well for
its routing purpose, any radical change to it may not be easily accepted or
deployed. We learnt a lot from DNS, and our goal is to try to make the
Handle System a more general and more efficient global name service. This
can be reflected in its namespace definition (<hdl_na>/<hdl_name>, where
<hdl_name> is based on Unicode   vs.  <sub-domain>(.<sub-domain>)+ ), and
administration model (per handle, handle group, or naming authority  vs.
per sub-domain), as well as the resolution protocol, as you have pointed
out. On the other hand, I agree it's still a long way from what it needs to
be, and appreciate very much your opinions on how to make it better.

Regards,
Sam
[email-masked],va.us

From: Al Gilman <[email-masked]>
Subject: [URN] Re: Relative URI vs. URN, and URI uniformity.
To: [email-masked]
Date: Tue, 3 Mar 1998 14:19:01 -0500 (EST)
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Al Gilman <[email-masked]>

to follow up on what Sam Sun said:

> I think it might be helpful to add that the ?#fragment? and
> relative URI are two kind of entities within any certain name
> and are processed differently.  For example,
> href=?relative-uri? is processed by binding ?relative-uri? to
> its base-uri, and sending the complete URI across the wire. But
> for href=?  foo:aaa#bbb?, according to the current URI draft,
> the ?#bbb? would be cut off from the URI reference (since it?s
> not part of URI), and only the ?foo:aaa? get sent over the
> wire.

The idea that "gets sent over the wire" has anything to do with
URIs in general is IMHO a popular misconception.  URIs are
identifiers.  The are strings that key the retrieval of
information in some way as to make the reference widely usable
throughout the Internet.

But file: URLs don't involve exercising telecommunications
protocols, and one of the primary beauties of the Web is the way
the difference between local and remote references is hidden by
the unifying power of the unified scheme of references.

Many news: URLs are totally ambiguous as to whether TCP/IP will
be required to retrieve the identified resource.

For example, an HTML- or XML- processing Ap recognizes an
URI-reference within a document context conditioned by the rules
of that language.  But then it is exercised in a
resource-retrieval service, not a comm protocol, in general.
Lots of these resource-retrieval services employ comm protocols,
but not necessarily all of them.

> My observation is that relative URI defines a client side
> process for compounding names. Based on libwww.lib
> implementation, relative URI never leaves the client side by
> itself, but have to bind to the URI scheme in its base URI
> before it can be of any use. So, if URI is considered a machine
> to machine protocol syntax, is relative URI an URI?

Use of the #fragment can be safely deferred until after the
enclosing object containing the name 'fragment' has been
retrieved.  For lots of schemes such as file: and ftp: it would
break the retrieval to mention the #fragment in external
dealings.  This combination of ingredients has made it customary
to strip the #fragment and then deal with the rest in a
schemewise fashion.  I agree with your arguments that this is not
logically necessary.  But we have to face the fact that it is
essentially-universal current practice.

>  The URN working group defined the syntax for identifiers to be
> transferred over the wire. If I understand correctly, URN
> syntax is designed mainly as a machine to machine protocol
> syntax. 

Then it's not an URI.  That needs to be person-to-machine ready.

> If there were any relative URN to be defined, it would
> mean that the URN service could not be stateless, and have to
> keep history of previous transactions in order to construct
> compound names, which doesn't seem very practical.

> This leads to the question to what URI is.
> 

> First, an observation: Some URI schemes, like “http:” or
> “urn:”, have the client side syntax follow the machine to
> machine protocol syntax. Some other URI schemes don’t. For
> example, the ftp server will not know to convert %23 to
> ‘#’, and when you send
> “ftp:[email-masked]”, the ftp server at
> “foo.com” will not recognize you are user “user#”,
> and entering password “pass#word”. Another example is
> LDAP whose protocol uses UTF-8 encoding, but the URL syntax
> seems to follow the http URL.

Yes, this is all handled already.  Characters that are URL-unsafe
are restored before the ftp communication protocol is exercised
by the gateway acting as ftp: schemwise retrieval service.

> It seems more natural to consider URI as a client side referral
> syntax. For any URI “foo:foo-specific-name”, the URI is
> responsible only to refer “foo-specific-name” to
> “foo:” module, but nothing more. Individual scheme should
> be allowed to decide how to parse its scheme specific data, and
> how to process the “#fragment”. Each scheme should be
> allowed to decide its own set of reserved/excluded characters,
> its character set encoding, and whether the client-side syntax
> follows the protocol syntax.

> If this is the case, it seems that for URI, the only reserved
> characters needed is byte ‘%25’, which is character % in
> ASCII encoding. And the only excluded character needed is byte
> ‘%22’, which is character ” in ASCII encoding. The
> ‘%25’ is needed to allow non-printable characters be
> entered and be understood. The ‘%22’ is necessary for
> separating URI from its surrounding context.

> Also, URI doesn’t have to be constrained to a subset of
> ASCII characters only, but should let individual URI scheme to
> decide how to support international character sets. Based on
> what I saw, the only strong arguments for URI to be ASCII only
> is that it is printable and can be entered from almost any (not
> all!) keyboard. These might be nice user interface features for
> “http:” URL, not necessarily for all other URIs. To be
> short, not every document is written to be readable by anyone
> around the world, nor would it necessary to require _every_
> NAME to be defined printable and enterable by anyone around the
> world. It should be a decision of the name issuer, not the
> underlying technology.

Yes, but every URI needs to be written to be interpretable in
many, many contexts used for global information distribution.
You want name visibility to be unhampered or it's not an URI.
The internationalization of URIs may have room for variations
lower down, but the internationalization scheme has to boot from
somewhere known or or we don't have URIs anymore.

URIs are used in a range of contexts.  Two of the most common are
HREF attributes in HTML documents and Location: etc. headers in
HTTP messages.  Header-safe character restrictions are a
efficiency and error-reducing measure in this major domain of
application.  This restriction should not be removed until the
replacement scheme has been demonstrated not to materially
degrade service in this scenario.

The restriction to the current RFC-822-header-safe subset of
ASCII is temporary under the plans as I hear them.  But it does
not make sense to open this up to a schemwise free-for-all or the
clients will choke on the necessary library.  Saying that some
clients will support some schemes defeats the purpose.  The point
of URIs is so that more clients can support more schemes.

I think that

 "Character Set" Considered Harmful
 http://www.w3.org/MarkUp/html-spec/charset-harmful.html

may be relevant here.

>  Essentially, I’m suggesting that the uniformity of URI
> should be only on its scheme binding syntax, as is commonly
> accepted in the web context, but not extend into the scheme
> specific content.

You need a better migration plan for existing clients.  To
declare this abruptly will cause gaps in service and loss
of customer confidence.

Al

Date: Tue, 3 Mar 1998 13:26:00 -0500
From: <[email-masked]>
To: "Sam X. Sun" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Scalability of Handle Resolution (was Re: FYI, AAP DEVELOPS DIGITAL I.D. SYSTEM FOR PUBLICATIONS)
Sender: [email-masked]
Reply-To: <[email-masked]>

Sam X. Sun writes:
 > In the current Handle System implementation, the global handle service
 > primarily serves as the referral service to direct the handle resolution to
 > the responsible local handle service based on the handle's naming authority.
 > The local handle service, which could be homed in any individual
 > organization from any country, is responsible for the handles registered
 > under its registered naming authority.

OK, so you now have a two-level hierarchy.  That's better, but if it
ends up being a successful service, the number of handle services listed
at the top level will also become large.  Why not allow any number of
delegations to happen?  If no more than one delegation is ever used,
there is no harm done.

 > 1. Query the global handle service to obtain the "service information" for
 > the naming authority “hdl_na”.
 > 
 > 2. Query the local handle service specified in the "service information"
 > obtained from step 1, to get the handle data for "hdl_na/hdl_namestring".
 > 
 > Some notes about the above procedure:
 > 
 > a) Result of step 1 can be cached by the client so that subsequent query
 > under the same naming authority may need only one round trip.
 >
 > b) The global handle service can be duplicated many places in the world to
 > make the step 1 more efficient.
 > 
 > c) A handle system caching server can be installed on behalf of an
 > organization to handle the caching on an organizational basis.

That is all good - it begins to address locality-of-reference.

 > Strictly speaking, handle resolution is "hierarchical", but in a limited
 > fashion. That is, the number of round trips for any resolution is always
 > less than 3. This is different from the DNS resolution where the number of
 > round trips could be as many as the number of <subdomain>s in the DNS name.

But the possibility of adding levels is not a disadvantage - it is an
advantage.  It allows greater use of locality-of-reference, and greater
flexibility in moving things around.  Furthermore, in practice, the
number of round trips will not be that much greater, if at all, because
partial resolution information will have been cached from previous requests.

 > On the other hand, caching "service information" allows subsequent handle
 > resolution to be performed in a single step. But the "service information"
 > has to be obtained from the global handle service to guarantee global
 > resolution uniqueness.

Not necessarily.  Cached information can have an expiration date so
clients don't need to check every time but, say, once a day.

 > This is different from DNS resolution, which
 > essentially does a local lookup first, and there is no global coordination
 > if the name is found in the local database (imagine the situation where the
 > local administrator decides to add a <subdomain> and not bothering to
 > register it with the upper domain).

Any cache service and registration mechanism can be abused, of course,
DNS or not.

There is not really any functional difference between what you are
evolving toward with the handle system and what DNS already has.  There
is a performance difference in that handle servers and clients use hash
lookup to find information more quickly.  Combining hierarchical
resolution with hash lookup at each level could provide the best of both
worlds.

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

From: "Sam Sun" <[email-masked]>
To: "Al Gilman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Relative URI vs. URN, and URI uniformity.  (was Re: [URN] #fragment as :name)
Date: Mon, 2 Mar 1998 11:48:38 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>

Al Gilman said:
>......
>In the schemes that the URN community is contemplating, this is
>probably not true.  Once one enters a namespace discipline, one
>may not expect interior namespaces to be randomly declared by
>the values found for exterior names.
>

My observation is that relative URI defines a client side process for
compounding names. Based on libwww.lib implementation, relative URI never
leaves the client side by itself, but have to bind to the URI scheme in its
base URI before it can be of any use. So, if URI is considered a machine to
machine protocol syntax, is relative URI an URI?

The URN working group defined the syntax for identifiers to be transferred
over the wire. If I understand correctly, URN syntax is designed mainly as a
machine to machine protocol syntax. If there were any relative URN to be
defined, it would mean that the URN service could not be stateless, and have
to keep history of previous transactions in order to construct compound
names, which doesn't seem very practical.

This leads to the question to what URI is.

First, an observation: Some URI schemes, like “http:” or “urn:”, have the
client side syntax follow the machine to machine protocol syntax. Some other
URI schemes don’t. For example, the ftp server will not know to convert %23
to ‘#’, and when you send “ftp:[email-masked]”, the ftp server
at “foo.com” will not recognize you are user “user#”, and entering password
“pass#word”. Another example is LDAP whose protocol uses UTF-8 encoding, but
the URL syntax seems to follow the http URL.

It seems more natural to consider URI as a client side referral syntax. For
any URI “foo:foo-specific-name”, the URI is responsible only to refer
“foo-specific-name” to “foo:” module, but nothing more. Individual scheme
should be allowed to decide how to parse its scheme specific data, and how
to process the “#fragment”. Each scheme should be allowed to decide its own
set of reserved/excluded characters, its character set encoding, and whether
the client-side syntax follows the protocol syntax.

If this is the case, it seems that for URI, the only reserved characters
needed is byte ‘%25’, which is character % in ASCII encoding. And the only
excluded character needed is byte ‘%22’, which is character ” in ASCII
encoding. The ‘%25’ is needed to allow non-printable characters be entered
and be understood. The ‘%22’ is necessary for separating URI from its
surrounding context.

Also, URI doesn’t have to be constrained to a subset of ASCII characters
only, but should let individual URI scheme to decide how to support
international character sets. Based on what I saw, the only strong arguments
for URI to be ASCII only is that it is printable and can be entered from
almost any (not all!) keyboard. These might be nice user interface features
for “http:” URL, not necessarily for all other URIs. To be short, not every
document is written to be readable by anyone around the world, nor would it
necessary to require _every_ NAME to be defined printable and enterable by
anyone around the world. It should be a decision of the name issuer, not the
underlying technology.

Essentially, I’m suggesting that the uniformity of URI should be only on its
scheme binding syntax, as is commonly accepted in the web context, but not
extend into the scheme specific content.

Regards,
Sam
[email-masked]

From: "Sam Sun" <[email-masked]>
To: "Al Gilman" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Relative URI vs. #fragment. (was Re: [URN] #fragment as :name)
Date: Mon, 2 Mar 1998 11:35:27 -0500
Sender: [email-masked]
Reply-To: "Sam Sun" <[email-masked]>

>This is an observation, not a proposal.
>
>It appears to me that the established uses of #fragment with HTML
>documents, and the proposed extensions with XML documents (which
>are designed to be compatible with the HTML-driven uses) are all
>cases where what follows the # character is a name reference.
>
>It is a reference to a name defined in a namespace which is in
>turn defined by the object identified in the preceding name.
>It is a "classic case of namespace descent."  The spelling might
>as easing be scheme:stuff:fragment where stuff comprises the
><site> and <path> parts in conventional URL usage.
>

>It is the fact that ID and NAME are both attribute designators
>from a common namespace that lets Lynx treat IDs in HTML in a
>manner "homologous to #name" and extend the scope of #name to
>include #[name | id] with no damage whatsoever.
>

I think it might be helpful to add that the “#fragment” and relative URI are
two kind of entities within any certain name and are processed differently.
For example, href=”relative-uri” is processed by binding “relative-uri” to
its base-uri, and sending the complete URI across the wire. But for href=”
foo:aaa#bbb”, according to the current URI draft, the “#bbb” would be cut
off from the URI reference (since it’s not part of URI), and only the
“foo:aaa” get sent over the wire.