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