[URN] The WG is putative no longer...

Leslie Daigle <leslie@bunyip.com> Fri, 04 October 1996 15:10 UTC

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18220 for urn-ietf-out; Fri, 4 Oct 1996 11:10:05 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18215 for <urn-ietf@services.bunyip.com>; Fri, 4 Oct 1996 11:10:01 -0400
Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20916 (mail destined for urn-ietf@services.bunyip.com); Fri, 4 Oct 96 11:09:59 -0400
From: Leslie Daigle <leslie@bunyip.com>
Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id LAA00559 for urn-ietf@bunyip.com; Fri, 4 Oct 1996 11:09:59 -0400
Date: Fri, 04 Oct 1996 11:09:59 -0400
Message-Id: <199610041509.LAA00559@beethoven.bunyip.com>
To: urn-ietf@bunyip.com
Subject: [URN] The WG is putative no longer...
Sender: owner-urn-ietf@services.bunyip.com
Precedence: bulk
Reply-To: Leslie Daigle <leslie@bunyip.com>
Errors-To: owner-urn-ietf@bunyip.com

Well, the rate of subscription to the mailing list has dropped off, so it
seems like a good time to get the ball rolling under our new _official_
guise as the IETF URN Working Group.  I've attached the announcement in
case anyone missed it -- it includes our official charter. (I will also
be updating the web page, http://www.bunyip.com/research/ietf/urn-ietf/,
just as soon as I get a few minutes to swap in the scanty shreds of basic
HTML that I know...).

After the Montreal BOF, the draft WG charter was submitted for consideration
by the Area Directors, and refinements (per the usual criteria of 
achievability and viability) followed.  The resultant charter holds the
spirit of what was in the Montreal BOF, but has the further benefit of
addressing a few issues raised by the IESG.  [Hey, I wasn't _at_ the
discussions, I can blissfully assume it was only a few  :-)  ]

To recap briefly, what we have on the table is an abstract framework, or
architecture, for URN resolution.  It identifies basic system components 
and their responsibilities in the process, with a view to being able to
accommodate as many namespaces as possible, while applying the minimal
amount of interoperability infrastructure necessary to be able to call
these names "uniform".  

Separately, we also have one concrete proposal for one system that implements
this abstract architecture -- the NAPTR work.  This is a flagship implementation
to demonstrate that URNs can work _today_.   

Also, we have a separate paper that was prepared independently of the above
work, which provides some important considerations for any system attempting
to do URN resolution -- some of which have already been discussed (at the
BOF, on this list, etc).

The purpose of this working group, then, is to refine the description of
the abstract framework, see one system specified (NAPTR), and enough component
pieces to demonstrate the concept.  

To that end, there are 3 documents that need to be revised/created nownow:

	. The framework document.  This document needs to be fleshed
	  out.

	. The NAPTR document.  Ron promises another draft real soon.

	. The syntax document.  Any volunteers to write up what should be
	  a very short document outlining the components of the URN syntax?

Anyone who wishes to volunteer, send me an e-mail.  


In general, the documents that we're chartered to write are as follows:


URN Framework document:

	Overview of the basic components necessary to support this approach
	to URN resolution/management.  In addition to sketching out the
	basic architecture, this includes descriptions of the minimal
	requirements of the components (including namespaces).


NAPTR proposal:

	A specific proposal for an implementation of the approach.


Syntax document:

	The URN syntax, so that we have agreement about what is opaque
	and what is not.  This should be a _real_ short document.


N2L/N2R/etc document:

	What gets returned upon reslution of URNs.


New Namespace document:

	While the Framework document lays out the requirements of namespaces,
	each namespace that will be used in URNs needs to be formally
	described in terms of how it meets the requirements, and how it
	is used in the URN space.

	The first step, then, is to present a sample new namespace (e.g.,
	"inet").
	

