Subject: Needed refinements

From: Leslie Daigle <[email-masked]>
Date: Fri, 8 Sep 2000 17:07:17 -0400

Hello all,

In the process of reviewing recent URN formal NID proposals, the
IESG has expressed some concerns over whether the URN
working group had adequately described constraints that would
maximize the likelihood of public use and overall interoperability
of these namespaces.

Specifically, the current process (RFC2611) does indicate that a
formal NID RFC will be published subject to IESG review, but
the suggestion is that there should be more concretely stated
guidelines so that new formal NIDs are considered when there
is adequate justification that:

        . there is no existing namespace that would serve the
          functional purposes of the proposer

        . the proposed namespace is of sufficient community
          value that it merits the distinction of a formal NID

Terry, I think this speaks to your concern about getting _all_ the
criteria out on the table.

So, there is discussion to be had -- and consensus to be found
on what practical criteria can describe the above (to be published
in a revised version of RFC2611).

I have some specific proposals, but would rather hear what other
people have to say, first...

Leslie.

--

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

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

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Sep 2000 00:51:17 -0400

The problem with this is that the existing namespaces may come with
strings, and IESG is not in a good position to determine whether the
existing namespaces (and their strings) serve the functional purposes
of the proposer.  So I would not include this as a consideration, or
at least, I would not want it so strongly worded.  We should be able
to have URN multiple namespaces that serve a particular purpose,
even to the point of allowing namespaces to overlap.

I do see this as an important consideration.  Basically we don't want
to burden either NID space or the NID registration process with
NIDs that are of little value to the community.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Mon, 11 Sep 2000 07:57:13 -0400

> NIDs that are of little value to the community.

I guess we need to further define what we mean by 'community' here
before I'm comfortable with this one. The publishing community for
example could be using a few NIDs almost completey within their
community. Do we consider their needs or some other community
when considering their NIDs?

-MM

--
--------------------------------------------------------------------------------
Michael Mealling        |      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:         14198821
Network Solutions       |          www.lp.org          |  [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Sep 2000 09:35:44 -0400

> when considering their NIDs?

I guess I would say that the NID needs to benefit a significantly-sized
group of people.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Mon, 11 Sep 2000 09:33:35 -0400

> I guess I would say that the NID needs to benefit a significantly-sized

I'm good with that as long as we explicitly say that we use a
loose definition of 'benifit'. In my example above some would say that
the only people who direclty benifit are a couple of publishers whereas
I would claim that the people who benifit are the much larger number of
those publisher's customers....

-MM

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Sep 2000 10:34:52 -0400

> those publisher's customers....

presumably even in these days of consolidation 'the publishing community'
is significantly larger than 'a couple of publishers'.   an NID that
was shared by a large group of publishers would be okay.  OTOH, if each
publisher had its own NID, then this would be to the detriment of URNs
as stable identifiers (since works should be able to be transferred from
one owner to another without changing NIDs).  this would result in harm,
rather than benefit, to the customers of those publishers.

ultimately we should work to benefit the community of internet users,
rather than the publishers.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Mon, 11 Sep 2000 10:39:55 -0400

> rather than the publishers.

I can go along with some of this (I don't like it because I still want to
allow the 'little guy' into the club but I realize I'm in a minority here).
My question is how do you say that in a standards document without
getting the IESG into a whole hell of a lot of trouble when someone's NID
gets refused on these grounds?

-MM

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Sep 2000 12:25:50 -0400

> allow the 'little guy' into the club but I realize I'm in a minority here).

I don't see this as a little guy vs. big guy issue.  Little guys should
be able to get NIDs if what they are doing has the potential to benefit
a large group of people.   But that's not the same thing as saying that
everybody should be able to have his own personal NID.

> gets refused on these grounds?

it's a good question.  I think we need to come up with guidelines about
NID suitability that are derived from the intended purpose of URNs as
long-term stable resource identifiers, and from other URN requirements
such as the ability to grandfather existing URN-like namespaces
(presumably with a recognizable NID).

also, we're talking about Formal (Type III) NIDs here.  Experimental or
Informal NIDs are also available.  seems like applicants for Formal NIDs
should be expected to explain why they need a Formal NID and an
Experimental or Informal NID isn't good enough for their purposes.
one reason that comes to mind would be the desire to grandfather in an
existing well-established namespace; another reason *might* be for
namespaces that could reasonably be expected to enjoy very wide use.

but IMHO one of the things that DOI did right was to use strings of
digits as namespace identifiers. it would be desirable for URNs to
discourage use of "human readable" NIDs except when there is a
convincing case that the use of such NIDs will actually promote
adoption of URNs (this is the grandfather case) or the long-term
stability of URNs.

Keith

---

From: Leslie Daigle <[email-masked]>
Date: Mon, 11 Sep 2000 14:25:00 -0400

Howdy,

[Slipping on my "participant hat"...]

> even to the point of allowing namespaces to overlap.

Yes, this is true.  My personal feeling is that we can't carve
this out in stone, but

        a) it doesn't seem unreasonable that there should be a burden
           on the proposer to demonstrate that they've at least looked
           at existing namespaces

        b) the demonstration should be at the level of showing that
           it's not just a "not invented here" syndrome that provokes
           the desire for ignoring what already exists

