W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: #364 Capturing more information in the method registry

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Wed, 04 Jul 2012 11:10:36 +1200
To: <ietf-http-wg@w3.org>
Message-ID: <c72916331395d92fb9e2291730bb094e@treenet.co.nz>
On 03.07.2012 19:28, Julian Reschke wrote:
> On 2012-07-03 04:24, mike amundsen wrote:
>> +1 on listing idempotent. this is _critical_ in assessing the 
>> use/impact
>> of a method. I'm not clear why it's left off the listing.
>> ...
> Anything in the registry beyond the pointer to the defining
> specification is just a shortcut; just because it's not in the
> registry doesn't mean it's not there.
> Adding new fields is possible, but we need find a balance; also, it
> requires deciding on the value for all methods in the list, which 
> also
> doesn't come at zero cost :-)
> Best regards, Julian

FYI: I made that comment at the point of writing a parser to handle 

Having just read may way through 2 WebDAV and 2 HTTP RFC and re-read 
the HTTPbis drafts, your post came as a bit of a non-surprise to find 
there were more RFCs which I now have to read just to find out if the 
methods listed are idempotent and/or cacheable.

Having a quick reference safe=yes/no, idempotent=yes/no would greatly 
assist writing parser that treated these methods as safe or idempotent 
without having to read/support every RFC on the block.

An indication of cacheability would also be great, yes/no/conditional 
kind of thing. Something to indicate if we proxy authors actually have 
to read the RFCs in question for correct interoperable behaviour when 
handling the method. Otherwise the method is going to get left on the 
"other" pile and not be supported fro a longer time. Which is a shame 
for new cacheable method responses.

Just the core considerations requested for new methods. Since those are 
the details we have already as a WG identified as important/critical for 
HTTP software implementing the method to be aware of.

Received on Tuesday, 3 July 2012 23:11:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:04 UTC