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

From: Keith Moore <[email-masked]>
Date: Tue, 02 Jul 2002 22:01:50 -0400

I strongly object to this document being labelled a BCP.

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.

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.

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.

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.  

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.

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.

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.

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.

				--

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.  

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.

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.

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.

Keith

---

From: Michael Mealling <[email-masked]>
Date: Wed, 3 Jul 2002 00:06:34 -0400

> 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. 

> resolving the URNs, clearly illustrates that it's not approprately

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.

> 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.

> 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.

> 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....

> 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....

> Again, this defeats the stability that URNs are intended to provide.

The URN identifies the parameter. Not its value.

> 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.

The IANA doesn't have the resources for that right now.

>    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?

>    in a protocol specification.

Unless that protocol specification actually _uses_ the URN
_as_ the protocol paramenter's name. Which some will....

>    actually if IANA assigned each parameter an OID then the oid URN

_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
[email-masked]      |                              | http://www.neonym.net

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 00:27:22 -0400

> element is being treated as a Resource in the full meaning of the

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.

> 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.

> 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.)

> 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.

> 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

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.

> with changing the parameter names to something meaningless....

that would go a long way toward making them more acceptable...

> 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.

> _as_ the protocol paramenter's name. Which some will....

we should discourage this for IETF protocols.  
 
> one Working Group that has this as a normative reference and they're

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

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 12:54:52 +0100

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:

>    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.

>    them to all protocol parameters.

Done.  The proposal requires RFC publication for new sub-namespaces.

>    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.)

>    those URNs in XML or whatever would need to look them up at IANA's

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
<[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

> matter for debate, but a good working approximation is "anything that can 

In other words, anything you can attach a name to is a resource.
 
> but I recognize no such harm.

Clarification: I claim "harm" for the proposed use of *URNs* because
URNs were designed to be long-term stable names for (at least potentially)
network-accessible resources, whereas the proposal is to use them as a 
way of generating globally unique strings like UUIDs or OIDs.

> syntactic forms to a common semantic definition 

Oddly enough, having different syntactic contexts also tends to cause
differences in semantic definition.  In one syntactic context order
of elements can be significant whereas it's not in the other. one syntactic 
context is designed to allow individual components to be accessed independently
of the others while another expects the entire resource description to
be available to the consumer.  One makes it easy to group related
items; another doesn't have a way of representing relationships between
items.  The semantic definitions tend to be influenced by these factors.

I'm all for reuse of data models where it makes sense, but if the goal
is really to "lock the various syntactic forms to a common semantic
definition" (presumably one which is compatible with XML) then I take
strong issue with that, as the XML model is quite dysfunctional for
many purposes.  (as are the others, it's just that XML is the current
bandwagon)

> -- in this case, providing 

But such drift is almost inevitable.  You can't recast some existing
data structure in XML and use it widely and expect the meanings of the 
protocol elements to stay the same.  And in essentially every example I've 
seen of an attempt to do this, the meanings of the protocol elements are 
changed subtly from the very beginning, usually by trying to use XML
structure to represent relationships that aren't explicit in the original  
data model.  More generally, an XML representation of a data model will get 
used differently than the original representation, and the semantics of the 
individual protocol elements will almost certainly drift as a result.

(Actually this happens even when you use the same representation.
RFC 822 headers had subtly different meanings on BITNET than on
the Internet, because there were enough differences in the two user 
communities and the mail reading programs used by those communities.
Similarly, casting a data model into XML means that a different set
of tools will be used to access/manipulate that data - indeed that
is the entire point of doing so - but this *will* cause semantic drift
in the data model between the two environments)

Using URIs for the names of the data elements won't stop that kind of drift.

> do we accept a Balkanization of Internet standards efforts, or do we try to 

Some things don't mix very well, even if they are quite useful individually.
The traditional examples are oil and water.

> happening.)  

But neither do we have to endorse it just so they will use our stuff.
Especially when their using our stuff dilutes the utility of our stuff
by not requiring widespread agreement on the media features used.

> This URN namespace proposal will provide a way to incorporate 
> without any kind of clear relationship to the IETF features.  

The w3c approach is encouraging them to do this anyway, by having
all media features be URIs that anyone can create/assign without any 
agreement from anyone else.

> information in these cross-layer interactions.

I think it would be far more useful to think of things in terms of the
mapping/translation process rather than just assigning alternate names to 
the protocol elements.  If it happens that the translation doesn't affect 
semantics of individual elements at all, that's a good thing, but my
experience suggests that that it often will.  And you don't know for sure
until you start looking at how those protocol elements will actually be
used in the new environment.
 
