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

Accidentally sent to the request address first time, apologies to Julian
who gets to see this twice...

-------- Original Message --------
Subject: Re: Chopan - Compressed HTTP Over PANs
(draft-frank-6lowpan-chopan-00)
Date: Tue, 14 Jul 2009 11:36:51 +0100
From: J Ross Nicoll <jrn@jrn.me.uk>
To: Julian Reschke <julian.reschke@gmx.de>
CC: ietf-http-wg-request@w3.org
References: <4A5C34BA.2070108@gmx.de>

Agreed, this looks like it would be far better suited as an HTTP-like
protocol, supporting key functionality, rather than trying (and failing)
to actually implement all of HTTP. Personally I'm unconvinced that any
sensor so limited in functionality that it needs to use a reduced HTTP
alternative for communication is going to be able to do anything
meaningful with the data moved around...

Also, this appears to be yet another protocol that uses UDP and then has
to work around the lack of TCP features (reliable delivery, in-order
delivery) it needs...

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 11:20:21 UTC