Subject: [core] observation via callbacks

From: Peter Bigot <[email-masked]>
Date: Fri, 22 Oct 2010 09:21:15 -0500

In the interests of continuing to promote this pattern of using call-back
URIs to simplify life, what do people think of the following alternative
observation paradigm:

Assume an observable resource is present at coap://server/observable, where
the authority denotes a unicast end-point.  GET works as usual.

Allow a node client to subscribe to this by POST to coap://server/observable
of a callback URI coap://client/observer along with a subscription duration
(zero to unsubscribe).  The semantics of this are that, until the
subscription expires, whenever the server changes the value of the resource
it PUTs the corresponding representation to the callback URI registered by
each observer (probably as a Non-Confirmable).

Enhancement: Extend the link description for this resource with a link
attribute "obs" the value of which is a URI-Reference that becomes a URI
like "coap://group/server/observable", where the authority denotes a
multicast group.  Whenever the server changes the value of the resource, in
addition to sending to subscribed unicast clients, it PUTs the value of the
resource in a CoAP message sent to the muticast address (and port from the
authority).  Subscribers are free to observe the resource by joining the
corresponding group and recognizing the "/server/observable" path.
Cooperative subscribers might respond to a GET of the multicast URI by
sending their cached representation; the requester can ignore all but the
first response, eliminating the need to combine multiple representations.

RESTful observation without change to the CoAP base protocol, needing
support in the link format only to enable discovery of a multicast alias for
efficient distribution of the resource to anonymous subscribers.

I think it's pretty cool.

Peter

---

From: "Stok, Peter van der" <[email-masked]>
Date: Fri, 22 Oct 2010 16:33:41 +0200

Dear Peter,

I must confess this description seems to come close to my naïve imagination of how battery-less sensors inform interested nodes.
However, the phrase
"Cooperative subscribers might respond to a GET of the multicast URI by sending their cached representation; the requester can ignore all but the first response, eliminating the need to combine multiple representations."
exceeds my parsing capabilities.
What is cooperative, cached representation, multiple representation, and why first and not last response?
Probably you already explained this in earlier mails, and pointing at the relevant parts in those mails would help.

Greetings and thanks,

Peter

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Bigot
Sent: Friday 22 October 2010 16:21
To: core
Subject: [core] observation via callbacks

In the interests of continuing to promote this pattern of using call-back URIs to simplify life, what do people think of the following alternative observation paradigm:

Assume an observable resource is present at coap://server/observable, where the authority denotes a unicast end-point.  GET works as usual.

Allow a node client to subscribe to this by POST to coap://server/observable of a callback URI coap://client/observer along with a subscription duration (zero to unsubscribe).  The semantics of this are that, until the subscription expires, whenever the server changes the value of the resource it PUTs the corresponding representation to the callback URI registered by each observer (probably as a Non-Confirmable).

Enhancement: Extend the link description for this resource with a link attribute "obs" the value of which is a URI-Reference that becomes a URI like "coap://group/server/observable", where the authority denotes a multicast group.  Whenever the server changes the value of the resource, in addition to sending to subscribed unicast clients, it PUTs the value of the resource in a CoAP message sent to the muticast address (and port from the authority).  Subscribers are free to observe the resource by joining the corresponding group and recognizing the "/server/observable" path.  Cooperative subscribers might respond to a GET of the multicast URI by sending their cached representation; the requester can ignore all but the first response, eliminating the need to combine multiple representations.

RESTful observation without change to the CoAP base protocol, needing support in the link format only to enable discovery of a multicast alias for efficient distribution of the resource to anonymous subscribers.

Peter

________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 22 Oct 2010 16:46:28 +0200

> URIs to simplify life, what do people think of the following alternative

It has some merits. But when Carsten and I discussed this during the
initial design of -observe, we came to the conclusion that a
notification and a PUT request are too different to be expressed with
the same message type.

Differences include:

- Who is the owner of the resource -- sender (notification) or receiver (PUT)

- What happens at proxies -- fanout to all subscribers (notification)
or pass-through to origin (PUT)

- What happens at caches -- update stored response (notification) or not (PUT)

- What are possible error conditions, etc.

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Fri, 22 Oct 2010 09:49:38 -0500

