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