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

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
> 
>     
> 
>

Received on Tuesday, 14 July 2009 10:48:57 UTC