Subject: *FREE* XXX Accounts! (MUST be 18+ w/CC)

From: [email-masked]
Date: Wed, 29 Jul 1998 09:00:48 EDT

<a href="http://www.angelfire.com/ia/aff3/index.html">Click Here for XXX Site
#1!</a>

<a href="http://www.angelfire.com/ia/aff3/index.html">Click Here for XXX Site
#2!</a>

<a href="http://www.cybererotica.com/ad/rrr-in.html?rrr_3309/C">Click Here for
XXX Site #3!</a>

<a href="http://www.cybererotica.com/ad/rrr-in.html?rrr_3309/C">Click Here for
XXX Site #4!</a>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-ietf-06.txt
Date: Fri, 24 Jul 1998 14:31:49 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

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

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

Internet-Drafts are also available by mail.

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

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

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

--OtherAccess--

--NextPart--

Date: Tue, 21 Jul 1998 16:15:24 -0500 (CDT)
To: [email-masked]
Cc: [email-masked]
Subject: [URN] Replacement of draft-ietf-urn-ietf-05.txt
From: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

To the I-D editor:

The following is a replacement of draft-ietf-urn-ietf-05.txt.  It has
been modified based on comments I have received.  Please add it
to the repository...

To the URN mailing list:

Here is draft-ietf-urn-ietf-06.txt.  I've added support for internet-drafts
(got enough requests, no complaints, and I figured out how to do it
fairly painlessly).  The example code is getting pretty ugly, but it still
works.  The test resolver at blackhole.vip.att.net works (at least it
did when I tested it :-).

On the subject of i-ds, currently I include the version number in the
URN.  I thought about not doing so, but didn't implement it.  Opinions
are welcome.

Ryan

=========

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

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

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

0.2 Changes from -03

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

0.3 Changes from -04

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

0.4 Changes from -05

   Based on a number of requests, i-ds have been added to the structure
   and resolvers. In addition, some examples have been added.

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)
                      ( "id:" name)
                family = "rfc" / "std" / "fyi" / "bcp"
                number = 1*DIGIT
                wgbofname = 1*LETDIGIT
                name =  id draft designation with "draft-" and trailing

