Subject: Re: proposed revision to RFC2611

From: Keith Moore <[email-masked]>
Date: Fri, 6 Oct 2000 15:06:55 -0400

> ---- Proposed replacement text for RFC2611 ----
>
> III. Formal:  A "Formal" namespace may be requested, and IETF
> review sought, in cases where the publication of the NID proposal
> and the underlying namespace will provide benefit to an open and broad
> base of the Internet community.  That is, as in any open standards
> outcome, publication of the NID proposal would allow persons
> not immediately associated with the proposer to create new software,
> or services, or otherwise better carry out their own activities
> than if the NID publication had not been made.  Benefits are expected
> to be in the form of open accessibility, interoperability, etc.

Mumble.  Clearly if the community will benefit from having details of
the namespace published as an RFC, then IETF should encourage such
publication.  But I don't necessarily see that as sufficient qualification
for a Formal namespace.

In general, URNs are not intended to have exposed structure beyond the
NID.  This is because the structure by which URNs under a particular NID
are assigned, or resolved (the two are different) may change over time.
We do not want to encourage implementors to depend on details of the structure
within a particular NID, because that would tend to either constrain the future
use of that NID. On the other hand, if the structure of assignment or resolution
for a particular NID were to change, it could limit the applicability of software
designed with assumptions about the old structure, and could therefore
lessen the effective persistence of the bindings between previously
assigned URNs and their resources.

The principal exception would be for a NID that grandfathers an existing,
well-established namespace (such as ISBN), for which there is significant
utility in exposing the relationship between that existing namespace
and URN-space, and/or in utilizing the structure of that existing namespace.

I don't necessarily want to discourage publication of the structural
details of URN namespaces (especially since the exchange of ideas
might help promote sound namespace design and management).  But I don't
think we should think of this as promoting interoperability.
URN interoperability should not depend on applications knowing the
internal structure of NIDs.

I continue to be strongly of the opinion that namespaces with
human-meaningful NIDs are themselves damaging to persistence,
and we should only assign human-meaningful NIDs when the utility
of doing so (say for grandfathering purposes) has an overwhelming
benefit.  Thus, use of ISDN as an NID can be justified because ISDNs
are already quite well-established, but use of WXYZ as an NID cannot
easily be justified if WXYZ identifiers are not already well-known.

To the extent that it is useful to encourage people to publish details about
the structure of their NIDs, I would prefer that we use a different mechanism
than assigning human-readable NIDs to those namespaces.   We should separate
the concepts of Formal NIDs and Human-Meaningful NIDs.  Also, Formal but
non-Human-Meaningful NIDs should not be penalized by making them longer and
harder to transcribe than Human-Meaningful NIDs.

A concrete proposal would be to allow Formal but Non-Human-Meaningful
NIDs to be represented with a short string of digits to be assigned
by ICANN.  non-Formal NIDs would still need some prefix.

(aside: it would be interesting to investigate the possibility of
allowing DOI prefixes as NIDs, since they already have many of the
right properties for persistence....and this might minimize the
competition between the two groups.  but this would require that the
DOI folks and IETF agree on rules for future assignment of such prefixes.)

> The RFC must include a "Namespace Considerations" section, which
> outlines the perceived need for a new namespace (i.e., where existing
> namespaces fall short of the proposer's requirements).
> Considerations might include:
>
>         - URN assignment procedures
>         - URN resolution/delegation
>         - type of resources to be identified
>         - type of services to be supported

We should be careful here about 'types of services'.  To some degree
the types of services to be supported are inherently related to the
types of resources which may be identified.   But we should not
encourage implementors to make assumptions about which services
(or for that matter, which resources) are available with which NIDs.

> The RFC must also include a "Community Considerations"
> section, which indicates the dimensions upon which the proposer
> expects the Internet community to be able to benefit by publication
> of this namespace.  Potential considerations include:
>
>         - open assignment and use of identifiers within the namespace
>         - open operation of resolution servers for the namespace (server)
>         - creation of software that can meaningfully resolve and
>           access services for the namespace (client)

Again, the creation of software aspect seems dubious.

> It is expected that Formal NIDs may be applied to namespaces
> where some aspects are not fully open. For example,
> a namespace may make use of an externally managed (proprietary)
> registry (as, e.g., ISBN does), for assignment of URNs in the namespace,
> but it may still provide broad community benefit if the services
> associated have openly-published APIs.

I think that Formal-ness (meaning publication of the structure) of the NID
should have little or nothing to do with open-ness of the NID.  However,
we should be wary about assignment of a human-meaningful NID to a closed
and non-pre-existing namespace - because the resulting competition for
favorable names, and the potential for disputes over ownership of an NID,
damages persistence of the URNs under that NID.   NIDs are not intended
for marketing purposes.

IMO, the fundamental requirements for assignment of a Formal NID should be based
on the following principles:

- the organization maintaining the NID should demonstrate stability and
  ability to maintain the NID space for a long time
- it should demonstrate ability and competency at name assignment in order
  to facilitate persistence (e.g. to minimize the likelihood of conflicts)
- it should commit to not re-assigning existing names and allowing old names
  to continue to be valid, even if the owners or assignees of those names
  are no longer members or customers of that organization.
  (this does not mean that they must provide resolution of such names, but
  it does mean that they must not resolve the name to false or stale
  information, and it means that they must not reassign the name)

Keith