[urn] Moving forward with something URN-ish

[John C Klensin <[e-mail]>]

Hi.

Having addressed some of the questions and explained why I don't
want to engage with some of the others (Mark Nottingham's "two
communities ... shared artefact" note of 18 April should be
incorporated by reference), this note is a personal perspective
on ways forward.  If draft-ietf-urnbis-urns-are-not-uris is
helpful in this regard, it can be revised as needed; perhaps
into something rather different.  If it is not, it is easily
discarded.  The terms "the draft" and "the current draft" below
refers to draft-ietf-urnbis-urns-are-not-uris-00.

Regardless of what one calls either the communities or what they
want to do, there is at least one significant community,
identified in Section 2 of the draft as "Content industries ...
and memory organizations ..." ("CiMo" below), or a subset of
that community, that perceives a need for some functionality
that cannot be provided by URNs as specified in RFC 2141.  For
them at least, extensions to 2141 that are fully compatible with
RFC 3986 are inadequate to meet those needs.  Some of us have
come to agree with them (although not all for the same
reason(s)).  Others do not.   They have found a strategy,
promoted and practiced by some people associated with the WG in
the past, of telling them that they really don't want and/or
need to do the things they believe that they need to do
unpersuasive... and, given centuries of experience in doing what
they do and peer-reviewed literature to back it up, insulting
and perhaps worse.  

They have, IMO, demonstrated remarkable patience with us but
still have the option they have had all along.   That option
could be to develop something URI-like with a method of, e.g.,
"CiMo" and whatever syntax met their needs or to develop much
the same standard with a method name of "URN".  Either would
presumably be done independent of the IETF.  While the advantage
of a "CiMo" method and syntax would be that no one would expect
it to conform to RFC 3986, it would have the disadvantage of
being incompatible with millions of identifiers developed and
deployed consistent with RFC 2141 (including but not limited to
those developed and deployed consistent with RFCs 3044, 3187,
and 3188).  If they were to do something independent of the IETF
because they gave up on our meeting their needs, I'm not in a
position to predict whether they would go the "CiMo" path with a
new method or would fork the "urn" method definition.  But, in
their position, I'd probably look at the economics of converting
those millions of existing identifiers and the (extremely small)
extra value that would result from doing so... and then decide
that the decision to fork the URN definition was a non-brainer.

So, without touching the "what is a name", "what does
'presistent' mean" and several other debates (and with some
redundancy with a note I wrote earlier in the month) I think we
can now:

(1) Recommend that the IETF (and maybe others) create a 3986bis
with more flexible syntax and no semantics and then revise 2141
to conform with it and accommodate the perceived needs of that
CiMo community (and other communities who believe we need to
move beyond un-extended 2141).  The creation of that 3986bis is
clearly outside the scope of this WG.  The reaction on the
apps-discuss list to the current draft suggests that such a
draft cannot be written and agreed to quickly (if at all).

(2) Remove syntax for the "urn" method from the scope of 3986
without trying to change 3986 itself.  This is what the current
draft attempts, probably badly.  Then develop a 2141bis that is
upward compatible from 2141 (even though it might use some of
the bits of syntax that 2141 reserved) and that meets the needs
of the CiMo and other communities, as above.

(3) Decide that the combination of the relative silence and
slowness of the URNBIS WG indicates that an adequate combination
of interest and knowledge does not exist in the IETF and then
either:

(3.1) Close the WG and hope that the necessary expertise and
interest will eventually emerge, that the work can be restarted
at that time, and that no one decides to do something
incompatible in the interim.

(3.2) Hand change control over to the CiMo community or someone/
something else and encourage them to develop a new URN spec.
That spec would presumably be compatible enough with 2141 to
avoid invalidating any 2141-conforming URNs or NIDs because
their investment in those existing URNs would encourage that,
but the IETF would have no way to enforce that outcome.
Presumably we would eventually ask for permission to public
their spec or a reference to it in the RFC series and would use
to obsolete 2141.

Note that, unless the CiMO community exhibits even more patience
than they have in the past, presumably being willing to wait for
the IETF forever, the only practical difference between 3.1 and
3.2 is probably whether they develop a new URN spec with or
without the IETF's official blessing and hence whether their
spec is considered a replacement for 2141 or a fork to that IETF
URN spec.

(4) In principle, the WG could wrap up the work on a 2141bis
that was strictly 3986-compatible and complete a 3406bis that
was compatible with it and only then close and proceed with one
of the variations on (3).  Others may have the energy for that;
personally I'd think it would be a lot of effort for very little
payoff.

I just don't see other options, at least ones that not have been
proposed already and failed to gain traction.  Is anyone else
able to suggest ones I haven't thought of?   Or have reason to
believe that such options will emerge if we wait long enough?

And, if there are no other options, what do people want to do?

FWIW, there will some meetings next week that will involve some
of the key actors in the CiMo standards community.  Their
procedures won't permit creating a new CiMo-URN project and
launching it without some additional steps, but I would expect
those of us who are present at all or parts of that meeting to
be asked hard questions about the progress the IETF is making.
If we don't have answers better than "still stalled and no
plan", then the first steps toward an independently-developed
specification could easily be taken.

Finally, if option (2) is the right approach but the draft isn't
the right way to do it, do people have specific suggestions or,
ideally, text?

   best,
    john