Subject: [core] observe and message id

From: Shoichi Sakane <[email-masked]>
Date: Wed, 17 Apr 2013 18:44:53 +0900

Hi Hartke,

Question and suggestion about the Observe.

> Appendix A.  Examples
> 
>          Observed   CLIENT  SERVER     Actual
>      t   State         |      |         State
>          ____________  |      |  ____________
>      1                 |      |
>      2    unknown      |      |       18.5 C
>      3                 +----->|                  Header: GET 0x41011633
>      4                 | GET  |                   Token: 0x4a
>      5                 |      |                Uri-Path: temperature
>      6                 |      |                 Observe: (empty)
>      7                 |      |
>      8                 |      |
>      9   ____________  |<-----+                  Header: 2.05 0x61451633
>     10                 | 2.05 |                   Token: 0x4a
>     11    18.5 C       |      |                 Observe: 9
>     12                 |      |                 Max-Age: 15
>     13                 |      |                 Payload: "18.5 C"
>     14                 |      |
>     15                 |      |  ____________
>     16   ____________  |<-----+                  Header: 2.05 0x51457b50
>     17                 | 2.05 |       19.2 C      Token: 0x4a
>     18    19.2 C       |      |                 Observe: 16
>     29                 |      |                 Max-Age: 15
>     20                 |      |                 Payload: "19.2 C"
>     21                 |      |

Could you clarify how to deal with the Message ID in the draft ?
I imagine that the Message ID in the 1st response from the server
is just echoed by the server and must be different from the 2nd
one that is initiated by the server.

I think it's better for a reader to show how Message ID handling
by both server and client.  It might be enough to refer the text
in the core draft. 

And, for implementers, the draft should have at least one complete
flow from the start to the end of an observation with type and
message id, like the core coap draft has the one.

> 3.6.  Cancellation
> 
>    When a client rejects a confirmable notification with a Reset message
>    or when it issues a GET request without an Observe Option for a
>    currently observed resource, the server will remove the client from
>    the list of observers of this resource.  The client MAY use either
>    method to indicate that it is no longer interested in receiving
>    further notifications for the resource until it eventually registers
>    again.

In the 2nd way, the server not only remove the client in the list,
but also send the final resource state to the client ?
It is mentioned in the figure 6 at Appendix A.  However, the body
in the draft should describe it.

Shoichi

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 17 Apr 2013 12:04:57 +0200

Hi Shoichi,

I think Klaus is in transit right now, so let me try a quick reply.

On Apr 17, 2013, at 11:44, Shoichi Sakane <[email-masked]> wrote:

> is just echoed by the server

Yes.  The first 2.05 is an ACK (this isn't very apparent from the example; you have to decode the hexadecimal header to see that -- 0x6.. & 0x3.. == 0x2..., 2=ACK.).
An ACK echoes the message-ID of the CON that solicited it.

> and must be different from the 2nd

No.  The second 2.05 is a NON (again, you have to look at the hex -- 0x5.. & 0x3.. == 0x1..., 1=NON.).
So it uses the message-ID space of the server, not that of the client.
(The message-ID therefore *could* happen to be the same, but the likelihood is 2**-16.)

> by both server and client.  It might be enough to refer the text

I think Klaus tried to focus the example on the observe-specific aspects.
Showing everything at once can be quite confusing.
But maybe we can find a way.

> message id, like the core coap draft has the one.

Good idea.

> in the draft should describe it.

Yes.  The text, again, focuses on what's specific to observe, but it indeed has to guard against the common misunderstanding "expressio unius est exclusio alterius" (which is making lawyers a lot of money, but isn't true in protocol specifications).

(Looking at this specific paragraph, there is also #258/#281; I think it is easy to fix both these tickets but there is an underlying cognitive dissonance with the fact that a GET without Observe is influencing existing observation relationships.  This is one of the things we have to nail down (i.e., change to something better or agree to accept as is) before finishing -observe.)

Grüße, Carsten