RE: Proposed Status Categories for URI Scheme registry

I am reviewing Stu Weibel's proposal's permanent, provisional, and
vernacular vs. draft-hansen-2717bis-2718bis-uri-guidelines-02.txt's
permanent and provisional. My impression after reviewing the differences
is that weibel-vernacular is most like hansen-provisional, and
weibel-permanent and weibel-provisional are most like two levels
within hansen-permanent:

>    Documented by 
          weibel-permanent: Standards Track RFC
          weibel-provisional: at least an Informational RFC
          weibel-vernacular:  unspecified (none | author-managed |
                                  community-managed...)
          hansen-permanent: Any RFC status (if IANA considerations
              call for permanent registration)
          hansen-provisional: IANA template
          

That is, both weibel-permanent and weibel-provisional have
a more stringent requirement for publication than hansen-permanent.
I'm not sure why, though. I believe that approval for publication
of any RFC with an 'IANA considerations' section is a sufficient
gate for insuring that the IANA registered values have been evaluated
by the process required for membership in that IANA registry, and
that further distinction based on standards-track status of the
document is not required. And weibel-vernacular allows registration
without even an IANA template being filled out, making the
registry not particularly useful.


>    Technical Review
         weibel-permanent: Must pass "full technical review"
         weibel-provisional: Must pass "provisional technical review
           (details and scope open to discussion)"
         weibel-vernacular: No review required, may have wiki-comments
         hansen-permanent: Must pass 'technical review'
            against the criteria in the draft.
         hansen-provisional: no technical review required
            
I'm not sure what difference were in mind for a "provisional technical
review". Draft-hansen tries to lay out what the technical criteria
are for URI schemes so that the "technical review" can be judged
against something other than personal preference. If you think that
the criteria laid out in draft-hansen are too stringent for some
URI schemes, let's discuss which criteria should be removed or
changed. I'm not in favor of having two sets of criteria, one for
"provisional" and one for "permanent", and I am not in favor of having
a "technical review" without an explicit set of criteria for 
that review. At least, this is something we were trying to fix
in hansen-, and part of the reason for combining 2717 and 2718. 

>    Unique token 
      weibel-permanent: assured
      weibel-provisional: assured
      weibel-vernacular: not assured
      hansen-permanent: assured
      hansen-provisional: not assured

I think this was the area that caused the most concern on the
mailing list, but the proposals aren't so significantly different
here. hansen- requires unique tokens for permanent registration
and not for others.


>    Revision authority
       weibel-permanent: rests with IETF
       weibel-provisional: with author or designated organization
       weibel-vernacular: (not specified)
       hansen-permanent: rests with IETF
       hansen-provisional: "the owner" (section 3.4)

I am uneasy with weibel-provisional requiring some level
of review, but then allowing unreviewed changes. Is the
concern that the IETF might make changes that the author
doesn't approve of? Or that the author can't make changes
that the author doesn't like?

 
    
> Annotation:
    weibel-permanent: (nothing specified)
    weibel-provisional: Registration records openly annotatable 
         (wiki-like public comment)
    hansen-:  (not explicit; mailing list comments allowed)

I'm uneasy about a technical review process ("registration records
openly annotatable (wiki-like public comment)" that requires technology
not currently part of IETF repertoire. My experience with blogs
and web sites that have completely open, unmanaged public comment
sections is that they are as susceptible to spam as email lists
are.  

I agree with the idea that public IETF documents might have a mechanism
for serious technical review after their publication, but I don't
think this is the forum to innovate in such areas (I suggest the
NEWTRK and IETF-Tools-discuss list).

Perhaps without specifying the mechanism for public comment, we could
at least specify the criteria for when the IETF should publish
something that arrives as a "public comment"?

Promotion:
    weibel
      weibel-permanent must have demonstrated usefulness as
      weibel-provisional scheme prior to technical review
    hansen
      hansen-provisional may be promoted to hansen-permanent

I think requiring that schemes MUST be registered in a different category
before reaching 'permanent' status is unnecessary. If desired, the
registration can be updated through standards track, but I don't think
it should be a required part of the registration process; it just
makes it too complicated. It would seem that once something was
registered as weibel-provisional, no one would ever bother with
weibel-permanent.

Received on Monday, 24 January 2005 04:18:57 UTC