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>

From: "Larry Masinter" <[email-masked]>
To: "David G. Durand" <[email-masked]>, "Leslie Daigle" <[email-masked]>, "Martin J. Duerst" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [URN] WG last call -- namespace definition document
Date: Wed, 12 Aug 1998 14:04:21 PDT
Importance: Normal
Sender: [email-masked]
Reply-To: "Larry Masinter" <[email-masked]>

Now that we've managed to get the URI syntax document resolved,
I wonder if it would be useful to consider extending
draft-masinter-url-i18n to cover 'URN's would be, rather than having a
separate document for URN internationalization as for URLs.

Larry

Date: Wed, 12 Aug 1998 17:19:27 +0900
To: Leslie Daigle <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: [URN] WG last call -- namespace definition document
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

Hello Leslie,

At 09:39 98/08/05 -0400, Leslie Daigle wrote:

> On Wed, 5 Aug 1998, Martin J. Duerst wrote:

> > > 	Some examples include:
> > > 	
> > > 	. mappings between different character set encodings
> > 
> > I don't understand why this made it here. URNs are encoded
> > based on UTF-8, as specified in the syntax document. This
> > eliminates any problems here.
> 
> It may be better to find another example, but I do think this
> is not completely spurious.  URNs may be encoded in UTF-8, but
> this document is the bridge between (often existing) identifiers,
> their use, and their use in URNs.

In that case, the wording should be more precise, e.g.

. How exactly characters in legacy encodings that have been used
  with the identifiers that the namespace is used for are mapped
  to UTF-8 for use in URNs.

> So, while it is clear that the identifier should be encoded in UTF-8
> for the purpose of expressing it as a URN, it may be important for
> people writing software to handle these identifiers to know that
> the character "e-acute accent" in an iso-latin-1 encoded identifier
> is the same as "e" in an ascii one.

That's equivalence, not encoding, isn't it: It would not make sense
to say that e-acute in iso-8859-1 has to be mapped to "e" in UTF-8,
because that would mean that for each URN namespace,a separate
transcoding is needed. For a given namespace, it may be desirable
to say that the difference between e-acute and "e" is ignored,
but still the mapping would be from e-acute in iso-8859-1 would
be to e-acute in UTF-8, wouldn't it?

> It's been a while since I visited that part of the document; I'll
> try to come up with a clearer example.

Great! Looking forward to it.

> > > 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]).
> > 
> > This should be reworded. Because URNs are based on UTF-8,
> > the chance that something has a more "generous" character set
> > are extremely small. What should be asked for (not necessarily
> > in a "syntax conformance" section, but maybe in a "character encoding"
> > section) is information that disambiguates mappings between the
> > identifiers as conventionally used (e.g. in print) and Unicode/ISO 10646.
> > An example would be whether the apostrophe (U+27) or the backwards
apostrophe
> > (U+60) should be used for something that looks similar to these in print.
> 
> I would actually direct this level of detail to other documents that
> are presumably being handled within the IETF or elsewhere -- i.e., there
> need to be standard ways of handling this across all applications, not just
> for URNs.

Sorry, but this is just impossible. Mappings between different encodings
could be standardized by the IETF in cases where they are not already
obvious (as e.g. for iso-8895-1). Behaviour to deal with issues such as
the precomposed/decomposed alternatives again could (and in my oppinion
should) be specified as widely as possible.

On the other hand, trying to specify conversion from non-electronic
media (such as print and handwriting) to Unicode in a general way
that guarantees interoperability is just impossible.

> However, the "generousness" of the character sets is still relevant, because
> the URN syntax is conformant to the URI syntax, which means that certain
> characters (notably spaces) may need to be %-HEX-encoded.

