The URN working group met to discuss "URNs in a practical world," with
the intent of talking about registration and standardization, NAPTR,
RFCs, PDIs and the possibility of wrapping up the working group.
There are several systems currently using URNs. There is a current
draft: draft-lyon-itp-nodes-02.txt, as well as FINBNs and
NISO ISDIs. The group agreed that these were "good" illustrations
of URNs since they seemed to be using names reasonably. The lyon
draft specifies the URN as the transaction ID but the common case
is to define its own transaction ID as the URN. This is not standard.
FINDBNs are used by the National Library of Finland. This is a naming
system for documents and a name space to fit with it. NISO ISDIs are digital
IDs for publications. Multicast is also interested in URNs for their work.
Registration and Standards Doc - this is a re-working of an earlier document.
It was re-focused at the Munich meeting and is now a set of mechanical
procedures for registering name spaces. The doc proposed 4 levels:
Experimental
Informal
Standard
Top-level
The idea has been copied in great part from the MIME media-types.
Experimental namespace IDs would be self-assigned; Informal would be easy
to get and contexts for use would be identifiable as short-term. It would
be a string ID based on OID/accession number. These would not be
legislated or enforced. The Standard NIDs would represent a small
number of namespaces for which the marketplace has decided success.
These would be built for real name space requirements and used in the
Internet context. These would require an RFC to document the space
and some entities will wish to document their requirements more closely
than others, but there should be enough documentation for resolution.
Both the name space and the name space ID are specificially registered.
For the Top-level (TL) the proposal is for a hierarchical structure
with the TL reserved allowing sub-delegation. A rough cut at the TL is
the RFC 1766 country codes. This allows a country to delegate the
NID as it sees fit. We need to make sure that the reserved characters
as stated in the syntax RFC are the only ones we need for this
hierarchical scheme. We had a discussion about setting aside a
particular structure for the TL name spaces. There was a question
about DNS impact, which was really a question about how flat the name
space is. We said that these are not volatile structures, but are
fairly static which could be cached and replicated. There was
some discussion about the structure and we noted that if we used
any characters other than A-Z, a-z, 0-9 and - we would be in violation
of our own syntax RFC.
Leslie expressed frustration over the fact that only one person had
commented on the draft on the mailing list, while the room seemed filled
with contentious opinion on the draft. She urged people strongly to
be sure to bring their thoughts up on the mailing list, where official
group discussion takes place.
The discussion about how to register name spaces fell down the
proverbial vanity name space well. The first part of the discussion
concentrated on the process. The suggestion was that the process
be analogous to mime-type registration a la RFC 2048. That is, all
NIDs would register with the IANA but Experimental types. Informal
would have and NID assigned. Standard and TL would require an
RFC-publication for documentation. There was then a discussion about
the problems with conflict and conflict resolution at the Informal
level. What if there were duplicates? The suggestion was that we
use OIDs and dashes not dots. Keith Moore claimed this was too complex,
that we need real NIDs with vetting and attainable ones, that they need
to be very lightweight and are assigned not requested. This would need a
lightweight process which is just number assignment. This position
is based on 2 things: the names have to fit the rules; and they have to
be unique. He argued for decoupling the assignment of IDs with
whether or not they go in registries -- what an entity does internally
doesn't matter. Other comments included: if they want to collaborate
and not clash they should use Informal NIDs. Very well known spaces should
use TLs and vetting. Standard and top-level may be combined. We might
go to Internal, Public and Private.
This led to the (sigh) discussion about vanity names. We need to reduce
the number to these to special standard ones. We may need to not use
OIDs and IANA hands out a 15 or 32 digit number (or alpha-numeric)
which would not prejudice any particular resolution scheme. However,
we need some motivation for going formal. We need implementation
experience with managing the name space. To take this discussion
back to the original examples used, ISBNs or SICI codes would be
standard; FINBNs would be a assigned by the Finnish TL. A Big
Corporation would use Informal; Social Security numbers would be
TL/country specific, and US social security numbers are Top-level
country. We had a contentious discussion which looked like Munich.
Keith suggested that we need to pick solutions which fit the URN
requirements. How should they be distinguishable in the RDS?
What is the impact and reliability of the level of service? How
is a lab different from being WWW accessible? All this needs to be
well documented and described.
Properties and characteristics of the namespace should all be changeable
so they should not be embedded in the name. Remember - who needs to
know and when do they need to know? Is 3 classes reasonable? Is
renaming reasonable? This is a registry issue and wrapping a
quality issue around it is probably a problem. We need to deal
(still!) with the vanity name spaces as a public process. Some
should be "very well documented" and not just assigned numbers.
We need to have some consensus here - is a structure allowed in NIDs?
The document assumed yes it is, but we really don't know.
Experimental may be noted but the structure is left to the name space
owner. With a registry we need to revisit the entire area, but we
shouldn't make assumptions. We actually have 2 design choices:
1) assign numbers with technical criteria
2) pick the hard choice (allow vanity spaces)
This discussion was refferred to te mailing list.
We then went over the documents which were mandated by our charter:
The Biblio IDs - show how grandfathering an existing space would work.
The architecture draft, as the working group chair reminded the AD
needs resolution. The IETF name space draft may be superceded
by PDIs. NAPTR needs a document to explain how to get a namespace
and how it gets resolution.
John Mallery gave a presentation on PDIs. The White House is using these
in conjunction with thttp to name documents and get resolution.
The most contentious issue was that they used the "|" and this was
not on the list of OK characters. Ryan suggested using "$". Check
the draft for all relevant info, including the BNF.
draft-mallery-urn-pdi-00.txt.
PDI may take the place of ietf as a new namespace showcase example.
PDI needs to coordinate with the http extensions group.
Clearly, we're not wrapped up yet, although the Chair expressed the
hope and expectation that fruitful work on the mailing list could yield
the necessary remaining components before the next IETF meeting.