> have for so long been a bane of IETF application standardization/extension 

Actually they are X- headers, just globally unique ones.   I'll freely
admit that such extensibility can be useful, and that having distributed
assignment of globally unique names for extension fields is a good idea
(though I've rarely seen a conflict between X- headers) but it's a huge
stretch to say that all fields should be defined this way.

(Also, I don't think that X- headers are a "bane" or ever have been;
they seem to cause far less harm than improper use of non X- fields; 
they're just currently out of fashion for reasons I cannot fathom)

> other organizations' specifications.

The likely consequence of what is being proposed is for the URIs that we
define to mean nearly, but not quite, the same thing as an IETF protocol
parameter - but we have to try to pretend that they mean the same thing. 
And it will degrade interoperability.

> framework for different organizations and persons to mint their own 

The fact that people want to use URIs in this way does not mean that it's
appropriate to use URNs in this way.  If people want to mint their own URNs,
then they have to follow the rules for URNs.  Those rules *do not* 
permit arbitrary organizations and persons to mint their own identifiers
without explicit delegation from a URN namespace, for very good reasons
which are consistent with URNs' purposes.

The very temptation to treat URNs as if they were as malleable as other 
URIs is part of what makes this proposal dangerous.  Since I think that
URNs *will* be widely misused if they are used for protocol elements, 
I'd far rather have IANA assign ordinary URIs for this - then we will
still get semantic drift but at least it won't dilute the value of URNs.

> syntactic structure in the name.

ISBNs do not have a visible syntactic structure, at least, not an 
obvious one.  But they're quite frequently used to look up book information.
 
> syntactic decomposition of the name.

You should really read up on the CNRI handle system then.  There are a lot
of things I don't like about it but it really was designed to have exactly
this property.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

>way of generating globally unique strings like UUIDs or OIDs.

I still don't see the "harm" here.

Another way to look at this might be:  they all have potentially 
network-retrievable representations, but not all uses depend on being able 
to perform the retrieval.

>many purposes.  (as are the others, it's just that XML is the current

I'm puzzled -- you appear to be arguing my point.  Yes, different syntactic 
frameworks will (in isolation) tend to yields differing semantics.  Yes, 
different syntactic frameworks are better suited for different 
purposes.  But it seems to me that referring different uses to the same 
original definition would help to inhibit that -- and if factors like 
ordering or grouping are significant, then the definition will (hopefully) 
capture that and place constraints on the syntactic contexts for re-use.

>Using URIs for the names of the data elements won't stop that kind of drift.

But not trying to re-use existing definitions seems to be a recipe for 
Balkanization.

Maybe it won't work for all applications, but I think there are a 
substantial number of cases where re-use of existing definitions is a 
reasonable and desirable goal.  I have two ongoing projects for which I 
would really like to see this URN namespace proposal approved:

(a) Distributed storage and analysis of email and other message metadata.

(b) common feature descriptions for IETF/W3C content negotiation efforts.

>The traditional examples are oil and water.

That seems like a non-argument for opposing this proposal.  Even emulsions 
have their uses.

>by not requiring widespread agreement on the media features used.

Come again?  That seems to me to be entirely non-sequitur.  How can other 
people using out stuff dilute its utility?  It is precisely in the nature 
of this proposal that using these URIs would be assenting to the IETF 
definition of their meaning.

>agreement from anyone else.

So we should roll over and play dead, and pretend that interoperability 
doesn't matter?

Actually, that's a misrepresentation of the W3C position, which is that 
vocabularies gain currency through use -- the more people who use them, the 
more useful, and more widely used they become. (Sure, that's a 
generalization.)  This approach seems to be very much in the spirit of the 
IETF I've been participating in over the past few years -- it's not our 
role to decide what will and will not work, but to provide an environment 
in which new technologies can evolve and find currency, and promote 
interoperability wherever we can.

>And it will degrade interoperability.

Er, no:  we *define* them to mean the *same* thing.  If implementations 
play fast and loose with the defined meaning, that's nothing new.

>which are consistent with URNs' purposes.

Ah, that's a misunderstanding.  One of the reasons I favour using URNs in 
this way (and contrary to the often touted W3C position) is that it 
provides a form of URI that is clearly *not* minted by any Tom, Dick or 
Harry working in isolation.  The definition of any urn:ietf:... URI is 
subject to the IETF consensus process, so can be expected to have been 
involved in some level of community review.  My point here was that, 
because they conform to a common URI syntactic framework, they can be used 
interchangeably in some contexts with experimental and private-use 
identifiers.  (In a sense, this might be viewed as a converse of the 
X-header approach:  arbitrary URIs may be treated as experimental or 
private use, unless they are allocated within a URI namespace controlled by 
a recognized authority in the area of their application.

>still get semantic drift but at least it won't dilute the value of URNs.

In what sense are URNs not ordinary URIs?  They have particular 
requirements for persistence that are not shared by all URI schemes.  And 
there is a requirement for "location independence", but what that means 
isn't always clear.

But mainly, the goal of this proposals is emphatically *not* to make URNs 
"malleable" (in the sense of, say, http: URIs which can be reassigned at 
will by domain owners), but to allow the introduction of some URIs that can 
clearly be seen to be stable and persistent.

I'd be happy for IANA to assign "ordinary URIs", assuming that by this you 
mean something like http://www.ietf.org/..., as long as there was a clear 
organizational commitment that such a URI, once allocated, would never be 
reallocated for any other purpose.   It's the particular properties of URNs 
that are desired here, not any sense that they are somehow a "special" form 
of URIs.

>obvious one.  But they're quite frequently used to look up book information.

I understand that ISBNs aren't persistent -- they get reused.  How many 
books are "in print" at any time?  I don't think this is quite Internet scale.

Anyway, ISBN's *do* have an internal syntactic structure.  From 
http://www.isbn.org/standards/home/isbn/us/isbnqa.asp#Q4:

[[
Does the ISBN have any meaning imbedded in the numbers?

The four parts of an ISBN are as follows:
Group or country identifier which identifies a national or geographic 
grouping of publishers;
Publisher identifier which identifies a particular publisher within a group;
Title identifier which identifies a particular title or edition of a title;
Check digit is the single digit at the end of the ISBN which validates the 
ISBN.
]]

>of things I don't like about it but it really was designed to have exactly

Based on a December 2001 article 
(http://www.dlib.org/dlib/december01/blanchi/12blanchi.html), it seems to 
me that Handles too depend on some syntactic structure to partition the 
search space -- based on dynamic content types and metadata schema.  (I 
should be clear that I'm using the term syntactic structure in an abstract 
sense, a la McCarthy 
(http://www-formal.stanford.edu/jmc/towards/node12.html#SECTION000120000000000000000), 
rather than in the sense of a specific arrangement of characters.)

Ah yes, and according to the internet draft on handles:
   http://www.ietf.org/internet-drafts/draft-sun-handle-system-09.txt
there *is* a clear syntactic structure:
[[
  2. Handle Namespace

     Every handle consists of two parts: its naming authority, otherwise
     known as its prefix, and a unique local name under the naming
     authority, otherwise known as its suffix. The naming authority and
     local name are separated by the ASCII character "/". A handle may
     thus be defined as:

       <Handle> ::= <Handle Naming Authority> "/" <Handle Local Name>
  ]]
How each naming authority deals with scaling within its domain of authority 
doesn't seem to be specified.

(Actually, when I wrote the above, I later realized that I misspoke 
slightly, because some systems work in constrained contexts -- I was 
referring to systems operating at global Internet scale without further 
contextualization.  But I think the general idea still holds here -- if you 
want to reliably and quickly dereference an identifier with Internet scope, 
it cannot be completely opaque.)

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 10:57:38 -0400

Keith

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

> I still don't see the "harm" here.

basically, it's trivializing them.  they're overkill for this purpose, and
using URns for this purpose makes them seem less useful than they really
are.  

that, and I think there'll be a very strong demand for them to be human-readable 
(i.e. to have visible structure) and syntactically derivable from the canonical 
name for the protocol elements (for those that have such names).

> capture that and place constraints on the syntactic contexts for re-use.

I just don't happen to share your faith in this as a mechanism to inhibit
or discourage semantic drift.  In every example I can think of where one
data model is exported into a different context there has been semantic
drift, even when the same names and official definitions were retained.
(maybe there's less drift this way, maybe not - but it certainly doesn't
inhibit drift)

> But not trying to re-use existing definitions seems to be a recipe for 

I don't know how to avoid Balkanazation.  Sometimes it seems better to
let data models fork rather than to try to reconcile various differences -
I'd cite RFC822, usenet, HTTP, and SIP as a good example of things that
we shouldn't pretend have the same protocol elements even though
we recognize that they share a common ancestry. 

> reasonable and desirable goal.  

I don't claim that re-use of a data model is not potentially useful.
If nothing else, an existing data model can serve as a useful starting 
point for a new data model when the requirements or syntactic structures
dictate not using the old one.

But neither do I want to give official blessing to folks to re-cast 
traditional IETF protocols into new syntactic forms.  And a lot of
the interest I've seen in having URI equivalents for IETF protocol
parameter names was from people who wanted to do just that - often
with the explicit intent of producing variant implementations in order
to disrupt the installed base.  

> definition of their meaning.

no it's not, because of the semantic drift that will occur.   

Someone once tried to demonstrate to me that it was perfectly reasonable
to express iCalendar events in XML - but her demonstration used XML's 
date representation which didn't have a proper concept of timezones.  
Interpretation of dates in iCalendar were dependent on a separate timezone
element, whereas the XML tool wanted to treat those dates as standalone.
so the "obvious" conversion of iCalendar to XML - even though the elements
mapped one-to-one - caused semantic drift and a loss of important 
functionality.

> So we should roll over and play dead, and pretend that interoperability 

It's not clear that doing things the w3c way helps interoperability.

> more useful, and more widely used they become. 

That's true to a point, but it also seems to be the case that controlled
vocabularies that need to have consistent meaning across large groups
need very careful definition and, well, "control".  Natural languages,
by contrast, tend to drift continuously.  Sometimes that's useful, but
perhaps not as useful for computer protocols as for humans that can
intuitively accomodate a certain amount of semantic skew.

> play fast and loose with the defined meaning, that's nothing new.

At the same time, by explicitly exporting them we are encouraging 
semantic drift.  

> requirements for persistence that are not shared by all URI schemes.  

In order to make a URN persistent you really need to make them opaque 
(or mostly so) to humans.   It's really too bad that we even allowed
URN namespace IDs to be human-meaningful, but that's water under the bridge.

> I understand that ISBNs aren't persistent -- they get reused.  

They're not supposed to be, but it does happen in some countries - 
particularly those with less ISBN space allocated to them.  
So we have a NAT-like problem for ISBNs ...

> Anyway, ISBN's *do* have an internal syntactic structure.  

I didn't say they didn't have one, I just said it was not obvious.

> search space -- based on dynamic content types and metadata schema.  

Handles have evolved a bit since first envisioned - as I understand it the 
problem wasn't the inability of the non-partitioned search service to scale 
up to the number of queries but rather the difficulties associated with
everybody trusting a centrally maintained flat search service.

Someone from cnri might be able to fill in more detail.

> there *is* a clear syntactic structure:

Yes, but the searching isn't (didn't used to be) federated according to that
structure.  The scalability of the searching didn't depend on it - 
federating actually slowed things down unless you happened to consult the 
right server first.  (locality does affect search speed)

> But I think the general idea still holds here -- if you 

Hashing is faster than tree searching, especially if the tree is distributed.
you federate the lookup because of trust issues (which are a kind of scaling
issue, but not in terms of bandwidth or cpu cycles) and ease-of-cost-recovery 
issues, not to make the lookup more efficient or cheaper.

Keith

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Graham Klyne <[email-masked]>
Date: Wed, 03 Jul 2002 19:07:41 +0100

[[

#g

-------------------
Graham Klyne
<[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

we could bat these arguments back and forth without making any further 
progress.  I think I have real use-cases for this proposal for which the 
concerns you raise just don't seem to be a problem.  On the other hand, I 
can recognize a legitimate concern with:

[[
]]

I think a more constructive way forward would be to work on an appropriate 
form of words indicating the concerns and purposes for which these IETF 
URNs SHOULD NOT be used.

I perceive that your concerns relate mostly to attempts to transplant 
entire protocol structures from one framework to another, and in those 
cases I agree that it is difficult to transfer all the semantics 
faithfully.  But this proposal is aimed more at using information about 
protocol elements, the kind of detail that is described in a registry 
entry, into a different application environment.

Examples:

IETF CONNEG and W3C CC/PP have quite different overall structure and 
semantics, but they can still usefully employ common media feature 
definitions.  This is clearly not an attempt to recast CONNEG into XML, but 
it seems highly desirable to not end up with two almost parallel sets of 
media features when just one set would do fine.

My other example, which may seem closer to your concern but which really is 
not, is to do with storing and processing message metadata.  Here, I want 
to be able to use URIs to identify the various header fields that appear in 
a message.  Again, the goal is not to re-cast an IETF protocol in a 
different form, but to take information from an IETF protocol for use in a 
different application.

#g
--

PS:  as far as I can tell, according to 
http://www.ietf.org/internet-drafts/draft-sun-handle-system-def-05.txt (for 
which I saw the announcement after sending my previous message), the handle 
system does operate federation of naming authorities:

         <Handle>          = <NamingAuthority> "/" <LocalName>

         <NamingAuthority> = *(<NamingAuthority>  ".") <NAsegment>

         <NAsegment>       = 1*(%x00-2D  /  %x30-3F / %x41-FF )
                           ; any octets that map to UTF-8 encoded
                           ; Unicode 2.0 characters except
                           ; octets '0x2E' and '0x2F' (which
                           ; correspond to the ASCII characters '.',
                           ; and '/').

         <LocalName>       = *(%x00-FF)
                           ; any octets that map to UTF-8 encoded
                           ; Unicode 2.0 characters

and:

     Naming authorities are defined in a hierarchical fashion resembling
     a tree structure. Each node and leaf of the tree are given a label
     that corresponds to a naming authority segment (<NAsegment>). The
     parent node represents the parent naming authority. Naming
     authorities are constructed left to right, concatenating the labels
     from the root of the tree to the node that represents the naming
     authority. Each label (or its <NAsegment>) is separated by the
     character '.' (octet 0x2E). For example, the naming authority for
     the Digital Object Identifier (DOI) project is  "10". It is a root-
     level naming authority as it has no parent naming authority for
     itself. It can, however, have many child naming authorities, e.g.,
     "10.1045" which is used as a naming authority for D-Lib Magazine.

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Wed, 03 Jul 2002 17:02:11 -0400

Keith

---

From: Graham Klyne <[email-masked]>
Date: Thu, 04 Jul 2002 00:34:49 +0100

Keith,

[[
]]

Examples:

#g
--

         <LocalName>       = *(%x00-FF)

and:

-------------------
Graham Klyne
<[email-masked]>

---

From: Wonko_The_Sane <[email-masked]>
Date: Fri, 05 Jul 2002 00:15:08 -0700

****.   the ietf listbot needs some multicopy spam deletion tool..

---

From: Michael Mealling <[email-masked]>
Date: Mon, 8 Jul 2002 10:08:34 -0400

On Wed, Jul 03, 2002 at 05:02:11PM -0400, Keith Moore wrote:
> <snip>

Sorry to have not been involved in the disucssion. Vacation and all..

Based on the discussion with Graham I am at a loss as to how to fix
the document to satisfy your concerns. It seems that most of your
concerns are more to do with the entire W3C promoted web architecture
than with anything in particular with this proposal other than the
desire for the individual syntactic elements to be as semantically
free as possible.

Is there anything that can be done to fix this document or are you
opposed to even the intended purpose of it?

-MM

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 08 Jul 2002 17:10:28 +0200

note that I (for one) don't think the particular concerns raised by Keith 
need fixing - the description of an URN that Keith seems to have in mind 
seems to me to fit well with certain types of URN (such as urn:isbn), but 
there seems to me no reason to expect all URNs to behave the same way in 
the aspects we are talking about here (whether there exists a 
dereferenceable entity to which the URN can be resolved, for instance).

I think using URN is a better solution to the problem the W3C seems to 
regard as important than using HTTP URLs for the same purpose.

                     Harald

--On mandag, juli 08, 2002 10:08:34 -0400 Michael Mealling 
<[email-masked]> wrote:

> -------------------------------------------------------------------------
> ------- Michael Mealling	|      Vote Libertarian!       | urn:pin:1
> [email-masked]      |                              |
> http://www.neonym.net
>
>
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 08 Jul 2002 17:30:43 -0400

> desire for the individual syntactic elements to be as semantically

I do have reservations with IETF endorsing the "W3C promoted web 
architecture" and this proposal seems (deliberately or not) to be 
encouraging us to move in that direction.

> opposed to even the intended purpose of it?

I can see utility in this proposal.  I can also see it causing problems.  
I don't know how to get the utility without introducing the potential
for problems.  Some proposals are like that.

I did include some concrete suggestions along with my original comments
that I thought would improve the document, and that I hope IESG 
(and you) will consider.

Graham also made at least one suggestion I thought was valuable (there
may have been others that I don't recall offhand) - that the document
contain an explicit statement saying that these URIs are not to be used
for the purpose of translating existing protocols into XML, or at least,
that such a practice is nonstandard and discouraged.  (I don't recall 
his exact wording, but something like this could be very helpful.)  

I continue to believe that if people want to import protocol elements 
from an IETF protocol for use in another protocol that the proper
way to do this is to write an document about it, describing how those 
data elements are used in the new context and (if appropriate) assigning 
new names or URIs for those protocol elements -- NOT to assume that the
model can be imported into (say) XML merely by giving each protocol element
a URI without any change (intended or not) to the semantics of those
protocol elements.

Keith