Grandfathered Namespace document:

	One of the goals of URNs is to be able to support existing 
	namespaces.  Thus, we need to demonstrate the feasibility by
	writing out the spec for including one such existing namespace
	in URN form.


While we get rolling on refinements of the system documents, it's worth
determining which new/old namespaces we'll address (and volunteers!).
 

That's pretty much it, and the layout of the work ahead...  Sound like a plan?

Cheers!
Leslie.



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


Uniform Resource Names (urn)
----------------------------
 
 Chair(s):
     Leslie Daigle <leslie@bunyip.com>
     John Curran <jcurran@bbn.com>
 
 Applications Area Director(s): 
     Keith Moore  <moore+iesg@cs.utk.edu>
     Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>
 
 Area Advisor
     Harald Alvestrand  <Harald.T.Alvestrand@uninett.no>
 
 Mailing lists: 
     General Discussion:urn-ietf@bunyip.com
     To Subscribe:      majordomo@bunyip.com
         In Body:       In body of message: subscribe urn-ietf
     Archive:           ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive
 
Description of Working Group:
 
The goal of this working group is to define both a Uniform Resource
Name (URN) framework and an initial set of components that fit this
framework.

URNs are persistent identifiers for information resources.  The output
of this Working Group will comply with RFC 1737, which defines URNs and
gives requirements for them.  The framework will define the mechanics
for enabling global scope, persistence, and legacy support requirements
of URNs; requirements for namespaces to support this structure will
also be defined.   Although the framework will allow URNs to be defined
that vary in terms of degree of scalability and persistance, ensuring
"user friendliness" of all resultant identifiers is beyond the scope of
this group.

This WG will define the framework for URNs, at least one resolution
registry system, and at least one namespace.  RFCs describing
additional material will also be developed (per the milestones,
below).

Input documents: 

 o A Framework for the Assignment and Resolution of Uniform Resource
   Names <draft-daigle-urnframework-00.txt>

 o Resolution of Uniform Resource Identifiers using the Domain Name
   System <draft-daniel-naptr-01.txt>

 o Requirements for URN Resolution Systems
   <draft-girod-urn-res-require-00.txt>

 
 Goals and Milestones: 
 
   Oct 96       Submit revision of URN Framework document as Internet-Draft.   

   Oct 96       Submit revised version of the NAPTR proposal as an 
                Internet-Draft.                                                

   Oct 96       Submit Syntax document as an Internet-Draft.                   

   Oct 96       Submit document detailing the N2L/N2R/etc resolution results as
                an Internet-Draft.                                             

   Nov 96       Submit document describing one (new) namespace as an 
                Internet-Draft.                                                

   Dec 96       Submit paper outlining grandfathering one namespace into the 
                framework as an Internet-Draft.                                

   Dec 96       Submit revised N2L/N2R/etc document as an Internet-Draft.      

   Dec 96       Submit NAPTR proposal to IESG as Experimental RFC.             
                Submit Framework document to IESG for publication as an RFC.   
                Submit syntax paper to IESG for publication as an RFC.         

   Feb 97       Submit revised new Namespace document as Internet-Draft.       

   Feb 97       Submit revised grandfather namespace document as 
                Internet-Draft.                                                

   Feb 97       Submit N2L/N2R/etc document to IESG for publication as RFC.    

   Mar 97       Submit grandfathered namespace paper to IESG for publication as
                RFC.                                                           
                Submit new namespace proposal to IESG for publication as RFC.  




-- 

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

                                                      Leslie Daigle
   "Learn and live."                                  Vice President, Research
                                                      Bunyip Information Systems
                          -- ThinkingCat              (514) 875-8611
                                                      leslie@bunyip.com
------------------------------------------------------------------------------


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

                                                      Leslie Daigle
   "Learn and live."                                  Vice President, Research
                                                      Bunyip Information Systems
                          -- ThinkingCat              (514) 875-8611
                                                      leslie@bunyip.com
------------------------------------------------------------------------------