Subject: Re: [core] Richard Barnes' Discuss on draft-ietf-core-observe-14: (with DISCUSS and COMMENT)

From: Klaus Hartke <[email-masked]>
Date: Tue, 23 Sep 2014 15:50:52 +0200

Hi Richard,

thank you for your review and questions.

Richard Barnes wrote:
> One very temporary point: Has anyone done a comparison between this work
> and the server push aspects of HTTP/2?  Is there any value in trying to
> align the two?

If I'm not mistaken, the server push in HTTP/2 is used when a server
can predict which resources the client is going to request next. For
example, when an HTML document contains an <img> element, it's highly
likely that a web browser will request the linked image next. However,
once the representation has been pushed to the browser, the server
cannot update the displayed page by pushing updated representations.

The "CoAP observe" protocol is used when a client wants to have a
fresh representation over a period of time. The server pushes updated
representations, but it cannot push representations of resources that
the client didn't request. In a web browser, a similar effect can be
achieved using <meta http-equiv="refresh" content="1"> or some ad-hoc
solution based on repeated AJAX calls, Long-Polling, Server-Sent
Events or WebSockets, except that any of these mechanisms either cause
a lot of unnecessary traffic, bypass the cache, or break REST in some
other way.

The closest equivalent to "CoAP observe" in the HTTP world that I'm
aware of is the MONITOR verb in Roy Fielding's Waka.

> It's unclear to me from the text of Section 2 how the 0/1
> register/deregister values are used.  Are these reserved values out of
> the sequence number space?  Or are they carried somewhere else in the
> option?  I infer from Section 3.6 that the answer is the former, but
> Section 2 should be explicit about this.

The value of the Observe Option depends on where it's used: in
requests or in notifications/responses. In notifications/responses,
the value is a sequence number. In a request, the value is either
'register' or 'unregister'. The two spaces do not overlap.

> In fact, it seems like it's not necessary to reserve the value 1 at all,
> since the server must interpret any positive value as deregistration.
> Calling out 1 as special invites server implementations to screw this
> up.

I could have written: "The client MUST be conservative in what it
sends; the server MUST be liberal in what it accepts."

> "the time elapsed between the two incoming messages is not so large that
> the difference between V1 and V2 has become larger than the largest
> integer that it is meaningful to add to a 24-bit serial number"
> The text seems confused about whether the value of the Observe option is
> a serial number or a time value.  The definition says that it's a serial
> number, but this sentence implies that it's somehow related to time.  In
> order to avoid clients making unwarranted assumptions about the value of
> the Observe option, it seems important to clarify this.

We want implementations to be able to generate the sequence number
from a client-local clock, so the client doesn't have to maintain any
counters. That makes the sequence number a "temporal serial number".
I'm aware that the draft doesn't fully explain how they work (temporal
serial number arithmetic is hard), but the requirements for
implementations have been verified multiple times and validated in
interop events.

> "And third, the server may erroneously come to the conclusion that the
> client is no longer interested"
> To mitigate this, might it be useful for a client to sometimes send
> "gratuitous ACKs"? That is, to periodically re-ACK the last notification
> to re-confirm its interest?

The server makes several attempts to contact the client before it
removes an entry from the list of observers. So a client is really
only removed when there is a network partition or heavy congestion. In
that case, a periodic acknowledgement wouldn't help as well. At some
point, an unresponsive client has to be declared dead and removed from
the list of observers. If a client wants to make sure that it's still
on the list (for example, if it hasn't heard from the server for some
time), then it can easily re-register by sending another GET request
with Observe Option and the previously used token.

> "If the server returns a 2.xx response that includes an Observe Option as
> well..."
> Does the value of this option matter at all?  Could the server, for
> example, simply mirror the client's option?

At this stage (send a request, get a response) it's only important
that the Observe Option is present. However, when it comes to
reordering detection, the value is important; it must be a sequence
number. This is specified in section 4.4 of the document [1].

[1] https://tools.ietf.org/html/draft-ietf-core-observe-14#section-4.4

> "Notifications are additional responses..."
> Might be helpful to re-word to emphasize that the only difference between
> a "notification" and a normal response is the presence of the Observe
> option.

I've added this to the end of that paragraph:

   Notifications are additional responses sent by the server in reply to
   the single extended GET request that created the registration.  Each
   notification includes the token specified by the client in the
   request.  The only difference between a notification and a normal
   response is the presence of the Observe Option.

> "Non-2.xx responses do not include an Observe Option..."
> Should this be a MUST NOT?  It seems like an interop requirement, in the
> sense of maintaining a consistent view of subscription state between
> server and client.

This sentence is just a non-normative summary of the normative
requirements for servers in section 4.2 [2]:

   "A 2.xx notification MUST include an Observe Option with a sequence
   number as specified in Section 4.4 below; a non-2.xx notification
   MUST NOT include an Observe Option."

[2] http://tools.ietf.org/html/draft-ietf-core-observe-14#section-4.2

Klaus