If that's what's meant, then it would be worded more clearly. The fact
that space has to be encoded with %HH doesn't have to be mentionned
(although it won't hurt).

Regards,   Martin.

Date: Wed, 12 Aug 1998 16:33:41 +0900
To: Yves Arrouye <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: [URN] WG last call -- namespace definition document
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

At 09:22 98/08/06 -0700, Yves Arrouye wrote:

> The character set encoding problem may be eliminated, but depending on the
> namespace, one might be willing to consider lexically equivalent strings
> that compare according to the Unicode collation algorithm for example
> (Unicode TR #10 on <http://www.unicode.org>). So the strings %C3%8A (LATIN
> CAPITAL LETTER E WITH ACUTE, U+00C9) and E%CC%80 (LATIN CAPITAL E +
> COMBINING ACUTE ACCENT, U+0301) could be considered to equivalent though
> their UTF-8 encoding is not.

Yes, they indeed should, because the user is not supposed to see the
difference. But I doubt that it makes sense that each namespace
defines these equivalences again. It's a much broader problem,
which in particular also has been comming up in the work here at
W3C. Please see "Requirements for String Identity Matching and String
Indexing",  World Wide Web Consortium Working Draft 10-July-1998,
http://www.w3.org/TR/WD-charreq. Comments are highly apreciated.

>   And one could use secondary and tertiary differences to distinguish
> between case (see the IETF documents namespace example, where case doesn't
> matter) and to ignore differences in diacritics. Such comparisons could be
> different in different locales.

Making equivalences depend on the user's locale seems to be completely
against the requirements for URN namespaces.

Regards,   Martin.

Date: Wed, 12 Aug 1998 16:53:16 +0900
To: "David G. Durand" <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: [URN] WG last call -- namespace definition document
Cc: Leslie Daigle <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

At 15:20 98/08/05 -0700, David G. Durand wrote:

> There are also practical details about how UTF8 is being applied. For
> instance some URN spaces might differ on their preferred practice with
> respect to composed characters included for compatibility with older
> character encodings. Some might forbid the use of precomposed characters,
> some might require equivalence between the two renderings, some might
> forbid such equivalence. These are permissible options in how to apply
> Unicode, as I understand it.

I think to forbid equivalence would be against conformance clause C9
of the Unicode standard, which says that applications are not allowed
to assume that other applications honor the difference between the
two representations (the renderings on the screen should be exactly
the same anyway).

Saying that only one representation (e.g. only precomposed) may
be accepted in my view only makes sense if all of the WWW and
the Internet goes into the same direction (what I call Early
Normalization in "Requirements for String Identity Matching and
String Indexing",  World Wide Web Consortium Working Draft 10-July-1998,
http://www.w3.org/TR/WD-charreq).

> >> This should be reworded. Because URNs are based on UTF-8,
> >> the chance that something has a more "generous" character set
> >> are extremely small.
> 
> There are well known holes in Unicode with regards to writing systems that
> are obsolete and obscure. At least in some scholarly applications, this can
> be a real problem. Whether special URN schemes will come into use in these
> contexts is an open question, of course.  The private-use characters are
> one  mechanism for dealing with problems like this, and conventions for
> their application might be a legitimate part of a URN scheme, as might be
> particular transliteration conventions.

Please have a look at http://www.unicode.org/pending/pending.html,
in particular the bottom of that page. How many of the scripts
there do you know? That page also gives advice on how to contribute
if you see any holes not yet covered.

> >However, the "generousness" of the character sets is still relevant,
because
> >the URN syntax is conformant to the URI syntax, which means that certain
> >characters (notably spaces) may need to be %-HEX-encoded.
> 
> Also a good point, although I suspect that the treatment of syntactically
> special characters within the character set is at a different level than
> that of dealing with characters altogether outside that chracter set.

Semantically, it's at a different level. Syntactically, it's not.

As a consequence, you might e.g. define a scheme that uses "A" as
a special character, and can still use "A" as a data character.
The later would be escaped as %41, the former wouldn't.
(Actually, I have my doubts that the difference would be preserved by
all URI-handling programs, but at least it's possible to express it.)

However, it is not possible to use a scheme that e.g. uses PLUS-MINUS SIGN
(U+00B1) both as a special character and as a data character, because
you have to escape it, and there is only one escaping mechanism.

Regards,   Martin.

Date: Tue, 11 Aug 1998 13:22:21 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] updated status
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Attached is an updated version of the status document I circulated in
May.

The only changes are in terms of 

	. document status	
	. detail on the operational experience of PDI's

Leslie.

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

    If cats had bumper stickers:                  Leslie Daigle
                                             
      "I wake for food."                          Bunyip Information Systems
                -- ThinkingCat                    (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

============================================================
URN Status Report
============================================================
Leslie L. Daigle
IETF URN WG Co-Chair
August 11, 1998.

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

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

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

   URN Namespace Definition Mechanisms 
	In WG last call; should be put forward as RFC in early September.
	
   URI Resolution Services Necessary for URN Resolution 
	In WG last call; should be put forward as RFC in early September.

   A URN Namespace for IETF Documents 
      Work required:
	. final concordance with Namespace Definition Mechanisms
	  paper (if changes necessary)

   NAPTR Registration Procedures document
      Work required:
	. Revision to incorporate comments.

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

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

   Resolution of Uniform Resource Identifiers using the Domain Name System 
   (RFC2168)
      Status:  Experimental Protocol, have requested it be considered for 
		Standards track.
     
   A Trivial Convention for using HTTP in URN Resolution (RFC 2169) 
      Status:  Experiemental Protocol

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

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

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

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

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

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

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

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

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

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

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

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

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

Elsevier:
	10.1016/S1384107697000225  which is resolvable through

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

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

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

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

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

	urn:doi:10.1016/S1384107697000225 

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

Persistent Document Identifiers (PDIs)

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

to see the system in action.  For example, 

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

is resolved through the proxy:

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

This system is documented in:

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

and more detail is given below as regards operational experience.

W3 Identifier Resolution Extensions (WIRE)

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

See:

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

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

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

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

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

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

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

"The Persistent Document Identifier (PDI)"  John Mallery

The Persistent Document Identifier (PDI) namespace is currently
used in a production document publication application running
at http://www.pub.whitehouse.gov  The PDI scheme was originally
deployed in October 1994. The specification was updated during
Fall 1997 to conform with URN standards and an extensible
fragment syntax was added. In December, URN resolution servces
for I2R and I2C were deployed using THTTP at www.pub.whitehouse.gov 
and an appropriate NAPTR record was added for PDI.URN.NET
as well as the deployed document series, oma.eop.gov.us. Recently,
the November 1997 PDI specification has been revised in light of 
comments received from the URN WG, the URI WG, and W3C.

To date, over 10,000 PDIs have been assigned in the
oma.eop.gov.us document series. All documents distributed by this 
publication server carry a PDI. The documents are distributed over
SMTP, NNTP, and HTTP. Fragment references are supported
on these documents over THTTP. A java Web interface allows users 
to easily create fragment references by selecting regions in documents.

PDI have proved invaluable in managing this document set because 
protocol-specific URIs (URLs, message IDs) are insufficient to cover 
the range of maintenance issues arising from multi-protocol
distribution, wide mirroring, and archival requirements.

The emphasis in this application is on the I2R resolution method
because we need to avoid indefinite support for transient URIs,
specifically URLs.  We currently provide backward compatility for
over 16000 URLs (entity and headers) issued before HTTP access to 
the documents was limited exclusively to the I2R method.  In this 
application, we envision little or no need to N2I type services due to
the associated backward compatibility problem. Identifier
assignment services are not required here because they are
handled by the backend application. The application
should sometime provide I2N resolution to map old URLs
to their PDI and support fragment references via email interfaces.

In research applications at the MIT Artificial Intelligence Laboratory, 
our group is developing a portable URI resolver for use, among other things, 
in collaborative annotation and distributed knowledge representation.
We currently have one internal PDI document series and we
plan to establish an external series for seminars and publications
by the MIT Artificial Intelligence Laboratory.

An HTTP proxy server that supports collaborative annotation
is using PDIs to refer to web resources, links, and annotations.
External URIs are imported into the PDI namespace whenever an
annotation is created. Resources must be imported and assigned
a versioned PDI in order to guarantee correct operation of
fragment references (by enforcing a monotonic binding of
the identifier to the machine representation of the resource).
This collaborative proxy and the knowledge representation
applications would benefit significantly from the definition of
URI resolution services for assigning meta-data, URIs, and machine
representations to URNs. (We plan to co-opt the HTTP PUT method
in WIRE for this purpose.)

The resolver includes an code to parse, represent, and management
PDI namespaces.  The architecture is object-oriented and allows
users to specialize classes and methods to implement other complex
namespaces. We imagine, however, that the basic URN namespace code
will allow service for simple namespaces without additional code.
We are developing fragment resolution code for additional media
types (e.g., html, video). 

Once this resolver becomes sufficiently robust, 
we intend to make it available for FTP as part of a Common Lisp suite 
of Web tools (http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html). 
At that time, we will put up a web page to delegate document
series within the PDI namespace. The resolver contain code
for performing this delgation from the root PDI namespace and
from delegated document series so that all can answer RDS queries. 
Groups interested in using PDIs will be then able to obtain their own
document series and run the resolver. People interested in alpha or beta 
access to the code should contact John Mallery ([email-masked]).

Until web clients are able to resolve URNs based on URN standards, we
will rely on THTTP (and extensions to it). For this reason, it is
important that THTTP track URI resolution services closely. We expect
that the WIRE proposal can be honed to a point where we will see 
Web client awareness of URNs in the coming months. From the PDI
perspective, WIRE needs to handle the full suite of URI resolution
services and allow binding of identifiers as well.

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

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

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

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

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

Explanatory information is available from:

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

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

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

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

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

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

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

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

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

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

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

Some of this work is described in a conference paper:

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

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

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

[No info available]

Ron Daniel Jr., Ed Balas, LANL

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

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

Date: Tue, 11 Aug 1998 11:17:01 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] WG last call
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Okay, having checked with the authors, there are no known outstanding
agreed-upon changes to the URI resolution services document,

	draft-ietf-urn-resolution-services-06.txt

Bearing in mind that this is proposed to go to "experimental" track
as an RFC, I put it to the working group for last call before asking
the ADs to put it forward as an RFC.

If there are no major outstanding issues identified before August 25,
I will ask the ADs to put it forward.

Thanks,
Leslie.

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

    If cats had bumper stickers:                  Leslie Daigle
                                             
      "I wake for food."                          Bunyip Information Systems
                -- ThinkingCat                    (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

Date: Thu, 06 Aug 1998 09:22:47 -0700
Subject: Re: [URN] WG last call -- namespace definition document
From: "Yves Arrouye" <[email-masked]>
To: [email-masked]
Sender: [email-masked]
Reply-To: "Yves Arrouye" <[email-masked]>

>> >  Some examples include:
>> >  
>> >  . mappings between different character set encodings
>> 
>> I don't understand why this made it here. URNs are encoded
>> based on UTF-8, as specified in the syntax document. This
>> eliminates any problems here.
>It may be better to find another example, but I do think this
>is not completely spurious.  URNs may be encoded in UTF-8, but
>this document is the bridge between (often existing) identifiers,
>their use, and their use in URNs.
>
>So, while it is clear that the identifier should be encoded in UTF-8
>for the purpose of expressing it as a URN, it may be important for
>people writing software to handle these identifiers to know that
>the character "e-acute accent" in an iso-latin-1 encoded identifier
>is the same as "e" in an ascii one.

The character set encoding problem may be eliminated, but depending on the
namespace, one might be willing to consider lexically equivalent strings
that compare according to the Unicode collation algorithm for example
(Unicode TR #10 on <http://www.unicode.org>). So the strings %C3%8A (LATIN
CAPITAL LETTER E WITH ACUTE, U+00C9) and E%CC%80 (LATIN CAPITAL E +
COMBINING ACUTE ACCENT, U+0301) could be considered to equivalent though
their UTF-8 encoding is not.
  And one could use secondary and tertiary differences to distinguish
between case (see the IETF documents namespace example, where case doesn't
matter) and to ignore differences in diacritics. Such comparisons could be
different in different locales.

Yves.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-nid-req-05.txt
Date: Thu, 06 Aug 1998 09:28:25 -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		: URN Namespace Definition Mechanisms
	Author(s)	: P. Faltstrom, R. Iannella, L. Daigle, D. van Gulik
	Filename	: draft-ietf-urn-nid-req-05.txt
	Pages		: 9
	Date		: 05-Aug-98
	
The URN WG has defined a syntax for Uniform Resource Names
(URNs) [RFC2141], as well as some proposed mechanisms for their
resolution and use in Internet applications ([RFC2168, RFC2169]).
The whole rests on the concept of individual 'namespaces' within the
URN structure.  Apart from  proof-of-concept namespaces, the use
of existing identifiers in URNs has been discussed ([RFC2288]),
and this document lays out general definitions of and
mechanisms for establishing URN 'namespaces'.

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

Internet-Drafts directories are located at:

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

Internet-Drafts are also available by mail.

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 5 Aug 1998 15:20:37 -0700
To: Leslie Daigle <[email-masked]>, "Martin J. Duerst" <[email-masked]>
From: "David G. Durand" <[email-masked]>
Subject: Re: [URN] WG last call -- namespace definition document
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "David G. Durand" <[email-masked]>

At 1:39 PM -0000 8/5/98, Leslie Daigle wrote:
>> > 	Some examples include:
>> >
>> > 	. mappings between different character set encodings
>>
>> I don't understand why this made it here. URNs are encoded
>> based on UTF-8, as specified in the syntax document. This
>> eliminates any problems here.
>
>It may be better to find another example, but I do think this
>is not completely spurious.  URNs may be encoded in UTF-8, but
>this document is the bridge between (often existing) identifiers,
>their use, and their use in URNs.
>
>So, while it is clear that the identifier should be encoded in UTF-8
>for the purpose of expressing it as a URN, it may be important for
>people writing software to handle these identifiers to know that
>the character "e-acute accent" in an iso-latin-1 encoded identifier
>is the same as "e" in an ascii one.
>
>Okay, so it's a bit tenuous.    My point is that the issue it's
>trying to address is (I think) not the one you think it is.

There are also practical details about how UTF8 is being applied. For
instance some URN spaces might differ on their preferred practice with
respect to composed characters included for compatibility with older
character encodings. Some might forbid the use of precomposed characters,
some might require equivalence between the two renderings, some might
forbid such equivalence. These are permissible options in how to apply
Unicode, as I understand it.

>> This should be reworded. Because URNs are based on UTF-8,
>> the chance that something has a more "generous" character set
>> are extremely small.

There are well known holes in Unicode with regards to writing systems that
are obsolete and obscure. At least in some scholarly applications, this can
be a real problem. Whether special URN schemes will come into use in these
contexts is an open question, of course.  The private-use characters are
one  mechanism for dealing with problems like this, and conventions for
their application might be a legitimate part of a URN scheme, as might be
particular transliteration conventions.

>> What should be asked for (not necessarily
>> in a "syntax conformance" section, but maybe in a "character encoding"
>> section) is information that disambiguates mappings between the
>> identifiers as conventionally used (e.g. in print) and Unicode/ISO 10646.
>> An example would be whether the apostrophe (U+27) or the backwards
>>apostrophe
>> (U+60) should be used for something that looks similar to these in print.

>I would actually direct this level of detail to other documents that
>are presumably being handled within the IETF or elsewhere -- i.e., there
>need to be standard ways of handling this across all applications, not just
>for URNs.

Exactly right.

>However, the "generousness" of the character sets is still relevant, because
>the URN syntax is conformant to the URI syntax, which means that certain
>characters (notably spaces) may need to be %-HEX-encoded.

Also a good point, although I suspect that the treatment of syntactically
special characters within the character set is at a different level than
that of dealing with characters altogether outside that chracter set.

  -- David

_________________________________________
David Durand              [email-masked]  \  [email-masked]
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Date: Wed, 5 Aug 1998 09:39:07 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: "Martin J. Duerst" <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] WG last call -- namespace definition document
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Howdy,

On Wed, 5 Aug 1998, Martin J. Duerst wrote:
> > 2.0 What is a URN Namespace?
> 
> > 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,
> 
> Sounds a bit strange. Do ISBNs have needs?

Well, I think they do, but perhaps that's because I spend my life
thinking about these things too much...  Perhaps a clearer wording is:

"...is inherently dependent on the requirements of the community defining
the identifier,"

> > 	Some examples include:
> > 	
> > 	. mappings between different character set encodings
> 
> I don't understand why this made it here. URNs are encoded
> based on UTF-8, as specified in the syntax document. This
> eliminates any problems here.

It may be better to find another example, but I do think this
is not completely spurious.  URNs may be encoded in UTF-8, but
this document is the bridge between (often existing) identifiers,
their use, and their use in URNs.

So, while it is clear that the identifier should be encoded in UTF-8
for the purpose of expressing it as a URN, it may be important for
people writing software to handle these identifiers to know that
the character "e-acute accent" in an iso-latin-1 encoded identifier
is the same as "e" in an ascii one.

Okay, so it's a bit tenuous.    My point is that the issue it's
trying to address is (I think) not the one you think it is.

It's been a while since I visited that part of the document; I'll
try to come up with a clearer example.

> > 	. 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]).
> 
> This should be reworded. Because URNs are based on UTF-8,
> the chance that something has a more "generous" character set
> are extremely small. What should be asked for (not necessarily
> in a "syntax conformance" section, but maybe in a "character encoding"
> section) is information that disambiguates mappings between the
> identifiers as conventionally used (e.g. in print) and Unicode/ISO 10646.
> An example would be whether the apostrophe (U+27) or the backwards apostrophe
> (U+60) should be used for something that looks similar to these in print.