For previous details of my position concerning REST operations on URIs where
the authority is a multicast address, see:

http://www.ietf.org/mail-archive/web/core/current/msg00607.html
http://www.ietf.org/mail-archive/web/core/current/msg00745.html

The resource URI coap://group/server/observable is a distributed resource
that is intended to mirror the actual resource at coap://server/observable.

cooperative: Technically, the subscribers don't own the resource, so there's
no obligation that they support a GET operation on it.  In any case, you may
not want all nodes to respond (to reduce the multicast storm).

cached representation: The representation of the cached resource value,
which may not be the current value as held at the actual resource owner.
(REST maintains distinctions between the resource and its representation in
a particular media type.)

multiple representations: The real resource represents a single value, e.g.
the string "ON".  A GET addressed to a multicast address is likely to
produce multiple representations, which ideally will all be "ON".  How these
multiple representations should be combined into a single representation is
a difficult question, discussed in the above emails.

first response: because the client in a normal CoAP GET operation expects to
receive one response, which completes the transaction.  For this multicast
GET to work, the client need merely be robust in the presence of additional,
later responses, which it ignores.  ("Last" causes difficulty because when
do you decide that there are no more responses coming?)

Peter

On Fri, Oct 22, 2010 at 9:33 AM, Stok, Peter van der <
[email-masked]> wrote:

>  Dear Peter,
>
>
>
> I must confess this description seems to come close to my naïve imagination
> of how battery-less sensors inform interested nodes.
>
> However, the phrase
>
> “Cooperative subscribers might respond to a GET of the multicast URI by
> first response, eliminating the need to combine multiple representations.”
> Probably you already explained this in earlier mails, and pointing at the
> relevant parts in those mails would help.
>
>
>
> Greetings and thanks,
>
>
>
> Peter
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of
> *Peter Bigot
> *Sent:* Friday 22 October 2010 16:21
> *To:* core
> *Subject:* [core] observation via callbacks
>
>
>
> Allow a node client to subscribe to this by POST to
> coap://server/observable of a callback URI coap://client/observer along with
> a subscription duration (zero to unsubscribe).  The semantics of this are
> that, until the subscription expires, whenever the server changes the value
> of the resource it PUTs the corresponding representation to the callback URI
> registered by each observer (probably as a Non-Confirmable).
>
> ------------------------------
> The information contained in this message may be confidential and legally
> protected under applicable law. The message is intended solely for the
> addressee(s). If you are not the intended recipient, you are hereby notified
> that any use, forwarding, dissemination, or reproduction of this message is
> strictly prohibited and may be unlawful. If you are not the intended
> recipient, please contact the sender by return e-mail and destroy all copies
> of the original message.
>

---

From: Peter Bigot <[email-masked]>
Date: Fri, 22 Oct 2010 10:24:21 -0500

> > URIs to simplify life, what do people think of the following alternative

Disclaimer: I have not changed my position that multicast with REST is an
ill-defined concept.  This proposal came from my accepting the position that
not everything CoAP enables has to be 100% consistent with REST.  Some of
what falls out from things like applying CoAP to multicast addresses is very
useful and worth adopting when REST is less important than efficiency.

> - Who is the owner of the resource -- sender (notification) or receiver

The real resource is the one identified by the URI with a unicast authority,
and it's owned by that authority.

The shadow resource identified by the URI with the multicast authority is a
distributed one, not really suitable for REST because there is no owner.  I
might say each subscriber is the owner of its cached copy.  PUTs work; GETs
are odd because the requester doesn't really know who the owner is, and you
end up with multiple (maybe inconsistent) representations.

Perhaps for completeness, each subscriber should make its copy available as
a distinct resource with a unicast URI, but I don't see that as being
particularly useful, except for a similar use in group communications.

> or pass-through to origin (PUT)

Recall that there are two URIs.  What's done depends on which one is used in
the REST operation.  I would suggest that the multicast URI should not be
used outside the link-local network segment, in which proxies are most
likely to be border nodes that also serve as routers.

A proxy receiving a PUT for the unicast URI would forward it (toward the
"owner"); one receiving a PUT for the distributed URI would also "forward"
(retransmit) it toward the subscribers, though it should not do so over the
link through which it was received.

