Re: [urn] [apps-discuss] URNs are not URIs (another look at RFC 3986)

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

>From the point of view of this analysis, the items that I have a
strong opinion are few, but I think that they bear heavily on the
practical engineering of the situation, and so need to be resolved one
way or the other.  The general idea is that being conservative
regarding syntax will avoid large costs, because much existing
software incorporates syntax assumptions.  But extending semantics is
not likely to be so expensive, because little software depends on the
semantic assumptions of a subset of UR* unless the software performs
detailed processing on those particular UR*.

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

> Perhaps
> as a corollary to the latter, perhaps independently, there have
> been efforts to create a Grand Unified Identifier syntax,
> sometimes in the very restricted "scheme:<stuff>" form that
> Phillip proposed, sometimes with a lot of reserved characters
> and associated semantics, and sometimes in between.

I have a strong sense that it's valuable to have and maintain a syntax
within which all the UR* fit, because processors of UR* enforce and
implement such syntaxes.  Currently the umbrella syntax is RFC 3986.
The cost of expanding the UR* syntax beyond what 3986 permits is going
to be relatively high, and will show up in systems that try to allow
all possible UR*s in certain situations.

Unfortunately, 3986 also specifies some semantics.  I believe that the
semantics defined for '#' (fragment) is sufficiently precise that
there is a risk that a considerable number of processors may be
incompatible with any other use for '#'.  That is, there will be a
significant cost to changing its semantics.

My current opinion is that the semantics of '?' (query) is
sufficiently broad that it can be used for any purpose that the UR*
scheme wishes define.

URNs of the "urn" scheme are currently constrained to the subset of
the syntax that is specified in RFC 2141.  2141 says that '#' and '?'
are reserved for expansion, but unfortunately the BNF given does not
specify their use.  This suggests that adding fragment and query to
"urn" URNs will be expensive, as software is likely to be designed to
the BNF.  However, defining additional URN schemes that do not have
that restriction should not have such a cost.

> (i) There is a community, [...] that have found the syntax and
> semantic constraints unreasonably restrictive given their perceived
> needs.

Can you give us pointers to this?  In particular, regarding the
syntax.  It seems to me that this is a deeply important point, but
short of reading the entire URNBIS archive, I don't see any
algorithmic way to obtain the supporting information for this
assertion.  Surely, if there are large communities with this opinion,
someone somewhere has made a clear statement and defense if this
conclusion.

Dale