Re: Chopan - Compressed HTTP Over PANs (draft-frank-6lowpan-chopan-00)

This reminds me very much of the long-running discussions (and that's  
being polite) of Binary XML in the W3C.
   http://www.w3.org/XML/Binary/
   http://www.xml.com/pub/a/2003/08/13/deviant.html

Making an interchangeable binary representation of a flexible text- 
based format that beats gzip on size with full fidelity is a high bar.

"Inspired by HTTP" may indeed be a more reasonable goal.

Cheers,


On 14/07/2009, at 8:48 PM, Jim Gettys wrote:

> Those of you with memory of my role in HTTP may find the following  
> comments surprising, but bear with me.
>
> Doing something like this has to pass test, in my mind:
>  o that it be shown to be significantly more compact than HTTP +  
> deflate style compression (probably with a pre-defined dictionary,  
> and canonicalization of cases of strings to minimize the size of the  
> dictionary).  Ad-hoc binary compression systems are often/commonly  
> not less efficient than what gzip style compressors can do.  (to  
> remind the audience, deflate is gzip without some preamble  
> information; and IIRC, it can be used with a predefined dictionary,  
> so you don't have to transmit said dictionary first when you know  
> the material being compressed).
>  o that it (by such actions) remain fully compatible with HTTP.
>
> This is much easier than having yet another HTTP parser lying around  
> which isn't quite HTTP, with ad-hoc, non-extensible coding of HTTP  
> to a fixed vocabulary.
>
> Now, if the needs/goal are for much better compression than what you  
> get that way, you really need to go beyond HTTP as a framework,  
> where information in common across a sequence of requests is  
> transferred in the first request and used in later requests (a  
> statefull protocol, at least for the length of the conversation).   
> But then it isn't HTTP anymore, but maybe "http style", and you  
> don't have constraints.  Of course, you then have other questions  
> people will ask you, when you are really different...
>                            - Jim
>
>
> Julian Reschke wrote:
>> I just looked at
>>    <http://tools.ietf.org/html/draft-frank-6lowpan-chopan-00>
>> and I'm a bit concerned by the fact that this essentially profiles  
>> HTTP.
>> For instance, it makes it impossible to use HTTP extensions that  
>> use "new" method names or status codes. Profiling like this has  
>> been a concern in the past, such as when the Atom WG discussed  
>> whether it could rely on DELETE and PUT due to restricted  
>> implementations/mappings that would only allow GET and POST -- so  
>> the problem may not be apparent right now considering deployed HTTP  
>> applications, but it will once people want to do new things.
>> In particular (just from a quick reading):
>> - HTTP extension methods not supported
>> - some standard headers are restricted in what they can carry  
>> (ETag, Cache-Control)
>> - some headers are listed as "standard", but do not seem to be  
>> registered ("Awake-Time"?)
>> - new headers are allowed to be stripped (that closes an important  
>> extension point)
>> I can see why the compression is optimized for common HTTP  
>> features, but it really shouldn't make extensions hard or impossible.
>> Best regards, Julian
>>
>
>


--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 15 July 2009 06:41:27 UTC