- What happens at caches -- update stored response (notification) or not
> (PUT)

Same deal: Two URIs, two resources, depends on what the cache is for (e.g.,
is it integrated with a proxy).

> - What are possible error conditions, etc.

Dunno until somebody tries it.

CoAP enables you to send and receive messages on multicast addresses, and in
fact its charter requires that it perform certain operations that way.  That
doesn't mean that every aspect of a CoAP system including proxies and caches
needs to make sense when you do this.  But where it does make sense, we
might as well get some value out of it.

Peter

> Klaus
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 22 Oct 2010 20:16:59 +0200

I think the question is, basically: What do we subscribe to an
observable resource, and how does an observer relate a notification to
a subscription or resource?

Currently, notifications are always sent to the transport address of
the subscribing node, and include the resource URI and/or a
subscriber-supplied token.

We can extend this with an option in the subscription request to
subscribe a third party. When it's present, notifications are sent to
the transport address specified in this option, instead of the
transport address of the subscribing node. The specified transport
address may specify a multicast address. Notifications include the
resource URI and/or a subscriber-supplied token.

Note how this is equivalent to subscribing an URI to a resource:

(a)
Send-Notifications-To: client:61616
Token: 0xad657b38

(b)
Callback-Uri: coap://client:61616/ad657b38

When the authority in (a) or (b) denotes a multicast group,
subscribers are free to observe the resource by joining the
corresponding group and recognizing the "0xad657b38" token or
"/ad657b38" path.

However, (b) implies that there is a RESTful resource at
coap://client:61616/ad657b38. This complicates a lot of things,
because

- we do not really want a RESTful resource, just something the server
can send notifications to,

- we could only update the RESTful resource using a PUT request, which
is not the same as a notification.

So (a) is the way to go. (That is, if we want to allow subscribing
third parties. When I presented the idea of subscribing a multicast
group to an observable resource in Maastricht, there was unanimous
consensus that this was the worst idea ever.)

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Fri, 22 Oct 2010 14:13:17 -0500

I'm unconvinced.

Creating a local resource and asking somebody to update it (via POST or PUT)
to tell me of changes to another resource seems like a perfectly natural and
RESTful coordination/notification approach given an underlying
request/response transaction model.  More natural and RESTful than accepting
multiple responses to a GET, in my opinion.

That the API technically permits subscription of third parties is something
that can be accepted or prevented by the designer of a specific system.

That the processing impact on the notifier and latency to observers is
diminished by providing a multicast authority in the URI denoting the
resource to be updated is a wonderful optimization that falls out naturally
as a consequence of a UDP-based transaction protocol, even if some REST
operations don't make sense on that URI.

Certainly, I am unaware of anything in CoAP that rules out or even
discourages use of the techniques I proposed.

Did I miss something?

Peter

---

From: "Stok, Peter van der" <[email-masked]>
Date: Sun, 24 Oct 2010 16:37:28 +0200

Hi Peter,

Just a small remark on the statement:
first response: because the client in a normal CoAP GET operation expects to receive one response, which completes the transaction.  For this multicast GET to work, the client need merely be robust in the presence of additional, later responses, which it ignores.  ("Last" causes difficulty because when do you decide that there are no more responses coming?)

I think this is just one of the few ways multicast returns can be handled or need to be handled. Let me cite some examples:
Multicast to a group of devices to set values
            No response needed, only the knowledge that all connected and correct devices have received the setting within a given period
Multicast to group of devices to get a status back
            Group is known to invoker. When a member of group has not answered within given time it is assumed to be faulty
Multicast to a server out of many possible ones
            Either the first (as you suggest) or one response selected from a set of answers, after closing return channel within a given time period (e.g. nearest DNS server)
Multicast to browse available services
            Answers can be continuously received and displayed on visu for selection by user (e.g. asking for available PIR sensors when DNS server is not available during maintenance by maintenance tool)
Possibly one should make additional implementation statements about the scope of the multicast. A mesh of wireless nodes has other response characteristics than a worldwide network of nodes connected through complex patterns of routers and edge routers.
Hope this helps,

Peter vd stok

From: Peter Bigot [mailto:[email-masked]]
Sent: Friday 22 October 2010 16:50
To: Stok, Peter van der
Cc: core
Subject: Re: [core] observation via callbacks

