Re: New issue: Need for an HTTP request method registry

Adrien de Croy <adrien@qbik.com> writes:
    
    in principle I agree.
    
    However I would strongly caution against the proliferation of methods.
    
Agreed.

Note, however, that IANA registries are established at
http://www.iana.org/numbers.html as a triple of

   (registry, defining-rfc, Registration/Assignment Procedures)

There are a number of possibilities for "Registration/Assignment
Procedures".  For example, the HTTP content-coding registry
is "First Come First Serve with specification recommended"
whereas others require review or approval, such as "IETF consensus"
or "Expert review".  I believe that BCP26/RFC2434 ("Guidelines for
IANA Considerations") is the latest document that defines how
this works; it suggests a set of example policies, but I think
BCP26 also allows inventing a new policy.

I suggest that the HTTP-methods registry set this policy from
BCP26:

      Standards Action - Values are assigned only for Standards Track
           RFCs approved by the IESG.

           Examples: MIME top level types [MIME-REG]

This would probably prevent much in the way of new methods;
it might even slow things down too much for some people's
tastes.

By the way, I'm strongly in favor of a registry, since it
does provide unambiguous documentation.  It might be useful
for the registry's scheme to include a field such as
"core" or "non-core" (or perhaps with more values possible)
so that implementors have some guidance as to which are
mandatory to implement.

-Jeff

Received on Wednesday, 8 August 2007 23:48:12 UTC