Re: [core] http observe unification

[Cullen Jennings <[e-mail]>]

(inline and all of this in my individual contributor roll not my co-chair roll )

On Oct 28, 2010, at 6:43 AM, Peter Bigot wrote:

> Cullen:
> 
> In the telecon yesterday, you objected to my proposal that the solution to the observation problem be left to designers of specific systems.

Yes - I think there should be at document that describes at least one way to do this. I don't care if there could be many ways to do it. I can see that there are some designs where you need to change or extend the underlying COAP protocol and there are also designs where it is layered on top with no change to COAP. I don't care too much which of the two it is as in the end that is really just moving where the bits are in the packet which I could care less about. 

>  It sounded like you felt a reference document describing alternative approaches that applications might take would not be adequate.  

sorry if I gave that impression - I'd love to see a document like that - it would help understand the design space. I am more concerned about having less than 1 solution than the problem of having more than 1 solution. I do not think the document that describes a solution has to be the same RFC as the base spec COAP spec and devices could choose if they were just doing the base spec or if they implemented base spec + an observation solution. 

> Could you elaborate a little more here on what you believe CoAP must provide, and in what timeframe?

I don't care if it is in COAP, an extortion to COAP, or just a way of using COAP but I would like to see the WG produce a way of having a way for Application A to to say it wants to know about changes to resource B and when B changes, a message gets sent to A saying it changed. It's not really very complicated what I want. As my friend Dean says, there's many ways to skin this cat, I rather not see us use a potato peeler. Oh, and let me be clear on one more thing about it - I do not care in the slightest if anyone thinks it is REST or not, I just want my message when the resource changes and something that is reasonable to implement. I've got a pretty deep understanding of REST and I don't see how the concepts of REST actually help much with the conversation here. I do think discussion of what devices need to store state, for how long, and how much do help with the design as well as discussion of what is idempotent. The security and flexibility implications of various solutions are also interesting to consider along with the obvious issues of size, complexity, and efficiency. 

> 
> I understood you to say that some IETF working group was nearly complete with a proposed standard way to implement observation in HTTP.  Is that the Httpbis group?  To which of their documents were you referring?  draft-loreto-http-bidirectional is somewhat relevant (wrt streaming responses).

HyBy

http://tools.ietf.org/wg/hybi/draft-ietf-hybi-thewebsocketprotocol/

> 
> The clearly relevant one is draft-roach-sip-http-subscribe, but that's based on SIP event notification.  Were we to take that approach, it might be best to define a CoAP-like protocol "csip", rather than integrate that functionality directly into CoAP.  On first glance, it appears this would be at least as much work as defining CoAP has been.  It would, though, give us a solution to observation, notification, and group communication that is compatible with the HTTP family of protocols, so is certainly worth considering.

I helped design the SIP Sub/Notify system and it's design goals were very different from what we are trying to do here. At a high level it is isomorphic to what we want but as you did into the details, it was optimized for something fairly different than the CoAP use cases. I'm certainly not pushing the approach that was used in SIP thought I tend to fall into using the terminology from SIP just because I know it well. 

> 
> Thanks.
> 
> Peter