Re: [core] http observe unification

[Peter Bigot <[e-mail]>]

I think the IETF activity I was looking for was "HyBi", a term I didn't
recognize; thanks for the pointer.  From its Wiki page:

The HyBi <http://trac.tools.ietf.org/bof/trac/wiki/HyBi> activity of the
IETF coordinates work in the IETF related to several proposals for
bidirectional, "long poll", and "reverse" HTTP: mechanisms where the
connection is still initiated by the client but communication is initiated
by the server.

This clearly states the problem for HTTP, which involves concepts of
connection and client/server communication.  CoAP does not have a concept of
"connection", and the client/server distinction is, in my opinion, a residue
of the assumption in REST that a resource is owned by a single entity (the
server) and interaction with it is always initiated by a different entity
(the client).  It is not necessarily appropriate for all M2M communication,
where an explicit peer-to-peer model has significant value.

There are a variety of approaches.  I'm still collecting base information,
then will drop below the working group reflector to coordinate with Kerry,
Klaus, Angelo, and others who have expressed a specific interest in the
problem, with the intent of coming up with a set of use cases and common
terminology that can be used to evaluate these approaches.  I have other
responsibilities which may delay visible progress until next week, but we'll
still aim to have something for discussion in Beijing.

Peter

On Thu, Oct 28, 2010 at 8:56 AM, Carsten Bormann <[e-mail]> wrote:

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