For previous details of my position concerning REST operations on URIs where the authority is a multicast address, see:

The resource URI coap://group/server/observable is a distributed resource that is intended to mirror the actual resource at coap://server/observable.

cooperative: Technically, the subscribers don't own the resource, so there's no obligation that they support a GET operation on it.  In any case, you may not want all nodes to respond (to reduce the multicast storm).

cached representation: The representation of the cached resource value, which may not be the current value as held at the actual resource owner.  (REST maintains distinctions between the resource and its representation in a particular media type.)

multiple representations: The real resource represents a single value, e.g. the string "ON".  A GET addressed to a multicast address is likely to produce multiple representations, which ideally will all be "ON".  How these multiple representations should be combined into a single representation is a difficult question, discussed in the above emails.

first response: because the client in a normal CoAP GET operation expects to receive one response, which completes the transaction.  For this multicast GET to work, the client need merely be robust in the presence of additional, later responses, which it ignores.  ("Last" causes difficulty because when do you decide that there are no more responses coming?)

Peter
On Fri, Oct 22, 2010 at 9:33 AM, Stok, Peter van der <[email-masked]<mailto:[email-masked]>> wrote:
Dear Peter,

Greetings and thanks,

Peter

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Peter Bigot
Sent: Friday 22 October 2010 16:21
To: core
Subject: [core] observation via callbacks

Peter

---

From: Zach Shelby <[email-masked]>
Date: Mon, 25 Oct 2010 00:32:05 +0300

On Oct 22, 2010, at 6:24 PM, Peter Bigot wrote:

> Disclaimer: I have not changed my position that multicast with REST is an ill-defined concept.  This proposal came from my accepting the position that not everything CoAP enables has to be 100% consistent with REST.  Some of what falls out from things like applying CoAP to multicast addresses is very useful and worth adopting when REST is less important than efficiency.

Just to synchronize... The intention of this WG was never to make CoAP 100% consistent with REST. That would be pretty hard considering there is no RFC defining what REST is exactly (seems to be some kind of cult...), the closest thing that we know is HTTP (which was very much designed for transferring hypermedia). The CoRE working group does aim to fit its work into the REST architecture, but I would say making CoAP (and the security work) useful for constrained nodes and networks in M2M applications to be our main goal. Thus I agree with you, multicast CoAP is worth developing, and is a must for most applications we are considering it for.

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Zach Shelby <[email-masked]>
Date: Mon, 25 Oct 2010 00:38:50 +0300

> consensus that this was the worst idea ever.)

This is the first thing that came to mind when Peter brought this up. We really got bashed in Maastricht for even suggesting that the notifications would go to a third party for security reasons. They *really* liked when it was mentioned that this could be a multicast address. Think of how powerful of an amplification attack this would be built-into a protocol implemented by resource-limited nodes? 

I do agree with Klaus, if we did want to allow subscription to a third party, then (a) makes the most sense to me. However, I am not sure if we should or can do that at the transfer protocol level. It sounds like the pattern Peter described belongs to a REST application interface design instead...  

Zach

---

From: Peter Bigot <[email-masked]>
Date: Sun, 24 Oct 2010 17:30:44 -0500

Bah.  If the content of the notification is sensitive, don't multicast it.
Or multicast it encrypted.  And disallow third-party subscriptions.  That's
all application-level policy decisions.  And as Zack says, all this can be
done by the application using CoAP as a transport for a REST API.  There are
plenty of notification use cases where third-party and/or anonymous
subscriptions and/or multicast distribution make sense, and CoAP shouldn't
presume to outlaw them (even if it could, which I doubt).

I don't need the proposed subscription options (or multicast) to implement a
workable RESTful notification or group communication scheme, with-or-without
multicast, with-or-without third party subscribers.  Base CoAP's got enough
for me to do that cleanly with unicast, using the techniques I described,
cleanly and no less efficiently than using the draft extensions.  I think
this is evidence of CoAP's robustness and strength as a point-to-point
REST-compatible protocol.

Multicast will be very useful in a CoAP-based protocol that uses a different
scheme and different (non-REST) operations.   Probably handled by a gateway
that transforms both standard CoAP and HTTP-carried REST operations into a
multicast form.  All of Peter van der Stok's examples can be handled, but
clearly need a lot more thought and development so they can be presented in
a conceptually clear model suitable for integration with web-compatible
service oriented architectures (which I think is really the goal, not REST
specifically).  I have ideas, but am too swamped to write them down now.

So: Do we try to discourage people from attempting to use multicast
addresses with CoAP as currently defined, given that we don't have
protection against amplification attacks, haven't really validated using
multicast addresses with the current method set, and don't have a clear
description of how to accomplish the mandated HTTP/CoAP transformations
generally when they're involved?  Or do we leave it unaddressed?

The same issues technically arise in any other UDP-based protocol that
inherently assumes a point-to-point interaction model.  Somebody bolted
multicast onto TFTP five years later on, and that was good enough, but since
CoRE's charter explicitly mentions multicast, and we're not ready for it,
whoever's at Beijing might want to be prepared to address this.  (I will be
attending virtually, not IRL)

Peter

On Sun, Oct 24, 2010 at 4:38 PM, Zach Shelby <[email-masked]> wrote:

> This is the first thing that came to mind when Peter brought this up. We
> really got bashed in Maastricht for even suggesting that the notifications
> would go to a third party for security reasons. They *really* liked when it
> was mentioned that this could be a multicast address. Think of how powerful
> of an amplification attack this would be built-into a protocol implemented
> by resource-limited nodes?
>
> I do agree with Klaus, if we did want to allow subscription to a third
> party, then (a) makes the most sense to me. However, I am not sure if we
> should or can do that at the transfer protocol level. It sounds like the
> pattern Peter described belongs to a REST application interface design
> instead...
>
> Zach
>
> --

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 25 Oct 2010 12:11:05 +0200

I agree with Peter, see this old discussion on the topic:

http://www.ietf.org/mail-archive/web/core/current/msg00236.html
http://www.ietf.org/mail-archive/web/core/current/msg00243.html

In my opinion designing a protocol that can be simply used by constrained
objects is the main target here.

There is a lot of state involved in the current design, and when concurrent
subscriptions with multiple end-points are in place the current transaction
layer cannot handle it and tokens are required (I pointed out this issue at
the Maastricht meeting too...).

M2M operation should be simplified by CoAP, and in this context even without
multicast an endpoint may request multiple endpoint to collaborate and to
serve some data to it recurrently on the resource in charge of handle this
kind of data.

As Klaus notes, this resource can be the holding the state a token would,
but can also be a prearranged resource to collect data. In my opinion it's a
more flexible and more RESTful solution to the subscription problem.

Moreover HTTP mapping is straightforward and a proxy/gateway in the middle
has no need to handle the token state to route and translate the request to
the right HTTP endpoint.

Angelo

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 25 Oct 2010 15:37:50 +0200

The main idea around this is to have a Source-URI Option to be used for:

a) subscription to define the resource that will be collecting notifications
b) notification to advertise the resource that is currently sending the
notification

In this way the current coap-observe proposal architecture remains the same,
but both URLs are sent in each transaction (as in CoAP, short URLs are
recommended).

In my opinion, this addition eases HTTP mapping, adds flexibility and adds
full support for concurrent subscriptions.

Best,
Angelo

On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani
<[email-masked]>wrote:

> M2M operation should be simplified by CoAP, and in this context even
> without multicast an endpoint may request multiple endpoint to collaborate
> and to serve some data to it recurrently on the resource in charge of handle
> this kind of data.
>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 25 Oct 2010 15:53:40 +0200

Peter Bigot wrote:
> I don't need the proposed subscription options

And I don't need GET, PUT or DELETE.
POST is good enough for me to do that.

But we do have GET, PUT, DELETE and POST in CoAP, because they have
different semantics and it's beneficial to make the meaning of a
message available not only to the sender and recipient, but also to
the intermediary nodes along the way.

The same applies when it comes to observing resources. I guess it is
possible to do subscriptions on top of CoAP, using only basic CoAP
operations without subscription-related options. But then we lose the
benefit of knowing what a PUT request means.

For example, a notification always comes with a set of meta data such
as Etag and Max-Age. When an intermediary node sees a notification, it
knows that the state of a particular resource has changed to a
particular state, and can cache the present representation.

