On Tue, Jul 02, 2002 at 10:01:50PM -0400, Keith Moore wrote: > 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. In the cases where these URNs are being used the registered protocol element is being treated as a Resource in the full meaning of the term. > 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. RFC 2141 explicitly says that URNs do not need to be resolved to be useful. Discussion about a resolution mechanism _might_ be in order but the namespace was needed long before the resolution mechanism might be in place. To be exact, none of the needs for the namespace required resolution at all. > 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. You don't get to make that choice. That choice is being thrust on us by the industry and by the W3C. If we don't provide this then the current 'http:' URIs that the IANA has now _will_ become unchangeable entity references in emerging standards. > 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. Huh? There is no _primary_ name for the protocol paramenters. There are standards that reference the IANA as the place to look, but there is no way of talking about those parameters using an identifier. > 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. A URI is going to be used regardless of what you or I would like them to use instead of one. We get to pick whether its what the IANA currently has at 'http://www.iana.org/whatever/whatever' or something else.... > 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. The name 'IANA' does _not_ exist in the name. I don't have a problem with changing the parameter names to something meaningless.... > 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. The URN identifies the parameter. Not its value. > 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. The document requires there to be a registration process. A URN is not created for every paramenter unless that parameter has a need for it. > -- > > 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. The IANA doesn't have the resources for that right now. > 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. The document requires an RFC in order for a URN to be assigned. We never suggest assigning them to all protocol parameters. We originally though about the idea but after looking realized it was rather silly. Are you sure you're reading the right version? > 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. Unless that protocol specification actually _uses_ the URN _as_ the protocol paramenter's name. Which some will.... > 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. _I_ wouldn't have a problem with that but the IANA and those who wanted this document to begin with might. I would gladly hear some debate on that. I suggest we be quick though. I know of at least one Working Group that has this as a normative reference and they're waiting on it.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 michael@neonym.net | | http://www.neonym.net