The challenge is... there are no hard & fast rules (without over-
constricting namespace possibilities).

> NIDs that are of little value to the community.

I believe this is true, but this is an area which admits a number of
different philosophies.

In a later message, Keith Moore wrote:
>  I think we need to come up with guidelines about

The rathole we've never before stopped ourselves from falling into
is:  what are the objectively observable criteria for predicting
that a given namespace proposal will succeed in providing unique
identifiers with adequate longevity.  So, let's try to stay away
from those specific issues, and take a step back to focus on
the general area of why should a given thing be formally published.

Some things that spring to my mind:

  1. Openness (openess?) of some or all aspects of the namespace:

        . consumers will be able to use this namespace to independently
          assign and use identifiers within it

        . software developers will be able to build clients to use it:
                . published resolution mechanism
                . open access to the data identified

        . servicing -- independent services can build resolvers to
          meet the namespace spec

     Note that not all (few?) namespaces will meet all these criteria:
     e.g., the "IETF" namespace does not allow independent assignment
     of URNs within it, but there is enough published to allow
     software devlopers to build clients or services for it.

  2. Widespread community value

     There are 2 separate aspects here:
        . widespread (the "Internet" use, not just "intranet" use)
        . community -- that there is a (widespread) community
          that it serves, e.g., the libraries of the world

     Note that this does not always follow from "openness" -- the
     "application/MSWord" media type is useful to many individuals
     across the globe whose mail programs can open up the
     appropriate proprietary software program to view the attachment
     (okay, so then we all catch viruses and spend a week debugging
     our machines, but go with the _point_, not the specific
     example ;-)

The key point is -- there has to be value in publishing the spec
openly, not just as a "deposit requirement" for getting a particular
NID.  We would still have the same problems (although perhaps less
frequently) if NIDs were randomly-assigned bit strings.

I've tried to phrase the above in a way that will be detectable in
a well-written namespace proposal document so that "grandfathered"
namespaces will fit, but so will as-yet-unheard-of ones that are
brought into being specifically for the Internet (publishing,
protocols, etc).

Thoughts?

Leslie.

--

Leslie Daigle
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 11 Sep 2000 14:42:16 -0400

>          on the proposer to demonstrate that they've at least looked

agreed.

>          the desire for ignoring what already exists

maybe.  I'm confortable with "not invented here" provided that the
applicant demonstrates some understanding of what has already been
invented and can argue that the new proposal is different in some way.
(which might be as simple as saying "even though our proposal is
similar to XYZ's, XYZ should not have a monopoly on URN assignments
of this type")

> constricting namespace possibilities).

given that we want URNs to last for decades, it will be decades before
we really understand how well the policies/procedures/rules work.
so at this stage we should have few hard-and-fast rules; in a few years
or tens of years we might want more.

> I believe this is true, but this is an area which admits a number of

agreed.

> identifiers with adequate longevity.

I don't think (and didn't intend to suggest) that we should insist
that a NID proposal demonstrate characteristics that ensure success
(as if we could even define such characteristics!)  but rather that
our criteria for evaluation of new NID proposals should follow
from the intended purposes of URNs.

> frequently) if NIDs were randomly-assigned bit strings.

I agree with this also.  There's little point in having a formal NID
if publication of the specifications for that NID doesn't result in
some community benefit.  Though for the case of grandfathering in an
existing namespace, a public document of the form "this is how you
translate FOO identifiers to/from URNs..." would provide such a benefit
even if it did not provide details of assignment, resolution, etc.

However I suspect that the granting of a formal NID also constitutes
some sort of statement by IETF about the suitability of that namespace
as a part of URN space, so I would say that both the suitability of
the namespace and the value of publication of the RFC should be considered.

Keith