I would actually direct this level of detail to other documents that
are presumably being handled within the IETF or elsewhere -- i.e., there
need to be standard ways of handling this across all applications, not just
for URNs.

However, the "generousness" of the character sets is still relevant, because
the URN syntax is conformant to the URI syntax, which means that certain
characters (notably spaces) may need to be %-HEX-encoded.

Leslie.

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

    If cats had bumper stickers:                  Leslie Daigle
                                             
      "I wake for food."                          Bunyip Information Systems
                -- ThinkingCat                    (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

Date: Wed, 05 Aug 1998 13:59:41 +0900
To: Leslie Daigle <[email-masked]>
From: "Martin J. Duerst" <[email-masked]>
Subject: Re: [URN] WG last call -- namespace definition document
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

At 18:17 98/08/04 -0400, Leslie Daigle wrote:
> Howdy,
> 
> Attached is the updated version of the namepsace definition document that
> I have just sent to the I-D repository.  This version features one 
> change over the last one:
> 
> 	. added a named repository of URN namespace registration information
> 
> Additionally, I have been in touch with the IANA, and they say they
> can do what they believe we are asking them to do here.
> 
> So, since this document isn't changing, and there hasn't been much
discussion
> of it, I move it forward for working group last call -- if there are no
> significant changes requested/supported before August 21, I will send it to 
> the ADs for consideration as an RFC. 

>       URN Namespace Definition Mechanisms

> 2.0 What is a URN Namespace?

> 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,

Sounds a bit strange. Do ISBNs have needs?

> 3.0 URN Namespace Definition Template

> Information in the template is as follows:

> 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

I don't understand why this made it here. URNs are encoded
based on UTF-8, as specified in the syntax document. This
eliminates any problems here.

> 	. 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]).

