> 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. it's hard to understand what that means. a protocol element is not a document or a service. it cannot be retrieved or accessed. it's just an abstract concept. > > 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. true, but the assumption here is that having URNs be attached to resources allows those resource names to be compared for equivalence (meaning that the resources attached to those names are equivalent, or at least different versions of the same resource). it's not clear how this proposed use of URNs is anything like that 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. I really don't care what kind of fashion statement the industry and/or w3c is putting out this week; if it doesn't make good technical sense then the IETF shouldn't be endorsing or supporting it. If there's a really good reason for this then let's do it but the fact that w3c thinks it is a good idea is NOT by itself a good reason. actually using http: URLs (which is what w3c seems to prefer) might actually be better than URNs - at least it wouldn't mislead people about what URNs are, and people are less likely to believe that http: URLs are stable. (fwiw, impressions I have from reading the w3c tag list is that w3c folks strongly prefer resolvable URIs - so if we're trying to play nice with w3c by proposing URNs we might want to explain how they're going to be resolvable. only if there's a sound technical justification, of course, and assuming we can actually define what "resolvable" means for a protocol parameter.) > > 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. some parameters do have names that are used in protocols - RFC [2]822 header field names are a good example. > > 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. the current occupant of the white house is going to keep killing innocent people too regardless of what you or I would like him to do. that doesn't mean that IETF has to support it. > We get to pick whether its what the IANA currently > has at 'http://www.iana.org/whatever/whatever' or something else.... I'm tempted to suggest that the IANA change this URL at random intervals to deter people from having the illusion that they're stable. > > 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.... that would go a long way toward making them more acceptable... > > 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. again I was thinking of things like header fields, though I admit I didn't describe it well. > > 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.... we should discourage this for IETF protocols. > > 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.... here's a litmus test - if a proposed use of a URN fails because the URN is opaque, they shouldn't be using a URN. as a concrete example, if someone expects to be able to map RFC 2822 header field "foo" into a URN of the form <prefix>"foo" then they shouldn't be using a URN. Keith