Re: Last Call: An IETF URN Sub-namespace for Registered Protocol Parameters to BCP
2002-07-03 05:10:43
Keith,
It seems that your objections to this proposal are based on a very
different view of what constitutes a "resource" to that which is understood
in circles where URIs are commonly used. Some edge-cases may have been a
matter for debate, but a good working approximation is "anything that can
be identified by a URI".
Spurred by XML and related technologies (which I assert are far more than
mere "fashion") we are seeing URIs used for a wide range of purposes which
are not constrained by a requirement for dereferencing. The use of URIs
for identifying arbitrary things is now a fact of life, and in some
technical domains is providing to be extremely useful. You claim "harm",
but I recognize no such harm.
(I don't claim that dereferencing isn't often desirable, just not always
necessary. And the DDDS work provides a framework for defererencing URNs
that doesn't critically depend on W3C-style management of http-space.)
Having different syntactic contexts in which names are used will inevitably
lead to different syntactic name forms. I submit that the real challenge
here is not to prevent the use of varying syntax, but to lock the various
syntactic forms to a common semantic definition -- in this case, providing
a way to create syntactic URI forms that can be bound to protocol semantics
in a way that inhibits semantic drift between the different forms.
One of the motivating factors in this work (for me, at least, and I think
for others) has been to draw together some of the divergent strands of
thinking that are taking place in the IETF and W3C. W3C are fundamentally
set on a course of using URIs as a generic space of identifiers. IETF have
a number of well-established protocols that use registries to allocate
names. Neither of these are going to change in the foreseeable future. So
do we accept a Balkanization of Internet standards efforts, or do we try to
draw them together?
A particular case in point is content negotiation. The IETF have prepared
a specification for describing media features that uses a traditional form
of IANA registry to bind names to features. In parallel with this, W3C
have prepared a specification which has some similar goals, but which uses
URIs to represent media features, and relies on the normal URI allocation
framework to ensure the minting of unique names as and when needed. (I
have some reservations about this, but that can't change what is actually
happening.) This URN namespace proposal will provide a way to incorporate
the IETF feature registry directly into the W3C work, in a way which is
traceable through IETF specifications. Without this, I predict that the
parties who are looking to use the W3C work (notably, mobile phone
companies) will simply go away and invent their own set of media features,
without any kind of clear relationship to the IETF features. Creating a
way to avoid that seems like a big win to me.
I also observe that IETF and W3C operate against somewhat differing
background assumptions: the IETF focus on wire protocols means that the
context in which a PDU is processed is well-understood, pretty much by
definition of the protocol. We have protocol rendezvous mechanisms and
state-machines and synchronization techniques that reduce the amount of
explicit information that is needed to be exchanged between parties -- this
is all part of efficient protocol design. The work of W3C (and other
designers working "over the stack") often depends on obviating such
contextual assumptions, and in such cases the global (context-free)
qualities of URIs are extremely valuable. If these layers were truly
isolated from each other, this debate would probably never arise. But
there is genuine leakage: client preferences depend on underlying hardware
capabilities; trust decisions may incorporate protocol addressing and
other information, etc., etc. This proposal to allow IETF protocol
parameter identifiers to be embedded in URI space is one way of controlling
information in these cross-layer interactions.
Another different assumption between wire-protocols and application data
formats: protocols are very binary -- either one is using a particular
protocol or one is not. The years-long Internet Fax debates about adapting
email for real-time image transmission made that very clear. It is not
permissable to simply assume that a communicating party understands
anything beyond the standardized protocol elements. And there is a very
clear distinction in protocol specifications between what is standardized
and what is private extension. This distinction is not so clear in
application data formats, and while there may be a core of standardized
data elements, it is often desirable for communities of users (or
application designers) to agree some common extensions -- this is typical
of how XML application formats are deployed. Using URIs as identifiers
(e.g. in the case of XML, as namespace identifiers) allows for more
flexible deployment of formats, avoiding the problems of "X-headers" that
have for so long been a bane of IETF application standardization/extension
efforts.
In summary: URIs *will* be used to identify protocol parameters. The IETF
cannot prevent that. What the IETF can do by supporting a particular form
of such use is to try and ensure that such use remains bound by a clear,
authoritative chain of specifications to the IETF specification of what
such parameters mean. The harm that comes from not doing this, in my view,
is that we end up with a multiplicity of URIs that mean nearly, but not
quite, the same thing as an IETF protocol parameter. That outcome, I
submit, cannot be good for longer term interoperability between IETF and
other organizations' specifications.
Responding to some specific points in your message:
At 10:01 PM 7/2/02 -0400, Keith Moore wrote:
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.
(i) what it means to resolve a URI will depend on what that URI denotes.
(ii) Done. See DDDS.
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.
Done. The proposal requires RFC publication for new sub-namespaces.
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.
Done. (That, surely, is a matter for the protocol specification
concerned: I'm not aware of any IETF specifications that allow URIs where
registry values are expected.)
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.
I disagree. This requirement actively works against one of the motivations
for using URIs in application data formats; that there be a scalable
framework for different organizations and persons to mint their own
identifiers.
To use an identifier, one must:
(i) have a framework for assigning identifier values, in such a way that it
is possible by some means for a human to locate its defining
specification. I can't see how to do this without exploiting a visible
syntactic structure in the name.
(ii) have a framework for actually using the identifier in an
application: in this case, I agree that the identifier should generally be
treated as opaque.
Also, I think (d) contradicts your goal (a): I cannot conceive any
scalable resolution mechanism that does not in some sense depend on
syntactic decomposition of the name.
#g
-------------------
Graham Klyne
<GK(_at_)NineByNine(_dot_)org>
|
|