I strongly object to this document being labelled a BCP.
1. URNs are intended as resource identifiers, not merely as unique
tokens. The use of URNs as resource identifiers seems is misleading
the public about the purpose of URNs, and thus does harm to the
functionality for which URNs were designed.
The failure of this proposal to even attempt to define a resolution
mechanism, or to describe what resources might be obtained by
resolving the URNs, clearly illustrates that it's not approprately
using URNs.
2. More generally the practice of using a URI as a substitute
or alternate name for some other registered quantity is a highly
dubious one, that IETF should discourage rather than encourage.
Having multiple names for the same protocol parameter is generally
a bad idea. For instance, in contexts where both representations of
the parameter are permitted, the existence of multiple representations
makes comparison between different representations of the same parameter
value considerably more difficult.
Furthermore, the use of URIs in place of registered protocol parameters
provides an easy way to bypass the procedures that have been established
for registering such numbers or tokens for that particular protocol -
at least in protocols whose parameters are ASCII strings that are more-or-less
syntax compatible with URIs. This is not something we should encourage.
3. Even assuming the desirabliity of having URI synonyms for
protocol parameters, the use of human-readable strings in URNs
(especially to describe their structure) is poor design, as
human-readable strings are subject to semantic drift over time
which may eventually produce a desire to reorganize the
name-space - if not invalidating old URNs then making them less
accessible. To give a concrete example, if IETF or IANA decides it
needs to reorganize the categories for protocol parameters, or if
at some point it becomes necessary to transfer some of the functions
currently delegated to IANA to some other organization (not necessarily
because we chose this - there have in the past been credible threats
to force us to do something like this) then we have a problem in that
the human-readable name "IANA" and human-readable names for IANA's
parameter organizing structure are wired into the URN.
Similarly, even hinting that there might be a syntactic mapping
between "parameter value" and "URN for parameter value" is a
Bad Idea, because it encourages implementors to assume that such
mappings are a matter of protocol, when it may be necessary to
change them in the future (even if the old URNs remain "valid"
in that they are not re-assigned, the string-mapping function
will no longer yield valid URNs for valid protocol parameters)
Again, this defeats the stability that URNs are intended to provide.
4. given that URIs are used to name XML protocol elements,
the definition of a URN for every protocol element seems
like an invitation to translate any random protocol into XML,
for no useful purpose other than to degrade interoperability.
--
For the reasons stated above, I argue that the practice described
in this document is not even "desirable", and it's certainly not
representative of the "best" practice that is currently known.
If we're going to do anything like this at all (and I realize that
XML advocates really want something like this), we should:
a) at least define what it means to resolve such URNs, and ideally
set up an initial resolution system for them.
b) limit the protocol parameters to which it applies to those
which are justified by some use case, rather than applying
them to all protocol parameters.
c) make it clear that it is NOT acceptable to use those URNs
as substitues for the actual parameter values specified
in a protocol specification.
d) embed NO visible structure in the URNs - just assign each
parameter value a sequence number. people who want to use
those URNs in XML or whatever would need to look them up at IANA's
web site.
actually if IANA assigned each parameter an OID then the oid URN
type could be used.
Keith