Chopan is not within the scope of IETF 6lowpan – which is working on networking related issues. It fits more into the new 6lowapp standardization effort we are starting right now, and the draft was contributed there as well.

True, breaking end-to-end semantics by compressing HTTP at a proxy has some problems. This is one way of trying to solve the problem at hand. The reality is that HTTP/TCP as is won’t do it over 6lowpan and for minimal embedded devices even just from the overhead perspective. This is one of the goals of the 6lowapp effort – to develop a solution for embedded low-power application data transfer. At least there is tons we can learn from REST/URL/Web models when doing that.

I guess your comment is that we should preserve the end-to-end paradigm as much as possible, right?

how does chopan (http://tools.ietf.org/html/draft-frank-6lowpan-chopan-00) play into the 6lowpan efforts? It appears that draft was submitted about three weeks prior to the submission of 6lowpan-usecases

I was really surprised to see a proposal to give up the ‘end-to-end’ principle. It’s clear that an intermediary service is needed but isn’t that entirely orthogonal to the network!?

Cheerio, Harry.

http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp