Re: [core] Observe Cancellation: The outcome

["Victor Blake" <[e-mail]>]

Well stated Peter. I agree, it's a choice to "create a resource representing
a subscription" and thereafter treat it as such.

-Victor

-----Original Message-----
From: Peter A. Bigot [mailto:[e-mail]] 
Sent: Saturday, March 08, 2014 7:20 PM
To: [e-mail]
Subject: Re: [core] Observe Cancellation: The outcome

On 03/08/2014 11:15 AM, Carsten Bormann wrote:
> On 08 Mar 2014, at 16:10, FOSSATI, Thomas (Thomas)
<[e-mail]> wrote:
>
>> b) reusing an existing request code as GET (or any other already
allocated
>>    method).
> (Personal view follows, no hat:)
>
> There is no "reuse".
>
> This is still a GET: A client is obtaining a representation of the
resource.
> At the level of the REST model, there is no change: These representations
are cacheable, they can be operated on by chains of proxies ("layered
system") only some of which make use of Observe, maintaining a uniform
interface, and so on.
>
> The details of how the GET request is operated are in the Observe request
option (absent, =0, =1).
> Setting up an Observation relationship asks for future representations as
well; renewing checks and possible re-establishes it, canceling ends the
indication of interest.
> But this is not application state: This is entirely an optimization that
saves polling (or, long-polling, which goes much further in the way of
bending the REST principles).
> Saying this is "not RESTful" is tantamount to claiming HTTP is not RESTful
because it involves setting up TCP state.

Agreed: There is no state at the HTTP (request/response transaction) layer;
it's present at the TCP (data transport) layer, which is conceptually
decoupled from HTTP in a RESTful system (e.g., HTTP/SMTP).

In CoAP, the state that's being created for -observe is being created and
destroyed as a side-effect of a GET request (transaction), and is identified
through a transaction-layer concept (Token).  So we can say there's no
inter-transaction state preserved in an -observe operation because the
transaction simply hasn't completed until something causes it to stop; all
those requests/responses over long periods are the moral equivalent of IP
packets, and the state required to support them the moral equivalent of TCP
state.

This is an interesting perspective, and I see the argument.

> The Observation relationship state is not modeled as a resource, because
it really isn't one.

It's not a resource only because it was decided that it shouldn't be.  
It'd be a resource if you think of handling observation this way:

1) Create a resource representing a subscription from a client to a server,
containing the URI of the resource to be observed and a URI to which changes
to the observed resource should be sent.  (Creation does not have to be done
on a server that hosts the observed resource.  
Exercise: why might this be desirable?)

2) Sit back and wait for updates.  (Notifications don't need to be sent by
the owner of the observed resource.  Exercise: why might this be
desirable?)

3) Delete the subscription resource when the subscription is no longer
desired.

Sure there are details to be worked out, but this seems more RESTful (and
clean and harmonious) than having subscriptions (aka state, at whatever
layer) created and destroyed as a side effect of requesting transfer of a
(representation of a) resource.

Something for CoAPbis to consider, or not.

Peter