This should be reworded. Because URNs are based on UTF-8,
the chance that something has a more "generous" character set
are extremely small. What should be asked for (not necessarily
in a "syntax conformance" section, but maybe in a "character encoding"
section) is information that disambiguates mappings between the
identifiers as conventionally used (e.g. in print) and Unicode/ISO 10646.
An example would be whether the apostrophe (U+27) or the backwards apostrophe
(U+60) should be used for something that looks similar to these in print.

Hope this helps.    Regards,   Martin.

Date: Tue, 4 Aug 1998 18:17:07 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] WG last call -- namespace definition document
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Howdy,

Attached is the updated version of the namepsace definition document that
I have just sent to the I-D repository.  This version features one 
change over the last one:

	. added a named repository of URN namespace registration information

Additionally, I have been in touch with the IANA, and they say they
can do what they believe we are asking them to do here.

So, since this document isn't changing, and there hasn't been much discussion
of it, I move it forward for working group last call -- if there are no
significant changes requested/supported before August 21, I will send it to 
the ADs for consideration as an RFC. 

Leslie.

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

    If cats had bumper stickers:                  Leslie Daigle
                                             
      "I wake for food."                          Bunyip Information Systems
                -- ThinkingCat                    (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

Internet Draft                               Leslie L. Daigle
August 4, 1998                               Bunyip Information Systems
draft-ietf-urn-nid-req-05.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.

URN namespace registrations will be posted in the anonymous FTP directory
"ftp://ftp.isi.edu/in-notes/iana/assignments/URN-namespaces/".

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]