RE: Addressing the name speculation problem

[This message starts as a refutation, but develops into a new proposal...]

At 14:48 15/02/05 -0500, Weibel,Stu wrote:
>Dan, you say you don't understand why the current proposal is not
>workable... I don't understand why anyone on this list thinks that
>leaving the uniqueness of URI tokens as indeterminate is an acceptable
>position.  As has been pointed out many times (and left unrefuted), it
>leaves any legitimate URI proposal subject to accidental or intentional
>damage, and it FAILS to guard against the possible problem of name
>squatting.

OK, I shall refute this.  At heart, I think you underestimate the good 
sense of the community, without which we would not have seen the kind of 
progress that is evident in development of the Internet ands the Web.

(I write from the perspective of the message header registry design, which 
I understand was used as a model for this proposal for URI schemes.)

The purpose of a provisional registration is to *document* an idea, not of 
itself to create a precedent for its use.  This may apply to a new proposal 
or to an existing in-the-wild scheme.  In the first instance, simply by 
spreading knowledge of such a scheme, other developers are warned off using 
that token for an incompatible purpose, because by so doing they make 
future problems for themselves.  Also, it encourages developers to 
cooperate rather than to compete.  My experience is that when developers 
become aware that others are working on similar ideas, they *do* 
compete.  The proposed concession of making uniqueness of provisional 
registration a SHOULD gives the reviewing community enough clout to push 
back on any proposed duplicate, so any new proposal with a duplicate name 
(as opposed to documentation of existing practice) can be resisted.  It is 
also made quite clear that existence of a provisional registration is not 
an endorsement, and is not of itself an encouragement to use such registration.

So, when it comes to the point that some part of the community recognizes 
the value of a proposal, and it has not been shown to be flawed, and 
participants propose to put significant effort into implementation and 
deployment, then the appropriate action is to request permanent 
registration.  In the case of the message header registry, this does not 
require taking the proposal to standards track, but I note that in the 
docvument under discussion, there is this text:
[[
    Permanent status is intended for use by IETF standards-track
    protocols.  The status requires a substantive review and approval
    process.
]]
-- 
http://www1.ietf.org/internet-drafts/draft-hansen-2717bis-2718bis-uri-guidelines-02.txt

I suggest that this be relaxed, so that the requirement for permanent 
registration becomes "publication as RFC or open standard", as it is for 
message header fields:
[[
    A header registered in the Permanent Message Header Field Registry
    MUST be published as an RFC or as an "Open Standard" in the sense
    described by RFC 2026, section 7 [1], and MUST have a name which is
    unique among all the registered permanent field names that may be
    used with the same application protocol.
]]
-- http://www.ietf.org/rfc/rfc3864.txt

In suggesting this, I note that I have effectively supported your earlier 
proposal for a 3-stage registration process:
(1) provisional registration
(2) permanent registration, non-standard
(3) permanent registration, standard-track

So the bar to permanent registration is RFC publication, which effectively 
ensures that frivolous proposals don't get to spoil the waters, while 
remaining sufficiently lightweight that I think your concerns for 
developers can be mitigated.  I would anticipate that entry into the 
permanent registry would be accomplished at any time after RFC publication 
is approved, avoiding any concerns of RFC publication delays.

I think this approach steers an appropriate course between control and 
freedom to innovate, has the advantage of being simple to operate, and 
requires minimal change to the document under discussion.

#g


------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 14/02/05

Received on Wednesday, 16 February 2005 09:44:01 UTC