ietf
[Top] [All Lists]

Re: Last Call: An IETF URN Sub-namespace for Registered Protocol Parameters to BCP

2002-07-02 21:10:03
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(_at_)neonym(_dot_)net      |                              | 
http://www.neonym.net