In a PUT request, Etag or Max-Age is not defined. Both are managed by
the origin server, not provided by the client when it supplies a new
resource state. When an intermediary node sees a PUT request, it
cannot make any assumptions about the state of the resource, and it
knows nothing about any sender resources.

A notification has really more in common with a response than with a request.

If you don't need intermediary nodes be aware of what's going on,
nothing prevents you from implementing observation with base CoAP. But
I think if you try to address all aspects of integrating a
subscription/notify mechanism into a RESTful environment, you end up
with a duct tape solution that is much more complex than making the
step and introducing a subscription option.

(To clarify: I'm all in for making things simpler. Reifying observers
into URIs feels really natural. In fact, that's what I had implemented
in my first experimental implementation before I started working on
-observe. But when I proceeded to work out the details, I had to give
up the idea. If you can find a solution that is simpler and works,
let's do it.)

Klaus

---

From: Peter Bigot <[email-masked]>
Date: Mon, 25 Oct 2010 09:28:19 -0500

Curious: why add a Source-URI option, rather than put the URI in the body of
the subscription request?  The body's not used for anything else in this
case (it's a GET, isn't it?).  I can see some motivation for putting it in
the response, but would suggest that the target of the response is adequate
to distinguish the sender (if you're doing fan-in, add a distinguishing path
component to the URI in the subscription request, like
coap://collector/temps/south, coap://collector/temps/north for an aggregate
resource coap://collector/temps).  It'd make the messages shorter, too.

BTW: to correct my example, I now believe the notification by the origin
should be a POST to the callback or notification URI, not a PUT.  The
implication is that the receiving resource is an actor that will process the
notification, not a data store that will hold its value.

Alternatively, which method should be used might be controllable by the
subscriber: in the case of sleeping nodes, the state at an always-up cache
which is the authority for a general-use URI for the resource is pure
storage.  The sleeping node that is the real resource owner can reasonably
PUT the value there.  (Though this is really a fairly special case of
notification, if it's notification at all.)

Klaus: You may well be right.  I suspect that using the natural semantics of
REST operations will allow the effect of intermediate nodes to be exactly
what's expected from REST, but can't say for sure because I haven't done a
deep analysis.  Without asking you to provide a more detailed summary of
your own analysis and assumptions than I've seen, I  have not yet myself
seen a compelling need to modify the protocol, especially in a way that
results in multiple responses to what is naively a single request.  I still
believe a perfectly workable and clear solution can be reached using base
CoAP as it's defined today.

In any case, PUT or POST, subscription or callback, perhaps subscriptions
are better expressed by defining content-types for subscription descriptions
and notifications, rather than adding options to the header and changing the
transaction layer state machine.  This would clearly provide the information
required by intermediate nodes.

Just a thought.

Peter

On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <[email-masked]
> wrote:

> In this way the current coap-observe proposal architecture remains the
> same, but both URLs are sent in each transaction (as in CoAP, short URLs are
> recommended).
>
> On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <[email-masked]
> > wrote:
>
>> There is a lot of state involved in the current design, and when
>> concurrent subscriptions with multiple end-points are in place the current
>> transaction layer cannot handle it and tokens are required (I pointed out
>> this issue at the Maastricht meeting too...).
>>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 25 Oct 2010 17:11:13 +0200

The utility of defining subscription fully at CoAP level is to have a CoAP
implementation not dependant upon the resource; CoAP implementation itself
can provide subscription functionality for every resource that is handling..
In constrained nodes this is really useful to save ROM space on the MCU.

There are methods to save space in the payload, just an example: if
source-URI is omitted, source-URI is equal to URI; another option is that
the subscriber can ask not to send back the source-URI in the notifications.

I prefer to receive a status code in the response, not a generic POST (like
in current coap-observe document). I think that it's more useful and
moreover CoAP sw layer can implement subscription by duplicating the same
message with interval X locally limiting sw overhead above CoAP.

An addition: I was wondering why limit subscribe to a GET? If I subscribe
using a POST with fixed parameters, in that case the subscription equals
receiving that particular post every X seconds, if properly elaborated can
be useful under some special circumstances.

Best,
Angelo

On Mon, Oct 25, 2010 at 16:28, Peter Bigot <[email-masked]> wrote:

> Curious: why add a Source-URI option, rather than put the URI in the body
> of the subscription request?  The body's not used for anything else in this
> Klaus: You may well be right.  I suspect that using the natural semantics
> of REST operations will allow the effect of intermediate nodes to be exactly
> On Mon, Oct 25, 2010 at 8:37 AM, Angelo P. Castellani <
> [email-masked]> wrote:
>
>> On Mon, Oct 25, 2010 at 12:11, Angelo P. Castellani <
>> [email-masked]> wrote:
>>
>>> Moreover HTTP mapping is straightforward and a proxy/gateway in the
>>> middle has no need to handle the token state to route and translate the
>>> request to the right HTTP endpoint.
>>>
>>> Angelo
>>>

---

From: Peter Bigot <[email-masked]>
Date: Mon, 25 Oct 2010 10:48:54 -0500

But it's the application level above REST, not CoAP, that determines what
GET, PUT, and especially POST and DELETE mean with respect to a particular
resource and content-type.  I don't think this can be done purely at the
CoAP level.  It would require that the CoAP transaction layer be notified of
every change to resource state to kick off distribution to subscribers, and
possibly that it be able to up-call to the application to retrieve a
resource representation without having a REST request to drive it (or that
it replay the REST request that created the subscription, including all its
companion options and message body, possibly violating the business logic
associated with the resource).

Attempting to account for all that within the transaction layer is pretty
difficult.  Time-driven auto-generation within CoAP, either of notifications
(subscribed GET) or of incoming updates (subscribed POST), also seems like
something that is better handled at the application layer where the
policy-related decisions can be managed.

I'm coming to feel that there's a resource A , there's optionally a second
resource B that provides subscription services for resource A if that's
appropriate, and there's arbitrary resources Ci that have been registered
through B to receive updates when the owner of A has detected a change.  A
"subscribable" resource A makes its subscription manager B visible through
the link description, and everything "just works".

Everything else is managed at the application layer.  Note that each one of
those subscribers might require a different representation (content-type),
or due to other characteristics be given a different view of the resource,
and only the application level can reliable identify (and retain) those
characteristics.  Or, in fact, determine whether a proposed subscription
should be accepted, if the resource content is sensitive.

I don't think the goal in your first sentence is the best way to save ROM
and satisfy domain business logic.  An application-level capability would do
this at least as well, and more generally.

Peter

On Mon, Oct 25, 2010 at 10:11 AM, Angelo P. Castellani <
[email-masked]> wrote:

>>> In my opinion, this addition eases HTTP mapping, adds flexibility and
>>> adds full support for concurrent subscriptions.
>>>
>>> Best,
>>> Angelo
>>>
>>>> In my opinion designing a protocol that can be simply used by
>>>> constrained objects is the main target here.
>>>>
>>>> As Klaus notes, this resource can be the holding the state a token
>>>> would, but can also be a prearranged resource to collect data. In my opinion
>>>> it's a more flexible and more RESTful solution to the subscription problem.
>>>>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 26 Oct 2010 09:00:42 +0200

Well probably there is a misunderstanding on some parts of my message.

However, surely a resource can be "non-subscribable" or even better POST on
some resource is "non-subscribable"... The resource itself when receives the
first message, is notified that the message itself is "subscription" message
and can refuse it.

CoAP layer can replicate the requests to the resource only after the
subscription has been successful. The requests to the resource should
contain information (TID?) to match the replicated request with the
precedent subscription.

The CoAP layer support for basic subscription functionality for generic
resources can be useful and standard, for this reason it can be supported by
CoAP applications built using generic CoAP-compliant sensors.

This support does not limit the use of advanced subscription functionalities
in above layers, and to refuse the use on resources that does not like this
mechanism.

A very useful cross-layer optimization that I hope will be possible using
CoAP is also that when the resource itself changes the representation
notifies the CoAP layer, so that even subscribers are notified of the
change; supporting this feature should optional for resources.

Angelo

On Mon, Oct 25, 2010 at 17:48, Peter Bigot <[email-masked]> wrote:

>> I prefer to receive a status code in the response, not a generic POST
>> (like in current coap-observe document). I think that it's more useful and