Proposed language change for Hansen 2717/2718

My primary concern with the Hansen 2717/18 draft as written is the
inability to assure registration of a unique scheme token in the URI
namespace at the beginning of the innovation cycle, that is, at the time
a scheme is registered as a provisional scheme.

I believe the following proposed changes would rectify this problem with
a minimum of difficulty and without recourse to the additional scheme
classification I have proposed before.

On Page 7 of 2717/18, it says:

   "The main requirement for a provisional URI Scheme is that there MUST
NOT already be a corresponding permanent entry with the same URI scheme
name.  In cases where separate communities have already established
differing uses of the same URI Scheme name for different purposes, it is
possible to have two or more provisional registrations for the same URI
scheme name."

I propose this wording be altered to read as follows:

   "The main requirement for a provisional URI Scheme is that there MUST
NOT already be a corresponding 'permanent' or 'provisional' entry with
the same URI scheme name.  In cases where separate communities have
already established differing uses of the same URI Scheme name for
different purposes, it is possible to have two or more provisional
registrations for the same URI scheme name.  Such inadvertant
duplication is contradictory to the purposes of URI schemes, and is one
of the motivations for this RFC.  The URI registry will acknowledge
these duplicates, but no additional duplicate registrations will be
accepted in the URI registry following acceptance of this RFC.  Further,
existing duplicate registrations are unsuitable for promotion to
permanent status without resolution of the URI scheme name duplication
problem."

On page 8 of 2717/18, it says:

Upon receipt of a URI scheme registration request, IANA:
   1.  Checks the submission for completeness; if sections are missing
       or citations are not correct, IANA rejects the registration
       request.
   2.  Checks the current registry for a 'permanent' entry of that name;
       if such a registry exists, IANA rejects the registration request.
   3.  Adds the registration to the 'provisional' registry.


I propose this wording be altered to read as follows:

Upon receipt of a URI scheme registration request, IANA:
   1.  Checks the submission for completeness; if sections are missing
       or citations are not correct, IANA rejects the registration
       request.
   2.  Checks the current registry for a 'permanent' or 'provisional'
entry of that name;
       if such a registration exists, IANA rejects the registration
request.
   3.  Adds the registration to the 'provisional' registry.












-----Original Message-----
From: Larry Masinter [mailto:LMM@acm.org] 
Sent: Wednesday, February 09, 2005 12:01 PM
To: Weibel,Stu
Cc: 'Tony Hansen'
Subject: RE: Requirements and assumptions for a managed URI namespace

 

> -----Original Message-----
> From: Weibel,Stu [mailto:weibel@oclc.org]
> Sent: Wednesday, February 09, 2005 7:15 AM
> To: Larry Masinter
> Subject: RE: Requirements and assumptions for a managed URI namespace
> 
> Hi, Larry,
> 
> I have no deep commitment to my proposal, other than as an 
> illustration of how the functional requirements can be met.

We have a proposal on the table, and are asking someone to propose and
defend alternatives.  Frankly, I think the proposal we have on the table
meets your requirements and you haven't read it carefully.


> I can support any system that provides a tractable approach to 
> sustaining full-strength URI schemes while providing for an innovation

> path that can assure unique tokens for experimental schemes, at least 
> for some period of time.
> 
> What I cannot support is a system where a new scheme must be proposed,

> justified, deployed experimentally, and brought through the approval 
> process (2 years or more?), all without any protection against 
> inadvertant or malicious name duplication.

Is the draft really unclear? Where in draft-hansen-etc does it say that
a new scheme must be justified and deployed experimentally before it can
get a permanent registration? Where does it say that the approval
process takes 2 years? The goal of draft-hansen-etc is to reduce the
overhead, time, and uncertainty in the process.

> I guess I am unclear about your two-registry idea, and the status of 
> the documents vis a vis their review requirements.  Perhaps I've lost 
> track of what your position is currently?

http://www.ietf.org/internet-drafts/draft-hansen-2717bis-2718bis-uri-gui
delines-02.txt

as modified by 

http://lists.w3.org/Archives/Public/uri/2005Jan/0054.html

I was going to incorporate Roy's comments in a new draft, but I've been
waiting until the discussion you initiated had come to some conclusion
before doing so.  Now that I understand that your concern is the length
of the review before a permanent registration is accepted, I think we
can just address that directly, and come up with a new draft. I'll work
on that this weekend.

Larry

Received on Wednesday, 9 February 2005 18:20:11 UTC