- From: Julian Reschke <julian.reschke@greenbytes.de>
- Date: Wed, 30 Oct 2013 09:48:18 +0100
- To: S Moonesamy <sm+ietf@elandsys.com>, apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org
- CC: ietf-http-wg@w3.org, ietf@ietf.org
On 2013-10-30 06:24, S Moonesamy wrote: > 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? The template only contains a subset of the information, so in general, the reader will have to read the referenced RFC. The entries in the template serve the purpose of shortcutting this lookup for considerations that can be answered with a simple "yes" or "no". >> 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. And the authors during AUTH48. There is no problem here. We will make sure that the registry gets populated properly. Trust me. > ... Best regards, Julian
Received on Wednesday, 30 October 2013 08:48:43 UTC