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

Re: #343: chunk-extensions

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 13 Feb 2012 15:13:00 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <8C4A5D1D-75B0-4FE7-9FE8-0F6E7C292AE0@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>
Assigning for -19.


On 08/02/2012, at 7:49 PM, Julian Reschke wrote:

> On 2012-02-07 21:46, Mark Nottingham wrote:
>> 
>> On 08/02/2012, at 7:26 AM, Julian Reschke wrote:
>> 
>>> On 2012-02-07 20:46, Mark Nottingham wrote:
>>>> Now<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/343>.
>>>> 
>>>> 
>>>> On 07/02/2012, at 12:03 PM, Mark Nottingham wrote:
>>>> 
>>>>> Right now, this is all we say about chunk-extensions (beyond the BNF, etc.):
>>>>> 
>>>>>>   All HTTP/1.1 applications MUST be able to receive and decode the
>>>>>>   "chunked" transfer-coding and MUST ignore chunk-ext extensions they
>>>>>>   do not understand.
>>>>> 
>>>>> Since this is an extensibility point, we should give guidance on how it should be used.
>>>>> 
>>>>> I can't really see establishing a chunk-extension registry; they don't have any semantic, and AFAIK haven't really been used in anger.
>>>>> 
>>>>> What do people think about adding advice along these lines:
>>>>> 
>>>>> """
>>>>> Use of chunk-extensions by senders is deprecated; they SHOULD NOT be sent and definition of new chunk-extensions is discouraged.
>>>>> """
>>>>> 
>>>>> ?
>>> 
>>> Works for me.
>>> 
>>> A future generation of HTTP spec authors can un-deprecate when needed :-)
>> 
>> 
>> $DIETY have mercy on their souls.
>> ...
> 
> :-)
> 
> Proposed change: <http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/343/343.diff>
> 
> Best regard, Julian
> 

--
Mark Nottingham   http://www.mnot.net/
Received on Monday, 13 February 2012 04:13:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT