[URN] re urn-nid-02

[Terry Allen <[e-mail]>]

I see I commented on the drafty draft a bit late.  Here goes on
urn-nid-02.  Executive summary:  All we have to do is figure out
a registration procedure and get on with business.  We do not have
to play URN Inquisition with would-be registrants, and attempts to
do so both impede the introduction of URNs and reduce the likelihood
of obtaining cooperation of name space owners in the registry that
*WE want them to use*.

|             Namespace Identifier Requirements for URN Services
| Abstract:
| =========
| 
| Services that offer to resolve Uniform Resource Names implicitly
| require that they support a persistent and reliable service for an
| indeterminate length of time. This draft outlines the requirements for
| any such service that wishes to participate as a Namespace Identifier.

Disagree with the first sentence (see below).  Participate within what 
framework?

| Introduction:
| =============
| 
| The Uniform Resource Name (URN) Working Group has defined mechanisms
| for both the syntax [4] and resolution of URNs [1,2]. An framework
| for URN discovery systems has also been outlined [3]. This draft
| discusses and recommends the requirements for entities that wish
| to act as Namespace Identifiers (NIDs) within the URN system.

The NID is part of the URN string.  So these entities are not acting 
as NIDs.  They are assigning URNs or delegating parts of name spaces.

| The NIDs in these cases, "znet", "buns", and "hoptus" all
| act as top-level namespaces, and hence, must meet certain
  ^^^^^^  "denote", not "act as"

|  Global Scope and Uniqueness.
| 
|   - The NID must be registered with IANA to ensure uniqueness and
|     demonstrating that it meets the requirements listed in this
|     document.

What happened to I-IV in the drafty draft?  

|   - Rules on how the Namespace Specific String are allocated
|     must be documented.

But not necessarily published.

|  Persistence
| 
|   - The NID service providers must show that they intend to
|     support the service for an indefinite period of time.

Impossible to do.  They might be required to promise that they
intend to do that, or arrange for successors, but showing their
inner state of mind is not something we should require.

And it is possible to imagine uses of name spaces for short-TTL
objects such that it would be perfectly reasonable to expect that
no one would want to resolve such names after, say, 20 years or
the expiration of a statue of limitations.

|   - Support facilities must be described and how the service
|     intends to operate, including "disaster recovery"-like
|     operations.

Oh come on.  Are you requiring everyone to describe their IT
policy?  This is for adults in the marketplace to deal with.

|   - Demonstrated experience in managing an established namespace
|     system is essential.    

Is required?  Um, no, we should not be erecting barriers to entry.

|   - One URN should never be reused for a different resource (where
|     "different" is defined as in previous paragraph by the namespace).
|     The URN should be persistent for all times, even though the
|     resource goes away.

This does not belong in a list of what name space registrants have
to demonstrate.

|  Independence
| 
|   - The NID service providers must also show any relationship
|     (both technical and administrative) that may impede on the
|     provision of the URN service.

This is just silly.  *Any* relationship might impede something,
but many relationships are confidential.  This goes far beyond
what we can expect reasonable people and corporations to expose.
"NID service" means nothing to me; "URN service" needs to be glossed.

|   - However, multi-party participation in the NID service is
|     an advantage.

A point not necessary to include here.

|  Resolution
| 
|   - The NID service providers must produce an RFC
|     describing the technical characteristics of the URN
|     resolution service, including security considerations.

Real vague, and requires exposing security considerations that it may
be desired to keep secret.

|   - The NID service providers may elect not to have the
|     resolution service publically available.

Of course, but we don't need to say that here.

| This URN, in the namespace called "buns" is referring to the
| document named annual-report, in postscript format. 
| 
| At a later stage, that resource is replaced by a text version, which
| lacks the pictures, but that is ok, because the namespace has decided
| that postscript format documents and text documents are considered the
| same even though the figures doesn't exist in the textual version.
| 
| In the third stage, the report is removed, and replaced with a report
| for a different year. This new report gets a new URN because it is
| considered being a different document.
| 
| The old URN is never reused.

What is this scenario doing in this document at all?  And the next one?

| (2) urn:foo:bar:current-weather
|     urn:foo:bar:weather/19970325
| 
| These are two URNs referring at one stage to the same resource, i.e.
| on the 25th of March 1997. On the 26th of March 1997,
| urn:foo:bar:current-weather is referring to the same resource as
| urn:foo:bar:weather/19970326.
| 
| Conclusion:
| ===========
| 
| This draft has outlined the requirements for providers of
| NID services for URN systems. The objective is to maintain 
| a high persistence rate for URN services, and these requirements
| are aimed at ensuring a high level of service stability.

I don't think this draft even defines "NID services."

| 
| References:
| ===========
| 
| [1] Ron Daniel & Michael Mealling, "Resolution of Uniform Resource
|     Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
|     February, 1997.
| 
| [2] Ron Daniel, "A Trivial Convention for using HTTP in URN Resolution",
|     draft-ietf-urn-http-conv-01.txt, February 1997
| 
| [3] Karen R Sollins, "Requirements and a Framework for URN Resolution
|     Systems", draft-ietf-urn-req-frame-00.txt, November 1996
| 
| [4] Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02, January 1997.
| 
| [5] Karen R Sollins & Larry Masinter, "Functional Requirements for
|     Uniform Resource Names", RFC1737, December 1994
| 
| 
| Security Considerations
| =======================
| 
| It is a requirement that it in the definitions of a namespace are
| included sections on security covering for example:
| 
|   + Spoofing of servers
|   + Verification of responses
| 
| Because a namespace can decide that a resolution service is not
| publically available, it is possible to use firewall installations and
| other traffic limiting constructions to diconnect the namespace from
| the global Internet.

More stuff not necessary to say.


Regards,

  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
                   http://www.sonic.net/~tallen/
    Davenport and DocBook:  http://www.ora.com/davenport/index.html