Subject: proposed revision to RFC2611

From: Leslie Daigle <[email-masked]>
Date: Fri, 22 Sep 2000 18:50:19 -0400

Howdy,

Following up on the discussion of a few weeks ago, here is
some proposed text to replace the "III. Formal" section in RFC2611.

I've tried to incorporate/address the various comments re. the
need to allow overlapping namespaces, as well as other issues
identified on this list.

This inevitably leaves stuff open to interpretation, although I hope
it will be able to capture a reasonable expression of our design
goals.

Comments please...

Leslie.

---- 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.

The NID application is made via publication of an RFC through
standard IETF processes.  The RFC need not be standards-track, but
it will be subject to IESG review and acceptance pursuant to the
guidelines written here (as well as standard RFC publication
guidelines).
The template defined in section 3.0 may be included as part of an
RFC defining some other aspect of the namespace, or it may be
put forward as an RFC in its own right.  The proposed template
should be sent to the

        [email-masked]

mailing list to allow for a 2 week discussion period  for
clarifying the expression of the registration information,
before the IESG reviews the document.

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

NOTE:  It is expected that more than one namespace may serve
the same "functional" purpose; the intent of the "Namespace
Considerations" section is to provide a record of the proposer's
"due diligence" in exploring existing possibilities, for the
IESG's consideration.

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)

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.

Additionally, since the goal of URNs is to provide persistent
identification, some consideration as to the longevity and
maintainability
of the namespace must be given.  The URN WG discussed at length
the issue of finding objective measures for predicting (a priori)
the continued success of a namespace.  No conclusion was reached --
much depends on factors that are completely beyond the technical
scope of the namespace.  However, the collective experience of
the IETF community does contain a wealth of information on technical
factors that will prevent longevity of identification.  The IESG may
elect not to publish a proposed namespace RFC if the IETF community
consensus is that it contains technical flaws that will prevent
(or seriously impair the possibility of) persistent identification.

A particular NID string is requested, and is assigned by IETF
consensus (as defined in [RFC2434]), with the additional constraints
that
the NID string must

        - not be an already-registered NID
        - not start with "x-" (see Type I above)
        - not start with "urn-" (see Type II above)
        - not start with "XY-", where XY is any combination of 2
          ASCII letters  (see NOTE, below)
        - be more than 2 letters long

NOTE: ALL two-letter combinations, and two-letter
combinations followed by "-" and any sequence of valid NID
characters,  are reserved for potential use as countrycode-
based  NIDs for eventual national registrations of URN
namespaces.   The definition and scoping of rules for
allocation of responsibility for such namespaces is beyond
the scope of this document.

Registrations may be revised by updating the RFC through
standard IETF RFC update mechanisms.  Thus, proposals for
updates may be made by the original authors, other IETF
participants, or the IESG.  In any case, the proposed updated
template must be circulated on the urn-nid discussion list,
allowing for a 2 week review period.

URN namespace registrations will be posted in the anonymous FTP
directory "ftp://ftp.isi.edu/in-notes/iana/assignments/URN-
namespaces/".

--

-------------------------------------------------------------------
"Reality with a delicate splash of the imaginary...
    ... or was that the other way around?"
   -- ThinkingCat

Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: "Martin J. Duerst" <[email-masked]>
Date: Sat, 23 Sep 2000 11:38:55 +0900

Hello Leslie,

I haven't thought through everything in detail, but I think
your text is extremely well written and addresses a lot of
the problems that have come up recentently.

At the moment, I have one general concern and one small
comment:

The text only speaks about an RFC, not about an I-D. Also,
it's not clear whether IESG approval or submission to
[email-masked] should be first, and in what form.

 From general IETF experience, it seems that the sequence
would be:

- Submission to [email-masked] as an I-D.
- Discussion there, maybe resubmission.
- Submission to IESG as an I-D for RFC publication.
- RFC publication and registration.

But maybe I'm getting something wrong. Anyway, I think it
would be extremely helpful if these things were spelled out
in the text in order to avoid confusion. I haven't seen
such confusion yet in the nid case, but I have seen it
for similar registrations where they went together with
an RFC.

>associated have openly-published APIs.

I'm a little bit confused by the word API here. Does publication
as an RFC provide an API? Are RFCs supposed to include an API
definition? If yes, what form would such a definition take?
Can some entries in DNS and some resolution services, which maybe
you want to refer to, be called an API? (I guess in a very wide
sense, that's possible, but it's really stretching the term,
and there are probably better terms).

Regards,   Martin.

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 26 Sep 2000 14:53:37 -0400

Howdy,

> in the text in order to avoid confusion. I haven't seen

Yep, good point, I'll add text to clarify that (both for formal
and informal NIDs).

> and there are probably better terms).

True.

How about:

"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)
source for assignment of URNs in the namespace, while providing
open access, and enough technical detail for unrelated parties
to build tools to make use of the names and services.  For example,
the "IETF" namespace has names assigned based on procedures defined
for RFC series (closed), but the convention for mapping such URNs to
document locations is publicly stated and third parties can make
use of these URNs."

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 26 Sep 2000 14:55:49 -0400

Hi all,

I'd like to hear more about people's thinking on the proposed
revision to RFC2611, or alternative suggestions.

I can make assumptions about what the silence means, but on the
whole, I think it's better not to...

Thanks,
Leslie.

--

Leslie Daigle
[email-masked]

---

From: Larry Masinter <[email-masked]>
Date: Tue, 26 Sep 2000 12:45:47 -0700

I like the direction of the proposed revisions, and I think it's
important to revise RFC 2611.

There are two components to your proposed revision that are
currently intermixed, that might be usefully separated out.

One component is the actual qualifications for a formal namespace:
what are the considerations and qualifications that formal namespaces
must meet.

The second component is the process by which the meeting of those
qualifications are judged -- which things need to be in the form
you fill out, where it gets sent, what mailing list is offered
the opportunity to review & comment, and how the final decision
to grant or reject the application gets made.

I think your current wording tends to get at the first (e.g.,
that namespaces must meet criteria for longevity and maintainability)
by talking about the second (the form must contain a discussion
of longevity and maintainability), partly because it is hard
to give objective criteria, but I think it would be useful to
try to push things even more so that the criteria are explicit,
and described separately from the process.