Re: [core] http observe unification

[Carsten Bormann <[e-mail]>]

Hi Peter,

I can't speak for Cullen (who is fast asleep right now, I hope), but you pressed what I think is a similar button with me, so I'll give you my interpretation.

> In the telecon yesterday, you objected to my proposal that the solution to the observation problem be left to designers of specific systems.  It sounded like you felt a reference document describing alternative approaches that applications might take would not be adequate.  Could you elaborate a little more here on what you believe CoAP must provide, and in what timeframe?

Most of us are used to take existing protocols and kludge together a solution for a problem using these protocols.  (One could argue that much of the Internet works that way.)  However, all these kludges have limitations and complexities caused by their kludginess.  When designing something new, it is important to separate in one's mind the desire to reuse a neat kludge that once worked for us, from a *good* way to solve the problem.  (As usual, this is balanced by the need to avoid NIH -- component reuse is a good idea, and a fit rarely has to be perfect.)

So, back to the specific problem, I think what would be interesting to see is a spec on resource observation that is developed well enough that these issues can be evaluated.  HTTP has shown us that there is no end of kludges that can be invented to solve related problems -- we have to find out which approaches are good for CoAP (where goodness includes, but is *not* limited to, ease of building boxes that map to HTTP).

In the end we want to have *the* way to handle asynchronous communication in CoAP, or -- if we need to have multiple ways -- one each for a well-defined area of application.  "Let the market decide" often just means people play games whose kludge goes into which widely used product first -- in the end we all lose.

(To avoid misunderstandings -- I'm not saying that, say, every solution that treats a subscription as a REST resource in their own right is a kludge, I'm just feeling that way when the main motivation appears to be that one would need to do this in HTTP.  CoAP is not HTTP.  On the other hand there may be a need to do both the lightweight and the heavyweight solution if each of them does not solve all the problems the other does and the unsolved problems are important enough to warrant a second solution.)

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

I think that comment was with respect to websockets.  Websockets is interesting as it is not an application protocol in the strict sense, but a way to securely (for some definition of security) derive a (minimally structured) transport to a browser from a URI.  The other half, how notifications should look like and how they interact with resource state, is outside the scope of websockets.  CoAP does not need websockets, because we already know how to send packets in our constrained networks, and there is no browser security to take care of.

Of course, there is half a dozen other hybi proposals that are more semantically rich.
http://trac.tools.ietf.org/bof/trac/wiki/HyBi#Proposals lists about half of them.

> 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 think this draft is a good source of ideas on how to combine HTTP resources with other protocols.  I don't see a need to draw in yet another protocol, though.

Gruesse, Carsten