Editor's note:  These minutes have not been edited.
 

                   Minutes of the URN Working Group
                 37th IETF, San Jose, December 12, 1996

Group Co-Chairs: Leslie Daigle, leslie@bunyip.com
                 John Curran, jcurran@bbn.com

Minute-Meister:  Sally Hambridge,  Intel 

Leslie opened the meeting by reviewing the Charter and Milestones.  
Hot Spots in the milestones are: we lack a draft detailing 
N2L/N2R/etc resolution results.  We will probably use Ron Daniel's HTTP 
conventions draft as a start on this milestone.  We also need to 
submit a document describing one new namespace and a document 
which describes grandfathering in older naming schemes, as well 
as the Frameworks and Requirements draft.

Karen Sollins presented the open issues with the current 
Frameworks and Requirements document:

The document discusses the assumptions of longevity, delegation, 
and independence.  The requirements fall in 3 major areas:  
Evolution, Usability, and Security.  The framework looks like 
this:

URN:<NID><NSS>
   |
   |
Global NID registry
  |        |
  |        |
  |     Private URN resolution service
UDS server
  |
  |
Private URN resolution service

Karen includes a definition section which defines Local 
Resolution service - what transforms URNs into access to 
resources; Hints - information that helps to access the 
information; UDS - URN Resolution Service Discovery Service - how 
to find the right URN resolution service; HFN - Human friendly 
names.

The Security area will discuss access control on hints; server 
authenticity; Server distribution (a countermeasure on denial of 
service attacks) and Privacy - the users from resolution services 
and for publishers for their clients and publications lists.

Issues:  
	- Encouragement of separation of URNs from semantics
	- Efficiency as a goal or a requirement is in several places 
	  (documents) which need to be aggregated.
	- Whether there is a useful distinction to be made between long-
	  term and short-term hints
	- Acceptance by potential providers of UDS services.

Karen asked what's missing from the list of issues:
Internationalization (i18n) should be covered one way or another.
Name space ID - needs to be in a document but probably not this 
document.

Ryan Moats presented the issues with the URN syntax ID:

URN: should this be optional.  Please see the later discussion on 
this for the consensus.  

NID syntax: Why not use numbers and "-".  No reason - Ryan will 
change the draft.  There was a suggestion for following the RFC 
for URLs on this, but it was pointed out that this document is 
currently undergoing a revision.  NID namespace will have case 
insensitivity and add %escaping.  The NSS may be case sensitive.

URN Character set adds/deletes: Add "%" to the allowed character 
set and add a list of characters NOT part of the set to the 
draft.

%escaping: Will be allowed for escaping of reserved characters in 
addition to characters outside the URN character set; and allow 
for %HH escaping to use either upper or lower case.
Where does a URN end? At the first non-URN character set 
character.

Equivalency: Are things the same when they point to the same 
resource?  (Equivalency of resources was deemed to be a 
rathole).    Leslie offered that a URN could point to a specific 
day's weather and another could refer to today's weather, and 
these were pointing to the same thing but were not equivalent.
ROUGH CONSENSUS was reached that ONLY lexical equivalency will be 
covered in the draft.  Each namespace may have its own rules. 

For the Human readability - MUST/SHOULD the following text is 
being substituted:
  Any namespace (existing or newly-devised) that is proposed as a 
  URN-namespace must be expressed in this syntax.  If names in 
  these namespaces contain characters other than those defined for 
  the URN character set they must be translated into canonical form 
  as discussed in section 2.2

Ron Daniel discussed the NAPTR draft.

	- There will be verbiage to state that records with unknown 
	  flags must be ignored.
	- The Pseudo-code will get a strong disclaimer.
	- "R" Flag for treating Regex as "Raw"
	- Don't do "E" flag for encrypting Raw fields.
	- Flag field reserves 0-9 for experimentation. ROUGH CONSENSUS was to 
	  allow people to create new flags however they want, but that if 
	  you see a flag you don't recognize you ignore it. Ron is going to 
	  revise the wording of the draft so that people may place any 
	  interpretation they want on the various fields as long as they 
	  define a flag for it.

There was a question of the references to other drafts, and John 
Curran said he would find out if the text RFC xxx could be 
written and if the RFC editor would insert the correct numbers.

This draft will be going as an Experimental RFC.  There was 
discussion about how the experimental status will effect DNS and 
the regex substitutions.  We need to be explicit.  We need to 
say how this doesn't overload DNS and how DNS security will help 
and where it won't.  Also, there will probably be more than one 
discover service in the future and we don't want this one to be 
"The Standard".  We need operational experience.  The requiring 
resolution problem is not part of this draft.  We will have one 
more revision on the mailing list, then this goes to 
Experimental.

HTTP Conventions: Ron took this one too.

We need a simple resolver for testing, the goal is not 
Standards track.  The goal is to use the conventions on encoding 
on requests and responses on http:

GET /uri-res/<server>/<uri> HTTP 1.0



Open Discussion:

URN:  There was a question of rough consensus on the problem of 
whether to require urn:.  The room seems to indicate that urn: 
should be required on any part of the urn that was shipped around 
the Internet.  Whether or not implementors would use urn: was 
left up to them for their own local products, but in transmission 
the urn: would be required.  The problem with urn: seems to be at 
the user interface and user services level.  Don't confuse human 
friendly names with internal representation.

Documents:
We need a URN dereferencing document to discuss the resolution 
service and the resolution system.  These need the syntax (which 
is close) and the system requirements needs the framework (which 
is also close.) 

Assign URN - needs everything! We need namespace requirements.  
Renato Iannella was volunteered to create a first draft of this
document.  We need to have one new namespace and we need to bring in 1 
existing namespace.  We need to pay some attention to potential 
lawsuit issue.  It is important for someone who has authority for 
the namespace to say how it works in URN.  The proposal is for 
these to be experimental.  Dun and Bradstreet is interested in 
working on this as soon as the syntax is ready.  Clifford Lynch 
said that the NISO bibliographic IDs could move en masse.

We can create a resolution system which can be used outside the 
URN space, but we need to make it work there first.

Charter directions:

* We need to get a grip on bringing in an existing namespace
* We need a new namespace scheme
* We need the Name space requirements document (to see whether 
DNS-based  namespace will or won't work, and if not, what we can
do about a generically-accessible namespace)
* We need to look at the process of creating new namespaces



-- 

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

  "_Be_                                           Leslie Daigle
             where  you                           Vice President, Research
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              leslie@bunyip.com
----------------------------------------------------------------------------