Re: [urn] Tuning the "URNs are not URIs" spec

[[e-mail] (Dale R. Worley)]

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

>    Like most controversies in which one group does not accept
>    the definitions, facts, or logic of another, the
>    differences are unlikely to be resolved by further
>    discussion, no matter how sensible and patient.

I'd phrase it "... in which EACH group does not accept ... of THE
OTHER".

>    Instead, the question is whether the IETF is willing to
>    evolve and adapt the URN definition to accommodate those
>    perceived needs or whether if prefers to have that work
>    done elsewhere, either by adoption in the broader
>    community and marketplace of a different approach or,
>    potentially, even a competing URN standard.

As far as I can tell, the key question is "Is the syntax of RFC 2141
("URN syntax") inadequate for the needs of important groups of users?"
If the syntax is adequate, then various groups of users can define
namespaces that have the properties that they desire without causing
any upset in running code; at most, revisions would be needed to RFC
3406 ("URN namespace definition mechanisms").  (Unlike IPv4 addresses,
we aren't in danger of running out of namespace identifiers.)

(And for example, this flexibility allows multiple sets of identifiers
which handle name/locator differences in distinctly different ways.)

What seems to be constantly hinted at in this discussion -- but never
explicitly stated -- is that important groups of users have needs that
CANNOT be satisfied within the syntax of RFC 2141.  Not just that the
particular definitions of "fragment" and "query" in RFC 3986 are
inadequate for their needs, but that those needs cannot be satisfied
by *any alternative means* that can be represented within the syntax
of RFC 2141.

If that actually is so, it is a fairly concrete fact, it shouldn't be
very difficult to make the case in a convincing way.  And once the
case is made, it would be a sound reason to move ahead with
significant changes to the status quo.

One objection I can see to RFC 2141 is how restrictive it is:  The
namespace-specific string can contain only letters (two cases),
digits, and 15 of the 32 ASCII special characters.  (That's not
counting %, since it has a special purpose.)  I can see how a group
may want to have much more syntactic flexibility in designing an
identifier, and they wouldn't enjoy %-encoding a large fraction of the
characters in their identifiers.

OTOH, there's no reason that a user group would have to *see* what
their URNs look like very often.  Most user interfaces that would
refer to sophisticated identifiers don't have to reveal the URNs that
are used one the wire, any more than that we have to see the bits that
encode the characters of our e-mails.

For instance, there's no reason that DOIs can't be encoded much the
same way that EIDRs are encoded (draft-pal-eidr-urn-03):

    The DOI "10.1051/0004-6361:20054201"
    becomes the URN "urn:doi:10.1051:0004-6361%3a20054201".

(Any sequence of Unicode characters can be represented as a sequence
of %-escapes per RFC 2141 section 2.2.)

The great benefit of this approach is that generic operations on these
URNs can be done by the great bulk of currently running code.

Dale