Expires 12/31/98                                                [Page 2]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

                        type removed (e.g. ietf-urn-ietf-06)
                LETDIGIT = DIGIT / %x41-%x5a / %x61-%x7a
                DIGIT = %x30-%x39

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

        Identifier uniqueness considerations:

                Because the rfc-editor assigns the RFC number uniquely
                these URNs are unique.  Since the mapping between RFCs
                and other rfc-editor document series (STDs, FYIs or
                BCPs) is not necessarily one-to-one, uniqueness of
                STDs, FYIs and BCPs are defined based on the document
                mappings maintained by the RFC Editor (the index files
                "rfc-index.txt", "fyi-index.txt", "bcp-index.txt",
                "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.
                The document mapping maintained by the Internet Drafts
                editor ("1id-abstracts.txt") is defined as the
                definitive statement of the assignment of URNs for
                the internet draft portion of this namespace.

        Identifier persistence considerations:

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

        Process of identifier assignment:

Expires 12/31/98                                                [Page 3]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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

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

                The third way a URN is assigned is through the
                publication of a new internet-draft by the Internet
                Draft Editor.  This draft will have a distinct name
                (and version number) and therefore defined a new URN.
                The document mapping maintained by the Internet Drafts
                editor ("1id-abstracts.txt") is defined as the
                definitive statement of the assignment of URNs for
                this portion of the namespace.

        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.

Expires 12/31/98                                                [Page 4]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

        Scope:

                Global.

3. Examples

   The following are examples of URNs that a resolver for this namespace
   can resolve:

           urn:ietf:rfc:2141
           urn:ietf:std:50
           urn:ietf:id:ietf-urn-ietf-06.txt
           urn:ietf:mtg-41-urn

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

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

6. References

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

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

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

7. Author's Address

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

Expires 12/31/98                                                [Page 5]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

   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) = (
  bcp => "/ftp/rfc/bcp-index.txt",
  fyi => "/ftp/fyi/fyi-index.txt",
  id => "/ftp/internet-drafts/1id-abstracts.txt",
  rfc => "/ftp/rfc/rfc-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

(&resolveid($1), exit) if ($urn =~ /urn:ietf:id:(i);
(&resolverfc($1, $2), exit) if ($urn =~ /urn:ietf:(72)/i);
(&resolvemtg($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(9*)-(
120&urn_error("400 Bad Request0);

Expires 12/31/98                                                [Page 6]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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

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 resolverfc {
  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 Found0);
  }

  $flag = 0;
  open(INPUT, "$cite{$scheme}");

Expires 12/31/98                                                [Page 7]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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

  if ($scheme ne "rfc") {
    print "Status:  200 OK70;
    print "Content-type: text/html70;
    $bib[0] =~ s/^[0-9]*/<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>0TITLE>Citation for $urn</TITLE>0;
    print "<BODY>0;
    $link=&make_link("$scheme$value");
    print "<H1><A HREF=
    foreach $i (@bib) {
      print "$i0;
    }
    print "</BODY>0/HTML>0;
  } else {
    print "Status:  200 OK70;
    print "Content-type: text/html70;
    $bib[0] =~ s/^[0-9]*//;
    $j=0;
    for ($i=0; $i<=$#bib; $i+=1) {
      $j += ($bib[$i] =~ s/, "/, <B>"/);
      $j += ($bib[$i] =~ s/",/"</B>,/);

Expires 12/31/98                                                [Page 8]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

    }
    for ($i=0;$i<=$#bib;$i+=1) {
      $k=$bib[$i];
      while ($k =~ /(fyistdrfc|bcp)([0-9]+)(.*)/i) {
        push @ref,"$1$2";
        $k=$3;
      }
      $done="";
      foreach $j (@ref) {
        next if ($done =~ $j);
        $done .= "$j ";
        $l = $j;
        $l =~ s//g;
        $l =~ tr/A-Z/a-z/;
        $link=&make_link("$l");
        $bib[$i] =~ s/$j/<A HREF="$link">$j</A>/g;
      }
    }
    print "<HTML>0TITLE>Citation for $urn</TITLE>0;
    print "<BODY>0;
    $link=&make_link("$scheme$value");
    print "<H1><A HREF=
    foreach $i (@bib) {
      print "$i0;
    }
    print "</BODY>0/HTML>0;
  }
}

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

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

  print "Status:  $code";
  print "Content-type: text/html0HTML>0;
  print "<head><title>URN Resolution: I2C $code</title></head>0;
  print "<BODY>0;
  print "<h1>URN to URC resolution failed for the URN:</h1>0;
  print "<hr><h3>$urn</h3>0;
  print "</body>0;

Expires 12/31/98                                                [Page 9]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

  print "</html>0;
  exit;
};

sub resolveid {
  my($flag,@bib,$i,$k,$j,$count,@ref);
  my($l,$link, $hdr, $done);
  my($value) = @_;
  my($scheme) = "id";

  open(INPUT, "$cite{$scheme}");
  while (<INPUT>) {
#
# capture record
#
    if ($flag == 1 || /^
      push @bib,$_;
      ($hdr = -1, $count = 0, $flag = 1) if (/^
      $count++ if (/^/);
    }
    if ($count == 1) {
      $hdr = $#bib if ($hdr == -1);
    }
    if ($count == 2) {
      for ($i=0; $i<=$hdr; $i+=1) {
            if ($bib[$i] =~ /<(.*)>/) {
              $l = $1;
              if ($l eq "draft-$value.txt" || $l eq "draft-$value.ps") {
                print "Status:  200 OK70;
                print "Content-type: text/html70;
                print "<HTML>0TITLE>Citation for $urn</TITLE>0;
                print "<BODY>0;
                print "<a href=
                print "<pre>0;
                foreach $i (@bib) {
                  print "$i";
                }
                print "</pre>0;
                print "</BODY>0/HTML>0;
                exit;
              }
            }
      }
      $flag = 0;
      @bib = ();
    }
  }
  &urn_error("404 Not Found0);

Expires 12/31/98                                               [Page 10]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

}

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",
  id => "internet-drafts/draft-",
);

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

(&resolveid($1), exit) if ($urn =~ /urn:ietf:id:(i);
(&resolverfc($1, $2), exit) if ($urn =~ /urn:ietf:(72)/i);
(&resolvemtg($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(9*)-(
120&urn_error("400 Bad Request0);

sub resolvemtg {
  my($ietfnum, $sesnam) = @_;
  &urn_error("404 Not Found0) if (!defined $number2date{$ietfnum});
  my($date)=$number2date{$ietfnum};
  my($link)="$wgpath/$sesnam/$sesnam-minutes-$date.txt";
  if (-f $link) {
    print "Status:  302 Moved temporarily0;

Expires 12/31/98                                               [Page 11]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

    print "Location: $link0;
    return;
  }
  my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
  if (-f $link) {
    print "Status:  302 Moved temporarily0;
    print "Location: $link0;
    return;
  }
  &urn_error("404 Not Found0);
}

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 resolverfc {
  my($flag,@bib,$i,$k,$j,$done,@ref);
  my($l,$link);
  my($scheme, $value) = @_;
  $scheme =~ tr/A-Z/a-z/;
  &urn_error("404 Not Found0)if (!defined $pathbase{$scheme});
  my($txttry)="/ftp/$pathbase{$scheme}$value.txt";
  my($pstry)="/ftp/$pathbase{$scheme}$value.ps";
  my($htmltry)="/ftp/$pathbase{$scheme}$value.html";
MIME_SWITCH: {
    if ($accept =~ /application/postscript/ && -f $pstry) {
      print "Status:  302 Moved temporarily0;
      print "Location: http://$host/$pathbase{$scheme}$value.ps0;
      last MIME_SWITCH;
    }
    if ($accept =~ /text/html/ && -f $htmltry) {
      print "Status:  302 Moved temporarily0;
      print "Location: http://$host/$pathbase{$scheme}$value.html0;
      last MIME_SWITCH;
    }
    if ($accept =~ /text/plain/ && -f $txttry) {
      print "Status:  302 Moved temporarily0;
      print "Location: http://$host/$pathbase{$scheme}$value.txt0;
      last MIME_SWITCH;
    }
    &urn_error("404 Not Found0);
  }
}

Expires 12/31/98                                               [Page 12]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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

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

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

A.3 I2Ls

#!/usr/local/bin/perl

Expires 12/31/98                                               [Page 13]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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",
             id => "internet-drafts/draft-"
);

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

(&resolveid($1), exit) if ($urn =~ /urn:ietf:id:(i);
(&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(72)/i);
(&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(9*)-(
120&urn_error("400 Bad Request0);

sub resolve2 {
  my($ietfnum, $sesnam) = @_;
  &urn_error("404 Not Found0) 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

Expires 12/31/98                                               [Page 14]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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

Expires 12/31/98                                               [Page 15]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

  }
  &urn_error("404 Not Found0);
}

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 Found0)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 Found0) if ($#urls == -1);

MIME_SWITCH: {
    if ($accept =~ /text/uri-list/) { #look for text/uri-list, otherwise text/html
      print "Status: 200 OK0;
      print "Content-type: text/uri-list0;
      print "#$urn0;
      foreach $i (@urls) {
        print "$i0;
      }
      last MIME_SWITCH;
    }
    if ($accept =~ /text/html/) {
      print "Status: 200 OK0;
      print "Content-type: text/html0HTML>0;
      print "<head><title>URN Resolution: I2Ls</title></head>0;
      print "<BODY>0;
      print "<h1>URN $urn resolves to the following URLs:</h1>0;
      print "<hr><ul>0;
      foreach $i (@urls) {

Expires 12/31/98                                               [Page 16]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

        print "<LI><A HREF=
      }
      print "</UL>0/body>0/HTML>0;
      last MIME_SWITCH;
    }
  }
}

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

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

sub resolveid {
  my($flag,@bib,$i,$k,$j,$done,@ref);
  my($l,$link);
  my($value) = @_;
  my($scheme) = "id";
  $scheme =~ tr/A-Z/a-z/;
  &urn_error("404 Not Found0)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 Found0) if ($#urls == -1);

Expires 12/31/98                                               [Page 17]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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

A.4 I2Ns

#!/usr/local/bin/perl

use strict;

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

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

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

Expires 12/31/98                                               [Page 18]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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

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

(&resolve1("id", $1), exit) if ($urn =~ /urn:ietf:id:(/i);
(&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(72)/i);
(&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(9*)-(
120&urn_error("400 Bad Request0);

sub resolve2 {
  my($ietfnum, $sesnam) = @_;
  &urn_error("404 Not Found0) 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 "Status: 200 OK0;
        print "Content-type: text/uri-list0;
        print "#$urn0;
        return;
    }
    if ($accept =~ /text/html/) {
      print "Status: 200 OK0;
      print "Content-type: text/html0HTML>0;
      print "<head><title>URN Resolution: I2Ns</title></head>0;
      print "<BODY>0;
      print "<h1>URN $urn resolves to the following URNs:</h1>0;
      print "<hr><ul>0;
      print "</UL>0/body>0/HTML>0;
      return;
    }
  }
  my($link)="$wgpath/$date/$sesnam-minutes-$date.txt";
  if (-f $link) {
    if ($accept =~ /text/uri-list/) {
        print "Status: 200 OK0;
        print "Content-type: text/uri-list0;
        print "#$urn0;
        return;
    }

Expires 12/31/98                                               [Page 19]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

    if ($accept =~ /text/html/) {
        print "Status: 200 OK0;
        print "Content-type: text/html0HTML>0;
        print "<head><title>URN Resolution: I2Ns</title></head>0;
        print "<BODY>0;
        print "<h1>URN $urn resolves to the following URNs:</h1>0;
        print "<hr><ul>0;
        print "</UL>0/body>0/HTML>0;
        return;
    }
  }
  &urn_error("404 Not Found0);
}

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

  $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 =~ /(fyi|std|rfc|bcp)([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/;

Expires 12/31/98                                               [Page 20]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

      $b =~ s/^0*//;
      push @ref,"urn:ietf:$a:$b";
    }
  }

MIME_SWITCH: {
    if ($accept =~ /text/uri-list/) {
        print "Status: 200 OK0;
        print "Content-type: text/uri-list0;
        print "#$urn0;
        foreach $i (@ref) {
            print "$i0;
        }
        last MIME_SWITCH;
    }
  if ($accept =~ /text/html/) {
    print "Status: 200 OK0;
    print "Content-type: text/html0HTML>0;
    print "<head><title>URN Resolution: I2Ns</title></head>0;
    print "<BODY>0;
    print "<h1>URN $urn resolves to the following URNs:</h1>0;
    print "<hr><ul>0;
        foreach $i (@ref) {
            print "<li>$i: Click to resolve using0;
            print "<a href=
            print "<a href=
            print "<a href=
            print "<a href=
            print "<a href=
        }
    print "</UL>0/body>0/HTML>0;
  }
}
}

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

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

  print "Status: $code";

Expires 12/31/98                                               [Page 21]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

  print "Content-type: text/html0HTML>0;
  print "<head><title>URN Resolution: I2Ns $code</title></head>0;
  print "<BODY>0;
  print "<h1>URN to URN resolution failed for the URN:</h1>0;
  print "<hr><h3>$urn</h3>0;
  print "</body>0;
  print "</html>0;
  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",
  id => "internet-drafts/draft-"
);

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

print "$urn0;
(&resolveid($1), exit) if ($urn =~ /urn:ietf:id:(i);
(&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(72)/i);

Expires 12/31/98                                               [Page 22]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

(&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(9*)-(
120&urn_error("400 Bad Request0);

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

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 Found0)if (!defined $pathbase{$scheme});
  my($txttry)="/ftp/$pathbase{$scheme}$value.txt";
  my($pstry)="/ftp/$pathbase{$scheme}$value.ps";

Expires 12/31/98                                               [Page 23]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

  my($htmltry)="/ftp/$pathbase{$scheme}$value.html";
MIME_SWITCH: {
    if ($accept =~ /application/postscript/ && -f $pstry) {
      print "Status:  200 OK0;
      print "Content-type: application/postscript0;
      open(FILE, "$pstry");
      while (<FILE>) {
          print $_;
      }
      close FILE;
      last MIME_SWITCH;
    }
    if ($accept =~ /text/html/ && -f $htmltry) {
        print "Status:  200 OK0;
        print "Content-type: text/html0;
        open(FILE, "$htmltry");
        while (<FILE>) {
            print $_;
        }
        close FILE;
        last MIME_SWITCH;
    }
    if ($accept =~ /text/plain/ && -f $txttry) {
        print "Status:  200 OK0;
        print "Content-type: text/plain0;
        open(FILE, "$txttry");
        while (<FILE>) {
            print $_;
        }
        close FILE;
        last MIME_SWITCH;
    }
    &urn_error("404 Not Found0);
  }
}

sub resolveid {
  my($flag,@bib,$i,$k,$j,$done,@ref);
  my($l,$link);
  my($scheme) = "id";
  my($value) = @_;
  $scheme =~ tr/A-Z/a-z/;
  &urn_error("404 Not Found0)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) {

Expires 12/31/98                                               [Page 24]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

      print "Status:  200 OK0;
      print "Content-type: application/postscript0;
      open(FILE, "$pstry");
      while (<FILE>) {
          print $_;
      }
      close FILE;
      last MIME_SWITCH;
    }
    if ($accept =~ /text/html/ && -f $htmltry) {
        print "Status:  200 OK0;
        print "Content-type: text/html0;
        open(FILE, "$htmltry");
        while (<FILE>) {
            print $_;
        }
        close FILE;
        last MIME_SWITCH;
    }
    if ($accept =~ /text/plain/ && -f $txttry) {
        print "Status:  200 OK0;
        print "Content-type: text/plain0;
        open(FILE, "$txttry");
        while (<FILE>) {
            print $_;
        }
        close FILE;
        last MIME_SWITCH;
    }
    &urn_error("404 Not Found0);
  }
}

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

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

Expires 12/31/98                                               [Page 25]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

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",
  id => "internet-drafts/draft-"
);

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

(&resolveid($1), exit) if ($urn =~ /urn:ietf:id:()/i);
(&resolve1($1, $2), exit) if ($urn =~ /urn:ietf:(72)/i);
(&resolve2($1, $2), exit) if ($urn =~ /urn:ietf:mtg-(9*)-(
120&urn_error("400 Bad Request0);

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

Expires 12/31/98                                               [Page 26]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

      push(@vers,$link);
  }
  $link="$wgpath/$date/$sesnam-minutes-$date.txt";
  if (-f $link) {
      push(@vers,$link);
  }
  &urn_error("404 Not Found0) if ($#vers==-1);

  print "Status: 200 OK0;
  print "Content-type: multipart/alternative; boundary=endpart0;
  foreach $i (@vers) {
      print "--endpart0;
      if ($i =~ /html$/) {
          print "Content-Type: text/html0;
      }
      if ($i =~ /txt$/) {
          print "Content-Type: text/plain0;
      }
      if ($i =~ /ps$/) {
          print "Content-Type: application/postscript0;
      }
      open(FILE, "$i");
      while (<FILE>) {
          print "$_";
      }
      close FILE;
  }
  print "--endpart0;
}

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

Expires 12/31/98                                               [Page 27]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

  print "Status: 200 OK0;
  print "Content-type: multipart/alternative; boundary=endpart0;
  foreach $i (@vers) {
      print "--endpart0;
      if ($i =~ /html$/) {
          print "Content-Type: text/html0;
      }
      if ($i =~ /txt$/) {
          print "Content-Type: text/plain0;
      }
      if ($i =~ /ps$/) {
          print "Content-Type: application/postscript0;
      }
      open(FILE, "$i");
      while (<FILE>) {
          print "$_";
      }
      close FILE;
  }
  print "--endpart0;
}

sub resolveid {
  my($flag,@bib,$i,$k,$j,$done,@ref);
  my($l,$link,@vers);
  my($scheme) = "id";
  my($value) = @_;
  $scheme =~ tr/A-Z/a-z/;
  &urn_error("404 Not Found0)if (!defined $pathbase{$scheme});
  my($try)="/ftp/$pathbase{$scheme}$value.txt";
  if (-f $try) {
      push(@vers, $try);
  }
  $try="/ftp/$pathbase{$scheme}$value.ps";
  if (-f $try) {
      push(@vers, $try);
  }
  $try="/ftp/$pathbase{$scheme}$value.html";
  if (-f $try) {
      push(@vers, $try);
  }
  print "Status: 200 OK0;
  print "Content-type: multipart/alternative; boundary=endpart0;
  foreach $i (@vers) {
      print "--endpart0;
      if ($i =~ /html$/) {
          print "Content-Type: text/html0;
      }

Expires 12/31/98                                               [Page 28]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1998

      if ($i =~ /txt$/) {
          print "Content-Type: text/plain0;
      }
      if ($i =~ /ps$/) {
          print "Content-Type: application/postscript0;
      }
      open(FILE, "$i");
      while (<FILE>) {
          print "$_";
      }
      close FILE;
  }
  print "--endpart0;
}
sub urn_error {
  my($code) = @_; #store failure code here...

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

Expires 12/31/98                                               [Page 29]

From: "Ryan Moats" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>, <[email-masked]>
Subject: RE: [URN] updated nid document and status
Date: Mon, 6 Jul 1998 15:10:28 -0500
Importance: Normal
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

> Leslie wrote [much deleted because I only have a little to
> say]
>
> 	. IETF namespace document: as done as it's likely to get

Maybe so, maybe not.  There have been some calls for adding
internet-drafts to the IETF namespace.  I don't think there is working
group consensus on whether this is a good idea or not.  I've realized
that it isn't that difficult to add to the code, so I'm willing
to add it if there is consensus.  However, if it's added I don't know
if the document can be finalized before the draft deadline for Chicago
(forget about 7/31).

Ryan

Date: Sat, 4 Jul 1998 20:28:28 +0200
To: "Larry Masinter" <[email-masked]>
From: "John C. Mallery" <[email-masked]>
Subject: [URN] URLs Resolved by URI Resolution: Radically Underspecified
Cc: "Leslie Daigle" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Reply-To: "John C. Mallery" <[email-masked]>

Larry,

Way before we get too wound up about merging non-URN URIs, I believe
it is critical to have a solid proposal on how a URL is resolved
with a URI resolver.

Specifically, we need to identify:

	1. How does a client determine when to use a URI
	resolver rather than just use the RDS information
	wired into the identifier?

	2. Once we know to use a URI resolver(s), how do we
	discover which URI resolver to use?

	3. How do we know which URI resolver or server is
	authoritative?

	4. How does this interact with HTTP proxying?

	5. Now that we have a URI resolver(s) to talk to
	and we know their status, what kind of merging do you 
	propose on the opaque string that the client passes to 
	the resolver?

My intuition is that discovering a URI resolver for a
random URL will require some pretty serious thinking,
especially for a scalable solution.

Until we have that concept worked out, we may be spinning
our wheels trying to push Jim Getty's idea about character
macros implying hierarchical identifiers ("/") in URIs 
just to get the URI spec standardized and push HTTP to proposed standard.

Recall that the retrofitting of late binding to URLs when
URN resolution was renamed URI resolution never elicited
a specification on how to resolve URLs, especially HTTP scheme
URLs, in this way. I suspect that working out this problem is
the real barrier to moving things forward.

It seems a good bet that URI resolution of URLs will involve
just passing an opaque string to the resolver (per the URN
specs), and therefore, the merging/hierarchy issue will become 
moot. The client will just perform the original merge
just as it would have done if it were using the RDS info that
URLs wire in, and then, it will pass that string to the resolver.

Since URNs don't wire in RDS information, it's not clear to me
that these concepts from URLs are commensurate in general, although
specific namespaces may wish to employ "/" as a hierarchy delimiter.
Certainly, namespace designers would be well-advised to treat "/"
specially and use it when their namespace includes a hierarchy
analogous to directory structure.

BTW, some other questions include:

	1. Should their be a URN-like specification for
	how to resolve each URL type?

	2. Should there be a namespace where RDS-accessible
	URLs live?

Date: Fri, 3 Jul 1998 12:19:27 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] updated nid document and status
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Howdy,

This long message covers:

	. updated URN namespace definitions document
	. NO MEETING IN CHICAGO
	. outstanding document status

Attached is a revised version of the URN namespace definitions document.
I'll be away on vacation next week, but I'll wait to read comments on
this (and update accordingly) before shipping it off to the I-D editor.

The major changes are as follows:

	. introduction of a mailing list for discussion of NID registration
	  templates (analogous to the ietf-types mailing list)

	. added a section of the template for listing relevant published
	  material

	. deprecation of the INET namespace

This last was included because this document is made clearer with the
inclusion of an example.  However, as was pointed out by a couple of people,
the INET namespace as proposed had some significant technical problems 
(largely inherited from the DNS).  Rather than hold up this document by
trying to address those, and after speaking with the ADs about this issue,
I've deprecated the illustration to (hopefully) make it clearer that this
is not thought to be perfect and is not intended as a seriously-proposed
namespace.  I did not remove/disable it completely, however, because
as it stands it does at least represent the outcome of a few people-hours
of thought (as opposed to asking my cat for an alternate illustration).
I think it's important to have something relatively well-thought out as
an illustration.

If people feel differently and have a proposal of how to otherwise get
around this illustration problem, please let me know.

As it stands today, I don't believe there is any reason to meet in Chicago.
I believe we can wrap up the documents of this group and get them shipped
to the IESG by the end of July, resolving any necessary follow-on details
on the mailing list.  If anyone sees any compelling reason to meet, please
drop me a line directly.

Document status is as follows:

	. IETF namespace document: as done as it's likely to get

	. URN resolution services document:  waiting for discussion of
	  Larry's proposed changes to I2R (returning base information).

	. NAPTR registration document: any serious outstanding discussions?

	. NID registration document:  attached for discussion; should be
	  just about done.

	. PDI documentation:  ?

Leslie.

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

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

Major changes:

	. added  section in template for "ancillary documentation"
	. added [email-masked] discussion mailing list
	. INET -> assigned number.

Internet Draft                               Leslie L. Daigle
July 3, 1998                                 Bunyip Information Systems
draft-ietf-urn-nid-req-04.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". 

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 Internet Assigned Number Authority, 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.  See [NAPTR-REG] for information
on obtaining registration in the NAPTR global NID directory.

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

Relevant ancillary documentation:

	This section should list any RFCs, standards, or other published
	documentation that defines or explains all or part of the
	namespace structure.

	Answers might include, but are not limited to:
	
	. RFCs outlining syntax of the namespace
	. Other community's (e.g., ISO) documents outlining syntax
	  of the identifiers in the namespace
	. Explanatory material introducing the namespace

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 Process

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 explicitly registered with IANA. They
	        take the form

		x-<NID>

		No provision is made for avoiding collision of experimental
	 	NIDs; they are intended for use within internal or limited 
		experimental contexts.

	 II. Informal:  These are registered with IANA and are assigned a 
		number sequence as an identifier, in the format:
		
			"iana-" <number>

		where <number> is chosen by the IANA on a First Come First
	 	Served basis (see [IANA-CONSIDERATIONS]).

		Registrants should send a copy of the registration
	  	template (see section 3.0), duly completed, to the 

			[email-masked]

		mailing and allow for a 2 week discussion period for
		clarifying the expression of the registration information
		and suggestions for improvements to the namespace proposal.  
		
		After suggestions for clarification of the registration 
		information have been incorporated, the template may be 
		submitted to:
	 	
			[email-masked] 

		for assignment of a NID.

	 	The only restrictions on <number> are that it consist
		strictly of digits and that it not cause the NID to exceed
		length limitations outlined in the URN syntax ([RFC2168]).

	III. Formal:  These are processed through an RFC review 
	 	process.  The RFC need not be standards-track.  The template 
		defined in section 3.0 may be
		included as part of the RFC, or a separate message
		referencing the RFC.  The proposed template should
		be sent to the 

			[email-masked]

		mailing list to allow for a 2 week discussion period.

		The registration template should then be sent to 

			[email-masked]

		A particular NID string is requested, and is assigned by IETF
		consensus (as defined in [IANA-CONSIDERATIONS]), with
		the additional constraints that the NID string must 
		not start with "x-" (see Type I above) or "iana-" (see Type II 
		above), and is not already a registered NID.

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

5.0 Example

The following example is provided for the purposes of illustration of
the URN NID template described in section 3.0.  Although it is based on
a posited "generic Internet namespace" that has been discussed informally
within the URN WG, there are still technical and infrastructural issues
that would have to be resolved before such a namespace could be properly
and completely described.  

Namespace ID:
	
	To be assigned
	
Declared registrant of the namespace:  

	T. Cat
	[email-masked]

Declaration of structure:

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

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

Relevant ancillary documentation:

	Definition of domain names, found in:

	P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", 
	RFC1035, November 1987.

Identifier uniqueness considerations:
	
	Uniqueness is guaranteed as long as the assigned
	string is never reassigned for a given FQDN, and that the FQDN
	is never reassigned.	
	
	N.B.:  operationally, there is nothing that prevents a domain
	name from being reassigned;  indeed, it is not an uncommon 
	occurrence.  This is one of the reasons that this example
	makes a poor URN namespace in practice, and is therefore not
	seriously being proposed as it stands.

Identifier persistence considerations:

	Persistence of identifiers is dependent upon suitable
	delegation of resolution at the level of "FQDN"s, and persistence
	of FQDN assignment...
	
	Same note as above.

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:<assigned number>:thinkingcat.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:

	FQDNs are case-insensitive.  Thus, the portion of the URN

		urn:<assigned number>:<FQDN>:

	is case-insenstive for matches.  The remainder of the identifier
	must be considered case-sensitve.

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

[IANA-CONSIDERATIONS] H. Alvestrand and T. Narten, "Guidelines for
    Writing an IANA Considerations Section in RFCs", 
    draft-iesg-iana-considerations-04.txt.

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

[NAPTR-REG] M. Mealling, "Assignment Procedures for the URI Resolution 
    using DNS (RFC2168)", draft-ietf-urn-net-procedures-00.txt.

[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]

From: Keith Moore <[email-masked]>
To: Maurizio Codogno <[email-masked]>
cc: [email-masked], [email-masked]
Subject: [URN] Re: persistence (was: the "ietf" namespace and internet-drafts) 
Date: Thu, 02 Jul 1998 17:29:16 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> > The more I think about it, the more I'm convinced that if there's 
> > going to be an IETF namespace, the names within that namespace
> > shouldn't reflect RFC numbers or STD numbers or ID names or anything
> > else.  They should consist entirely of serial numbers and/or dates.
> > Any approach that tries to use the existing names sets a misleading
> > example.
> > 
> > e.g. URN:ietf:23408 might correspond to RFC 822, and
> >      URN:ietf:28934 might correspond to STD 11
> > 
> > (no, they're not the same thing)
> 
> I understand some reason for this chioce, but there is something
> which escapes me. 
> 
> When (if?) STD 11 will be updated, will URN:ietf:28934 point to the new
> document, or not? With URN:ietf:std:11 the answer is of course "yes", and
> it makes sense to me. Here I am not sure about it...
> 
> (probably my idea of "persistence" is dead wrong!)

I should point out that my proposal was only half serious.

One of the primary goals of URNs is the ability to "grandfather"
in other naming systems, and grandfathering "rfc" and "std" series is
consistent with this goal.  

My concern is that, if "ietf" is the first example of a URN 
namespace, people will think that URNs work like the "ietf" URN, 
which in fact the IETF case is atypical.

(I just realized today another reason why "ietf" is a poor example -
the namespace ID should not be associated with the organization that 
owns the documents. What happens when the organization changes names,
or gets bought out by another organization?)  

The DOI folks got one thing right: they're using numbers for 
everything.  It solves a lot of the problems with long-term persistence.

To answer your question, though:  If URN:ietf:28934 were originally
defined to be associted with STD 11, then it should always be associated
with the current version of STD 11.  Yes, URN:ietf:std11 would work as well.

Keith

From: <[email-masked]>
Date: Thu,  2 Jul 1998 16:49:20 -0400 (EDT)
To: "Larry Masinter" <[email-masked]>
Cc: "Leslie Daigle" <[email-masked]>, <[email-masked]>
Subject: RE: [URN] URN required reading & a modest proposal
Sender: [email-masked]
Reply-To: <[email-masked]>

Larry Masinter writes:
 > My long message must have gotten in the way of making the key
 > point clearly enough:
 > 
 > FOR NOW:   Forget "hierarchical URNs", and disallow "/" in URNs.
 > THE ISSUE: What is the 'base' for resources that contain relative
 > references?

I was about to offer my congratulations for having convinced Leslie
and others of what I was trying for years to convey.    But I guess I
was mistaken too. :-)

 > This is a technical issue with (non-hierarchical) URNs; without
 > a clear approach for determining the 'base' to be used, URNs
 > will be unreliable when applied to most of the current web's content.

There is a clear approach already defined, and it works as I described
in mail over a year ago.  I'll repeat below.

 > This issue is not addressed by RFC 2169 or RFC 2168, or mentioned
 > by RFC 2276.

You are right that it is not described in those documents, but I don't
think it needs to be, assuming URNs are URIs.

It is described in the Relative URLs document, RFC 1808.

  3.3.  Base URL from the Retrieval URL

   If no base URL is embedded and the document is not encapsulated
   within some other entity (e.g., the top level of a composite entity),
   then, if a URL was used to retrieve the base document, that URL shall
   be considered the base URL.  Note that if the retrieval was the
   result of a redirected request, the last URL used (i.e., that which
   resulted in the actual retrieval of the document) is the base URL.

So if a URN is redirected to a URL, then the URL is used as the base,
not the URN.

For the N2R function, presummably there is no intermediate URL that the
clients sees directly, so this is what people are worrying about.  But if
there *is* an intermediate URL, even if the client doesn't know about it
when the N2R function is invoked, the client should be informed of the
correct base to use.

All this avoids the issue of URNs for hierarchical name spaces.
I won't get into that now, although I have some things to say about it,
of course.

BTW, I haven't exactly bowed out.  I just do not have time to argue any
more unless I have a chance of being heard.

dan

Date: Wed, 1 Jul 1998 11:08:22 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Larry Masinter <[email-masked]>
cc: [email-masked]
Subject: RE: [URN] URN required reading & a modest proposal
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Larry,

I do have some further comments on this thread, from the perspective of
my own technical opinion (i.e., not wg chair).

Essentially, I think we've got the problem to the point where we either:

	. think we understand enough of the ramifications to plunge ahead
	  with a technical solution that, if properly deployed, will
	  meet the needs, or

	. stick to the original plan, and avoid hierarchical URNs for now,
	  so that we can solve a known subset of the whole space, as well
	  as we know how.

Personally, I think the IETF has experience with "thinking we understood
the problem well enough to solve it", only to discover that there were 
large gaps in practical deployment understanding.  There is pressure to
accommodate hierarchical references 'because they are already there'.  Is
the cost of ignoring that "market pressure" greater than the danger of
enabling before infrastructure is understood/deployed?  My personal feeling
is that it is _not_.

On Wed, 1 Jul 1998, Larry Masinter wrote:
> But when persistent identifiers (URNs) are employed, the context of documents
> so referenced may have to be determined in other ways; most likely,
> by associating metadata with the document. So just as the product review
> should not be separated from the author and date of creation, having the
> 'base' be part of the metadata of the document would be an appropriate
> way to make sure that relative references don't become separated from the
> base against which they can apply.

So, I argue, this may be true in principle, but for URNs to be successful,
we need to see what happens in practice.  In practice, today, there is
very little accessible/regularly used metadata on the net.

> I think MHTML has provided some answers, too, for the cases where
> more extensive rewriting is necessary. In MHTML, a
> document migrates from its original home on some web server to an
> embedded piece of content; within MHTML structures, relative references
> are resolved against the base supplied with the enclosure, and then
> those references are potentially matched and rewritten by context

Or potentially XML, or anyone of a number of mechanisms -- but there is
no currently-implemented standard (i.e., common) practice.  Lots of things
that _could_ be done, but very few that _are_.

> This is not true! There are many ways of associating a base with
> a document, communicated by a variety of different means. As I mentioned,
> MHTML supplies one. 

Again, plenty of things that _could_ be done...

> Clearly for documents accessed through URN resolution,
> the base for relative references should be either taken from  the actual
> location of the document, (not the "URI used to originally access it"),
> or through content-base, etc.

This would require a change to the URI syntax document, because it's not
how it currently reads.

> > Note that the embedded references are likely created by the document
> > author/responsible person.  URNs, by contrast, will be assigned by
> > a variety of independent organizations, which have their own requirements
> > for name structure.
> 
> But the assignment of names in the library community is not an isolated
> event, but rather is coupled with the assignment of additional metadata
> as well. A work isn't named and given a call number without also identifying
> the author, date, title, publisher, publisher's address, and other bits of
> information that are necessary to interpret relative references within it.

In principle, this is true.  In pracitice, we're already seeing much
more quick-and-dirty name assignment happening.    Libraries (like hte
Swedish library) are assigning names to things which do not lie within
their repositories; the concept of publisher, etc, is quite nebulous, 
and the ability to ascertain an appropriate base URI is questionable.

> Any assignment of a name to a resource that contains relative
> references should be accompanied by an indication of the base for the
> resolution of those relative references. If the base is the 'location',
> then that base needs to be communicated back as part of N2R resolution.

Again, I have no disagreement with this in principle.  My argument is
that the likelihood of it being implementable in practice is somewhat low.
Without inherent embeddding of base URIs within document structures, 
there are few mechanisms for a URN-assigner to ascertain the appropriate
base URI.  And, even if one is asserted at the time of assigning the URN,
the URI may well change (particularly if it is a URL) over the course of the
lifetime of the resrouce, and we're back to square one with non-persistent
URIs.

> But URNs won't work if 'slapped on' to existing resources that contain
> relative references. As you say, the references are there, and there
> is a desire to name them in a location-independent way. So you need
> _some_ way to associate a base. Once you have that, you might use that

Well, URNs will be (whether we like it or not) slapped on.  If URNs do not
support hierarchy, we at least know that the relative references do not
apply to them, or cannot be used.  If URNs do, at some level, support 
hierarchy, we can't distinguish why resolution fails (i.e., because hte
URN used was not intended as the base for those references, or some other
failure?).

> when a URN names a resource which has them. Keeping URNs from having
> hierarchical structure might be a way of making sure those relative
> references are _broken_, but it's hardly good design.

I argue it's not a way to break them, so much as be able to know what state
you are in -- cannot resolve because no appropriate base URI has been
supplied.  Good design is not simply trying to handle every possible
eventuality -- it's being able to assert what state you are in, in order
to be able to posit strategies for getting out of it.

> then you have to decide how they are to be processed! I suggest merely
> that N2R be modified to always carefully supply a 'base', and that
> the control of the 'base' for N2R resolution be in the hands of the
> namespace, and not in the hands of the resource reached.

And I argue that this is not currently likely in practice.  And, I'm
not sure I see how the namespace can properly be expected to control 
all the results of N2R resolution.  It's the publisher of the resource
that has control over that, and the publisher is pretty close to the
resource reached.

Leslie.

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

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

Date: Thu, 2 Jul 1998 14:39:02 +0200 (MET DST)
From: Maurizio Codogno <[email-masked]>
Subject: [URN] persistence (was: the "ietf" namespace and internet-drafts)
To: [email-masked]
Content-MD5: qfki2kMJlLKvVUNLszH+ww==
Sender: [email-masked]
Reply-To: Maurizio Codogno <[email-masked]>

Keith writes in <[email-masked]>:

> The more I think about it, the more I'm convinced that if there's 
> going to be an IETF namespace, the names within that namespace
> shouldn't reflect RFC numbers or STD numbers or ID names or anything
> else.  They should consist entirely of serial numbers and/or dates.
> Any approach that tries to use the existing names sets a misleading
> example.
> 
> e.g. URN:ietf:23408 might correspond to RFC 822, and
>      URN:ietf:28934 might correspond to STD 11
> 
> (no, they're not the same thing)

I understand some reason for this chioce, but there is something
which escapes me. 

When (if?) STD 11 will be updated, will URN:ietf:28934 point to the new
document, or not? With URN:ietf:std:11 the answer is of course "yes", and
it makes sense to me. Here I am not sure about it...

(probably my idea of "persistence" is dead wrong!)

ciao, .mau.

From: Keith Moore <[email-masked]>
To: "Larry Masinter" <[email-masked]>
cc: "Leslie Daigle" <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: URN required reading & a modest proposal 
Date: Thu, 02 Jul 1998 08:35:32 -0400
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> PROPOSAL:  the processing of relative forms against the base is
> _entirely_ syntactic, and occurs BEFORE any attempt at resolution.

This doesn't work unless you somehow wire the base URI to the document.
If there can be more than one base, there will inevitably be conflicts
between the meanings of names relative to that base, just like there
are conflicts when a HTML file with relative links can be accessed
by multiple URLs, but not all servers share the same storage organization.
We don't want URNs to inhernt the problems associated with using relative
forms with URLs.

Using the document's URN for the base URI doesn't work at all, because
there can be more than one URN for a document, and there is no
"distinguished URN".  If you have a distinguished URN to be used as
the base, you're back to needing to do a resolution step (to get
the distinguished URN) before you evaluate the relative form.

And as far as I know there is currently exactly one file format
that lets you wire the BASE into the document.  (okay, maybe two --
I haven't looked to see whether XML does this)

What do relative forms provide for URNs other than a crude compression 
scheme?   If you want compression, gzip is a lot more efficient.

Keith

Date: Wed, 1 Jul 1998 14:36:42 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Larry Masinter <[email-masked]>
cc: [email-masked]
Subject: RE: [URN] URN required reading & a modest proposal
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Wed, 1 Jul 1998, Larry Masinter wrote:
> 
> My long message must have gotten in the way of making the key
> point clearly enough:

I'm sorry -- I evidently missed the transition (?) from when you were
proposing the mechanics of how hierarchical references could be 
syntactically implemented in URNs now to the point where you're saying
we shouldn't and the issue isn't there.  I may yet be missing your
point, and for that I apologize, but:

> FOR NOW:   Forget "hierarchical URNs", and disallow "/" in URNs.
> THE ISSUE: What is the 'base' for resources that contain relative
> references?
>     
> This is a technical issue with (non-hierarchical) URNs; without
> a clear approach for determining the 'base' to be used, URNs
> will be unreliable when applied to most of the current web's content.
> 
> This issue is not addressed by RFC 2169 or RFC 2168, or mentioned
> by RFC 2276.

RFC2168:  NAPTR
	This is about resolution server discovery, and I think it 
	would help if you could provide a more concrete idea of what
	should be done at this level for supporting base elucidation -- I
	don't see it.

RFC2276:  Architectural principles
	Again, a much higher-level document than should deal with
	expression of calculation of "base".  If you have a concrete
	suggestion of how it fits into the document, please forward it.

RFC2169:  Trivial HTTP
	This is not expected to be anything other than an experimental,
	non-definitive protocol.  It is meant to provide an implementation
	of the services outlined in the services document.  You've already
	proposed a change to teh N2R service, and that deserves a separate
	discussion (is your suggestion in line with the intention of that
	particular service, etc).

I don't see where elucidation of base is a URN-specific problem; it is
true that the problem is more acute when attempting to provide persistent
identification, but I've been told that URNs are not unique in that regard.

The real place to solve that problem is in the _URI_ documentation, so
that bases are appropriately defined/communicated for all URIs.  In a 
separate forum, I and others have offered all the concrete text I can think of 
to firm up that part of the document in question; if you have more concrete 
suggestions there, the whole of the URI-using population would be well-served.

Leslie.

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

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: "Larry Masinter" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] URN required reading & a modest proposal
Date: Wed, 1 Jul 1998 08:43:44 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

My long message must have gotten in the way of making the key
point clearly enough:

FOR NOW:   Forget "hierarchical URNs", and disallow "/" in URNs.
THE ISSUE: What is the 'base' for resources that contain relative
references?
    
This is a technical issue with (non-hierarchical) URNs; without
a clear approach for determining the 'base' to be used, URNs
will be unreliable when applied to most of the current web's content.

This issue is not addressed by RFC 2169 or RFC 2168, or mentioned
by RFC 2276.

Once this issue has been dealt with, then it will be possible to
revisit the question of whether hierarchy in URNs can be robust.

Regards,

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

Date: Wed, 1 Jul 1998 10:28:26 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Larry Masinter <[email-masked]>
cc: [email-masked]
Subject: [URN] input on the question
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Larry,

Well, I think you have succeeded in putting together the most detailed,
mechanical presentation of integrating hierarchical fragment references
with the proposed URN system.  I think our only disagreement is in timing --
whether to wait for the appropriate infrastructure to be in place (e.g.,
use of mhtml), or address an existing issue (relative references).

At this point, it involves a judgment call, and I think it's valid to
reassess the state of the whole WG's thinking:  Should we
	
	. enable (URI-based) hierarchical URNs now, while mechanisms _exist_
	  to communicate base URI but are not necessarily widely
	  deployed.  Failure could mean URNs become just another URI
	  scheme that fails to address requirements of reliable resource
	  identification.

	. wait until base-bearing mechanisms are more widely deployed and
	  overt use of hierarchy in URNs is better understood (by virtue
	  of URNs being better understood through deployment experience).
	  This should also expose the reality of the ability to "consciously"
	  assign URNs only with attendant base URI appropriately set.
	  Failure here could mean irrelevance of URNs because of the
	  number of resources that contain relative references already.

To allow hierarchy requires a change of the URN syntax -- allowing "/" 
characters, and, unless the URI syntax document is changed, allowing "urn://".
This will also entail convincing the ADs that we know enough of what we
are doing to make this an advisable change.

So, input on the above question, please.  

Leslie.

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

    "The nice thing about reality                 Leslie Daigle
       is that there are        
     so many versions to choose from."            Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: "Larry Masinter" <[email-masked]>
To: "Leslie Daigle" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] URN required reading & a modest proposal
Date: Wed, 1 Jul 1998 00:14:45 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

> However, this still overlooks at least one fundamental issue which undermines
> persistence in the use of identifiers: the separation of a  relative reference
> from its base.

I agree that this is a central issue for robust URNs, although it has
almost nothing to do with the syntactic form of URNs.

Almost all human communication requires some context for it to be understood.
If you saw a product review at "urn:reviews:1234" that said:

   "I thought that it was too expensive and didn't work very well."

you wouldn't be able to interpret that, unless you knew about the context
of the "I" (who said it), and the "it" (what product?!). In URL-space,
these contectual elements are often provided by the context of access;
the host that you get it from, the path that leads up to it. If you land,
by chance, on some page using Alta Vista, you can climb up the URL space
to figure out the context.

But when persistent identifiers (URNs) are employed, the context of documents
so referenced may have to be determined in other ways; most likely,
by associating metadata with the document. So just as the product review
should not be separated from the author and date of creation, having the
'base' be part of the metadata of the document would be an appropriate
way to make sure that relative references don't become separated from the
base against which they can apply.

I think MHTML has provided some answers, too, for the cases where
more extensive rewriting is necessary. In MHTML, a
document migrates from its original home on some web server to an
embedded piece of content; within MHTML structures, relative references
are resolved against the base supplied with the enclosure, and then
those references are potentially matched and rewritten by context
that is supplied with the document itself. It would make sense for
N2R to return a 'multipart/related' which contains the resource and
its related embedded material, rather than merely the resource itself.

> > Under this view, the validity of the hierarchical nature of URNs,
> > and the utility of relative forms against a URN base, are independent
> > of the mechanisms and architectural principles of  RESOLUTION,
> > since the syntactic processing happens before resolution is attempted.
>
> To do this requires both the base and the relative fragment, and
> the only mechanisms we currently have for communicating that base are
> (at least currently), dependent on the resolution process (e.g.: "use
> the URI used to access the resource").

This is not true! There are many ways of associating a base with
a document, communicated by a variety of different means. As I mentioned,
MHTML supplies one. Clearly for documents accessed through URN resolution,
the base for relative references should be either taken from  the actual
location of the document, (not the "URI used to originally access it"),
or through content-base, etc.

> 	. you do an N2R resolution and get a resource, which
> 	  contains relative references
> 	. you then want to resolve the relative references which,
> 	  and unless a specific base is delivered, the URI syntax
> 	  document says "default to the URI used to get here" -- i.e.,
> 	  the URN.

Clearly this points out that N2R resolution needs to return a usable
content-base. Otherwise, you are _disallowing_ resources obtained from
N2R to have relative references at all!

> If URNs do not support hierarchy, then you have a URI scheme that
> is not appropriate for the syntactic manipulation, and you have a problem.

I agree that you have a problem whether or not URNs support hierarchy,
as long as you want to name resources that contain relative pointers.

> If URNs _do_ support hierarchy in the general way, then:
>
> 	. _all_ URN references to this document must be formed on
> 	  the same hierarchy as the relative references, or else
> 	  the URNs formed after the syntactic manipulation will simply
> 	  be wrong.  And, there's no (known) way of distinguishing
> 	  between a URN that accepts the document's embedded hierarchy
> 	  and those that do not.

This doesn't make sense to me. Relative references must be resolved
against the applicable 'base'. URN references used to denote a document
may be completely inappropriate as the base for references within
the document.

That is why, whether you use multipart/related or some other structure,
it is important for the URN to reference not the 'resource itself',
but rather the 'resource with associated metadata', and to make sure
that the metadata covers the same kind of information that is
normally available when a resource is accessed via a URL rather
than a URN, including the identity of the authority, location, date,
etc. If "N2R" doesn't support this now, it would be good to fix it.
You need name-to-(resource+metadata).

> Note that the embedded references are likely created by the document
> author/responsible person.  URNs, by contrast, will be assigned by
> a variety of independent organizations, which have their own requirements
> for name structure.

But the assignment of names in the library community is not an isolated
event, but rather is coupled with the assignment of additional metadata
as well. A work isn't named and given a call number without also identifying
the author, date, title, publisher, publisher's address, and other bits of
information that are necessary to interpret relative references within it.

Any assignment of a name to a resource that contains relative
references should be accompanied by an indication of the base for the
resolution of those relative references. If the base is the 'location',
then that base needs to be communicated back as part of N2R resolution.

This is completely straightforward and required independent of the organization
of the name space and its hierarchy or lack thereof.

In _some_ circumstances, it will be appropriate to assign names to the
components of what originally was a hierarchy in a compatible hierarchical
fashion; in those circumstances, using hierarchical URNs, and allowing
the 'base' to be the base URN, makes sense. But this is the decision
of the naming authority that is assigning the URNs. There's certainly
no reason to disallow it. The requirement to supply a 'base' comes not from
the use of hierarchies in URN spaces at all, but from the desire to assign
permanent names to objects that contain relative references.

>                                 A single web page may validly
> have assigned to it URNs from both of these sources; the sources do
> not have the same hierarchical structure, nor are they in any way
> related to the structure of the relative references offered by the
> author.  Therefore, it is _not_ valid to assume that relative fragments
> will work with all these URIs for the same resource.

Exactly, this is why whenever you have a URN which names a resource
that contains relative fragments, it is necessary to have a mechanism
to determine the base. Even if it is a single URN. Even if the URN
is "urn:space:1". What is the base for relative references?

> Yeah; but I'll play an unusual card and point out that the reality
> is that the bulk of existing resources are web pages, and they already
> have relative references in them, with little or no formal declaration
> of base.
>
> We can write a BCP on when to use relative references and when not, but
> the reality is that people will slap URNs on existing resources, however
> they are formulated.

But URNs won't work if 'slapped on' to existing resources that contain
relative references. As you say, the references are there, and there
is a desire to name them in a location-independent way. So you need
_some_ way to associate a base. Once you have that, you might use that
mechanism to associate a base that happens to be a URN, in the case
where the URN space matches the hierarchy of the original URL space,
but that's a URN-space-designer choice.

I think we've uncovered an element that should have been addressed
in RFC 2276 and wasn't, which is the handling of relative references
when a URN names a resource which has them. Keeping URNs from having
hierarchical structure might be a way of making sure those relative
references are _broken_, but it's hardly good design.

> > >  Keith asked whether or not it is worth casting into
> > > question URNs' ability to provide persistent references in order
> to support
> > > this case.  Anything I've seen suggests it comes back to point #1 --
> > > we don't yet understand well enough how to do these across _all_ URN
> > > namespaces.
> >
> > Perhaps by 'understand' you really mean 'accept'? Syntactic preprocessing
> > is certainly 'understandable', isn't it? It's really a matter of whether
> > you accept it as a viable way of dealing with relative processing.
>
> No, I mean understand, as in understand and address all the very real
> ramifications.  Your proposal is indeed easily understood, and
> technically straightforward.  But, it's like an extended warranty
> on a new car:  what's important is not the long list of things it
> will cover, so much as the very significant bits that are not.

I think the crux of the matter is that relative references are in the
very documents you want to name, and that you can't eliminate them.
Since they're there, if you want to name them with persistent identifiers,
then you have to decide how they are to be processed! I suggest merely
that N2R be modified to always carefully supply a 'base', and that
the control of the 'base' for N2R resolution be in the hands of the
namespace, and not in the hands of the resource reached.

With that structure in place, you're set up to allow URNs to have
a hierarchy if it is useful, and to not require it if it is not.

> But you haven't addressed (accepted?) the deployment issues outlined
> above.  And, at least the last time I checked, this group was still
> concerned with anticipating deployment and scaling issues.

I agree that these are important issues to be worked out, and I hope
that I've noted the primary implementation issue that is required,
with or without hierarchical URN name spaces.

> I have every faith that HFIs will address many problems.  And, if _that_
> work can address the kinds of problems that will be encountered in
> real usage terms, then it will be appropriate to update RFC2168
> with the appropriate terminology.   But, to change the syntax in
> anticipation of the successful outcome is, to my way of thinking, like
> saying "let's load the gun and figure out how to aim later".

I hope you agree that the problem is not with the syntax of URNs,
but rather the technical and deployment issue of trying to use
URNs with resources that contain relative references. The
proposal that N2R must supply a base (which overrides
any other base supplied with or by the resource itself) is a good
first step, although in general I believe that more is required.

Larry