using http URIs to name IETF protocol elements [was: TB16]

On Tue, 2002-07-02 at 09:49, Michael Mealling wrote:
[...]
> > >But the TAG should also realize that there are many 
> > >cases where dereferenability of namespace names is exactly _NOT_ what the
> > >system being designed wants to happen.
> > 
> > The only plausible example of this that I've seen is that of 
> > highly-transient per-transaction namespaces that exist only briefly. 
> > Can you think of any others?  
> 
> Yes. The IETF has made very specific decisions not to turn the IANA's
> web resources into a directly downloadable schema repository.

I'm interested in records of those decisions. I told the TAG
I'd ask you for them...

"Section 1.1.1 Social expectations for URI persistence

[...]

    Action DC: Ask Michael Mealing when IETF decided not to use HTTP
URis to name protocols."

  -- http://www.w3.org/2002/07/08-tag-summary#arch-doc

If the decision entails not using http: URIs for IANA
things, then I disagree with it. I consider myself
a member, i.e. a participant, in the IETF, and I'm
disappointment that the consensus process seems
to have failed. I'm interested to know
what sort of last calls and such I should have been paying
attention to in order to voice my disagrement before
the decision was made.

> That's
> why we created the 'ietf' URN namespace and are putting permanent
> references to IANA registry entries there instead of making 'iana.org'
> follow the w3.org example. We _don't_ want things failing becuase
> the IANA decided to re-arrange its website. That's called a single
> point of failure and its _not_ what the Internet is supposed to have.

Using HTTP does not introduce a single point of failure.

The IETF is trusted to manage the names whether they
look like http://www.ietf.org/... or urn:ietf:...
There's no technology that can prevent the IETF from
re-assigning a urn: ; only policies and other
social mechanisms.

I suggest that there's more reason to trust the IETF
to manage the http: names, because more people are likely
to notice and hold them accountable if they screw them up.

The answer to "things failing because the IANA
decided to re-arrange its website" is: don't do that.
In fact, promise not to do it... in an standards-track
RFC, if that's the sort of guarantee you trust.

You don't have to promise to keep your web site running
forever, since, as you said, the relevant technologies
don't depend on availability of servers to dereference
the URIs; you just have to promise not to use those
names for anything else.

As to the lack of a guarantee
that IANA/IETF actually owns iana.org/ietf.org, that seems at
least as manageable as any of the other relevant risks.
i.e. as long as the world cares about IANA,
they'll keep following the existing links to iana.org,
and as long as IANA cares about the world,
they'll continue to service those links.

I don't see any guarantee that the same sorts of trademark
disputes that cause friction in DNS space won't cause
friction in URN NID space. When zillions of dollars
are at stake, McDonald's is not going to let a few
RFCs stop them from undoing a registration for
urn:mcdonalds:bigmac by some unauthorized party.


As explained by Prescod in his reply of 02 Jul 2002 08:58:09 -0700,
the names
  http://www.w3.org/1999/XSL/Transform
  http://www.w3.org/2001/XMLSchema
have all the characteristics of persistence, uniqueness,
and unambiguity of urn:ietf:... names, but
as a special bonus aside, if you happen to find to find

	<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform>
		...

in a document, and you've never heard of XSLT, you can pop
that URI into any of millions of installed web browsers
and find out all about XSLT.



                          | http://www.neonym.net
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Friday, 12 July 2002 13:43:17 UTC