Hi Julian,
At 07:14 28-10-2013, Julian Reschke wrote:
Yes -- this is not necessarily a problem. There are many things that
need to be defined for a new method, and not all of these fit into
the template.
A DISCUSS about this can be easily addressed. :-)
What is the intent behind the HTTP Method Registry (Section
8.1.3)? What information should that registry convey to the
reader? For example, is it a quick way for the reader to find out
whether POST is cacheable (re. a choice that a browser vendor made
some time back) or should the person read the relevant specification
text to get accurate answer?
That's an assumption that is true for all "bare" Section references.
The problem is that people copy and paste them blindly. I suggest
having information in the tables as the working group would like it
to appear in the registry
The IANA Considerations are processed by the RFC Editor and IANA,
and they will make sure that the registry is properly populated.
There's no point in mentioning a still unknown RFC # here.
It is up to the Responsible Area Director and the the document
shepherd to make sure that the registry is properly populated.
What, precisely?
I suggest adding "RFC XXXX" in the tables. I read
draft-reschke-http-status-308-07. The reference is similar to what
is in draft-ietf-httpbis-p2-semantics-24. They are two different
drafts and that makes referencing only the sections ambiguous. RFC
6585 updated the HTTP Status Code registry last year. The current
registry format only references the RFC number. I suggest making the
change clear so that, in some distant future, someone working on this
can figure out the details of the registry.
Regards,
S. Moonesamy