Subject: [core] SUB/NOT - the sea level view

From: Cullen Jennings <[email-masked]>
Date: Fri, 4 Jun 2010 12:33:53 -0600

Over the year I have had the pleasure of being in many conversations about what a stateless protocol is, what REST is, HTTP, polling, asynchronous notifications, web based RPC, and blowing soap bubbles.  Though interesting, I have a hard time concretely explaining it to anyone and the oxygen always seems a bit thin at the 10,000 foot view. I do however have a very easy time understanding a very low level view of the systems where there are  some boxes and arrow diagrams of  message flow and roughly the semantics of the data they cary. Let me try and draw my current understanding of how this is going to work.

We have two nodes - I will call them Source and Sink. 

   Source         Sink       
     |    SUB      |         
     |<------------+         
     |             |         
     |    ACK      |         
     +------------>|         
     |             |         
    ... Time Passes ...          
     |             |         
     |   NOTIF     |         
     +------------>|          
     |             |         
     |   ACK       |         
     |<------------+          
     |             |         

Sink starts by sending a message I will label "SUB" to the Source. The SUB messages says which resource the Sink would like to be informed about when the resource changes. The Source sends a OK or No there is a problem in some sort of ACK message to the SUB. Eventually the resource changes and Source sends an message I called "NOTIFY" to the Sink. This tells the Sink which resource changed and the current value of it.The Sink sends some sort of acknowledgment. I find the terms client and server very confusing when discussing SUB/NOT so I'm not using those terms. 

The Sink could be a HTTP proxy that mapped this to COMET, WebSocket, or plain old polling, XMPP, SMTP, just about anything. As far as I can tell, pretty much everything people have been proposing fit into this model.  So first, I'd like to get an idea if people think I am in left field and there is a very different message flow to consider. Second we need to figure out some of the stuff I left out of the picture above such as 

a) how to cancel a subscription 

b) how to get the initial value of the subscription around the time you subscribe 

c) what sort of filtering is available to limit the types of resource changes that result in a NOTIFY 

d) lifespan of subscription how to refresh a subscription

e) caching and interaction with sleeping device 

We have to be clear on how this maps to HTTP and possibly other protocols. One of the problems with HTTP is it has so many ways of doing asynchronous notifications that it hard to decide what to map for. I would be very conformable if we clearly new how to map it to HiBy and to direct HTTP polling. It would be nice to have  back of the cocktail napkin belief that it probably could be mapped to SMNP, XMPP, and the other HTTP approaches. My guess is that the mapping to other protocols is going to turn out to be easy.

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Fri, 4 Jun 2010 21:22:11 +0200

my two cents

[if sink node POST a new entry into the subscribers list on that resource, then it can DELETE it]

[the ACK  could be a response message containing the current value of the subscribed resource at time of subscription]

[it seems application specific; for example, you can define a sort of trigger with thresholds and hysteresis to avoid bouncing]

[sink and source nodes can agree on a subscription lifetime: sink can refresh the subscription by sending a new SUB request]

[mmhh ... no have cents for now. sorry]

Adriano

From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
Sent: venerdì 4 giugno 2010 20.34
To: core
Subject: [core] SUB/NOT - the sea level view

                             
   Source         Sink       
     |    SUB      |         
     |<------------+         
     |             |         
     |    ACK      |         
     +------------>|         
     |             |         
    ... Time Passes ...          
     |             |         
     |   NOTIF     |         
     +------------>|          
     |             |         
     |   ACK       |         
     |<------------+          
     |             |         

[if sink node POST a new entry into the subscribers list on that resource, then it can DELETE it]

[the ACK  could be a response message containing the current value of the subscribed resource at time of subscription]

[it seems application specific; for example, you can define a sort of trigger with thresholds and hysteresis to avoid bouncing]

[it seems application specific; sink and source nodes can agree on a subscription lifetime: sink can refresh the subscription by sending a new SUB request]

[mmhh ... no have cents for now. sorry]

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 4 Jun 2010 15:49:06 -0600

Great points - thanks. 

Just as a bit of other information for the WG, I'll try and describe how SIP solved these problems. SIP has different design goals so what they did is probably not appropriate for all of these but it is at least something to be aware of. My apologies to the SIP experts on the list that know this but seems worth mentioning for folks that don't.

> [if sink node POST a new entry into the subscribers list on that resource, then it can DELETE it]

I can see how that works but looks like it might involve a few roundtrips. What SIP does is it "refreshes" the subscriptions with an expiry time of zero which causes it to instantly expire and go away. More of how the refresh works down in point d. 

> [the ACK  could be a response message containing the current value of the subscribed resource at time of subscription]

I like the approach you are proposing. What SIP does is it sends a NOTIFY as soon as the SUBcription happens. This was done due a variety of reasons but a big part is SIP has some pretty significant problems with negotiating size of responses. This would cause problems where the ACK ended up being too large in SIP. I don't think we would have the problem in COAP so sending it in the ACK might be better. 

> [it seems application specific; for example, you can define a sort of trigger with thresholds and hysteresis to avoid bouncing]

The SIP guys went round and round discussing a variety of increasingly complicated generalized solutions which were never general enough to meet all the use cases. Eventually  they came to the conclusion that it was application specific. 

> [sink and source nodes can agree on a subscription lifetime: sink can refresh the subscription by sending a new SUB request]

This is roughly what SIP does. The Sink proposes the max expiry time it wants. The Source can make this smaller (but not larger) and returns the "expiry time"  in the ACK. The Sink has to refresh the subscription before the expiry time by sending a new SUB. I suspect this would wok well for COAP. 

> [mmhh … no have cents for now. sorry]

SIP has these, uh, I'm never going to manage to explain this in a paragraph but if you are feeling masochistic you can go read RFC 2778, 3265, 3903, 4662, 4479, and 5839 as a starting point them move into the many RFCs on the compression and optimization approaches. I'd suggest the full blow SIP approach is probably a bit complex for constrained devices. 

I can easily imagine something where a COAP cache or caching proxy to HTTP just subscribes to the resource. That way the cache is always up to date and when the cache receives a GET or SUBSCRIBE for the resource, it can just respond with the correct data. The device that has the resource can sleep and just update the cache any time the resource changes. To make a scheme like this work really well it might be nice if a Source that received a SUB could redirect the Sink to send the subscribe to a cache that the Source knew was willing to cache the data. It also allows a cache that see a NOTIFY go by to update it data for that resource. 

> [mmhh … no have cents for now. sorry]
>  
>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 7 Jun 2010 11:10:55 +0200

Yes one request for multiple responses.

On Mon, Jun 7, 2010 at 10:30, Adriano Pezzuto (apezzuto) <[email-masked]
> wrote:

>  Hi
>
> not sure to understand but it sounds as an interesting way to see things.
> Multiple response messages to the same initial GET request message?
>
> The initial GET request acts as subscription request to a certain resource.
> The first response message returns the value of the resource at time of
> subscription and subsequent responses act as notification messages about
> resource changes in the time.
>
>
>
> Questions:
>
>
>
> how to keep track of initial GET request and subsequent responses? using a
> sort of transaction id shared among request and responses messages?
>
This is really transport dependant.

If we use TCP or DTLS, application level has already a session established
and TID is not needed at all.

If we use UDP, TransactionID can be easily substitued by sending responses
to the client source port of the request. This will work in almost every
situation, however a TransactionID option can be there for the cases when
there is some collision using the source port.

> how to fit with REST requirements? safety/idempotency?
>
I don't feel that subscription "changes the resource state" in some way but
it only changes the way the resource *reports* its actual state.

EXAMPLE node led resource: with POST/PUT I change the state of the led on
the node, with GET I read the state. Subscription-GET reports the state
every N seconds, when changes, etc.

However if we don't like this solution for the REST safety/idempotency
properties, we can use something else (POST? I don't think we really need a
specific SUBSCRIBE for this).

Using GET however seems simpler, and we're designing this for constrained
nodes so it can be convenient in any case...

> how to distinguish this by a classic GET request/response transaction (one
> request followed by only one response)?
>
An Option is required to transform a GET to a recurrent GET. Some samples:

Repeats-Every: N
N represents the response rate. Resource should send a response every N
seconds.

Repeats: true
Node should send a response according to the triggers defined in the body
(TODO: specify a starting but extensible format)

Repeats-Lifetime: N
N represents the number of seconds after which the resource sends its last
state.

Many other can be defined, we can agree the minimal required set of flexible
options..

> how to realize spontaneous notifications, i.e. notifications no triggered
> by a subscription?
>

Spontaneous notification really map in a different way in this context and
also in HTTP. They can be simply a PUT/POST to some resource defined to
catch that kind of events.

Angelo

>
>
> Adriano
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Angelo P. Castellani
> *Sent:* lunedì 7 giugno 2010 9.59
> *To:* Cullen Jennings (fluffy)
> *Cc:* Adriano Pezzuto (apezzuto); core
> *Subject:* Re: [core] SUB/NOT - the sea level view
>
>
>
> I agree with Adriano comments, and I really like the POST/DELETE (or GET?)
> mapping of the subscriptions. We really need to define new HTTP verbs to
> define a standard a subscription format?
>
> What if we define the best HTTP-mapped subscription?
>
> A solution can be, a SUBSCRIBE action is nothing more than a GET which
> responses are repeated using some criterion (threshold, every N seconds,
> etc.).
>
> The trigger of the response, in my opinion, can be ranging a lot depending
> upon the application, so could be inserted in the body of the request. A
> possible version of the body format can be agreed, however it should be
> extensible to fit particular cases.
>
> ACK'ing the request or the responses is really transport dependant. If we
> use TCP, ACKs are already there. If we use UDP, some ACK packet format can
> be agreed to provide some level of reliability to UDP. etc.
>
> *   Source                   Sink
>      |           GET          |
>      |<-----------------------+
>      |                        |
>      |           RES          |
>      +----------------------->|
>      |                        |
> ... Time Passes, something triggers in the Source ...
>      |                        |
>      |          RES           |
>      +----------------------->|
>
>
> *To realize this we can define some Options that will make that GET (or
> POST?) request have the same meaning of a SUBSCRIBE (seems easier to define
> new Options to make this eventually adopted by HTTP, or maybe there is some
> Option already there we can overload in some way).
>
> Repeats? Repeats-Every? Lifetime?
>
> In this way we have easily the very initial value, and because the packet
> format is the same for a standard response and for a NOTIFY its easier for a
> CoAP/HTTP proxy to update its cached value.
>
> Subscription can be updated/refreshed/deleted with the same message GET (or
> POST?) message (delete -> Repeats=false) and we can get in this way the
> value on subscription deletion.
>
> In this way I'm quite confident that node software architecture also can be
> simpler, because a lot of code/procedures can be shared between GET and
> SUBSCRIBE/NOTIFY with no particular effort.
>
> Angelo
> *
> *On Fri, Jun 4, 2010 at 23:49, Cullen Jennings <[email-masked]> wrote:
> >
> > Great points - thanks.
> >
> > Just as a bit of other information for the WG, I'll try and describe how
> SIP solved these problems. SIP has different design goals so what they did
> is probably not appropriate for all of these but it is at least something to
> be aware of. My apologies to the SIP experts on the list that know this but
> seems worth mentioning for folks that don't.
> >
> >
> > I can see how that works but looks like it might involve a few
> roundtrips. What SIP does is it "refreshes" the subscriptions with an expiry
> time of zero which causes it to instantly expire and go away. More of how
> the refresh works down in point d.
> >
> >>
> >> [the ACK  could be a response message containing the current value of
> the subscribed resource at time of subscription]
> >
> > I like the approach you are proposing. What SIP does is it sends a NOTIFY
> as soon as the SUBcription happens. This was done due a variety of reasons
> but a big part is SIP has some pretty significant problems with negotiating
> size of responses. This would cause problems where the ACK ended up being
> too large in SIP. I don't think we would have the problem in COAP so sending
> it in the ACK might be better.
> >
> >>
> >> [it seems application specific; for example, you can define a sort of
> trigger with thresholds and hysteresis to avoid bouncing]
> >
> > The SIP guys went round and round discussing a variety of increasingly
> complicated generalized solutions which were never general enough to meet
> all the use cases. Eventually  they came to the conclusion that it was
> application specific.
> >
> >>
> >> [sink and source nodes can agree on a subscription lifetime: sink can
> refresh the subscription by sending a new SUB request]
> >
> > This is roughly what SIP does. The Sink proposes the max expiry time it
> wants. The Source can make this smaller (but not larger) and returns the
> "expiry time"  in the ACK. The Sink has to refresh the subscription before
> the expiry time by sending a new SUB. I suspect this would wok well for
> COAP.
> >
> >>
> > SIP has these, uh, I'm never going to manage to explain this in a
> paragraph but if you are feeling masochistic you can go read RFC 2778, 3265,
> 3903, 4662, 4479, and 5839 as a starting point them move into the many RFCs
> on the compression and optimization approaches. I'd suggest the full blow
> SIP approach is probably a bit complex for constrained devices.
> >
> > I can easily imagine something where a COAP cache or caching proxy to
> HTTP just subscribes to the resource. That way the cache is always up to
> date and when the cache receives a GET or SUBSCRIBE for the resource, it can
> just respond with the correct data. The device that has the resource can
> sleep and just update the cache any time the resource changes. To make a
> scheme like this work really well it might be nice if a Source that received
> a SUB could redirect the Sink to send the subscribe to a cache that the
> Source knew was willing to cache the data. It also allows a cache that see a
> NOTIFY go by to update it data for that resource.
> >
> >
> >>
> >>
> >> Adriano
> >>
> >> Over the year I have had the pleasure of being in many conversations
> about what a stateless protocol is, what REST is, HTTP, polling,
> asynchronous notifications, web based RPC, and blowing soap bubbles.  Though
> interesting, I have a hard time concretely explaining it to anyone and the
> oxygen always seems a bit thin at the 10,000 foot view. I do however have a
> very easy time understanding a very low level view of the systems where
> there are  some boxes and arrow diagrams of  message flow and roughly the
> semantics of the data they cary. Let me try and draw my current
> understanding of how this is going to work.
> >>
> >> Sink starts by sending a message I will label "SUB" to the Source. The
> SUB messages says which resource the Sink would like to be informed about
> when the resource changes. The Source sends a OK or No there is a problem in
> some sort of ACK message to the SUB. Eventually the resource changes and
> Source sends an message I called "NOTIFY" to the Sink. This tells the Sink
> which resource changed and the current value of it.The Sink sends some sort
> of acknowledgment. I find the terms client and server very confusing when
> discussing SUB/NOT so I'm not using those terms.
> >>
> >> The Sink could be a HTTP proxy that mapped this to COMET, WebSocket, or
> plain old polling, XMPP, SMTP, just about anything. As far as I can tell,
> pretty much everything people have been proposing fit into this model.  So
> first, I'd like to get an idea if people think I am in left field and there
> is a very different message flow to consider. Second we need to figure out
> some of the stuff I left out of the picture above such as
> >>
> >> [the ACK  could be a response message containing the current value of
> the subscribed resource at time of subscription]
> >>
> >> [it seems application specific; for example, you can define a sort of
> trigger with thresholds and hysteresis to avoid bouncing]
> >>
> >> [it seems application specific; sink and source nodes can agree on a
> subscription lifetime: sink can refresh the subscription by sending a new
> SUB request]
> >>
> >> We have to be clear on how this maps to HTTP and possibly other
> protocols. One of the problems with HTTP is it has so many ways of doing
> asynchronous notifications that it hard to decide what to map for. I would
> be very conformable if we clearly new how to map it to HiBy and to direct
> HTTP polling. It would be nice to have  back of the cocktail napkin belief
> that it probably could be mapped to SMNP, XMPP, and the other HTTP
> approaches. My guess is that the mapping to other protocols is going to turn
> out to be easy.
> >>
> >>
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Mon, 7 Jun 2010 09:59:14 +0200

*   Source                   Sink
     |           GET          |

* To realize this we can define some Options that will make that GET (or
POST?) request have the same meaning of a SUBSCRIBE (seems easier to define
new Options to make this eventually adopted by HTTP, or maybe there is some
Option already there we can overload in some way).

Angelo
*
> I can see how that works but looks like it might involve a few roundtrips.
What SIP does is it "refreshes" the subscriptions with an expiry time of
zero which causes it to instantly expire and go away. More of how the
refresh works down in point d.
>> [the ACK  could be a response message containing the current value of the
subscribed resource at time of subscription]
>
> I can easily imagine something where a COAP cache or caching proxy to HTTP
just subscribes to the resource. That way the cache is always up to date and
when the cache receives a GET or SUBSCRIBE for the resource, it can just
respond with the correct data. The device that has the resource can sleep
and just update the cache any time the resource changes. To make a scheme
like this work really well it might be nice if a Source that received a SUB
could redirect the Sink to send the subscribe to a cache that the Source
knew was willing to cache the data. It also allows a cache that see a NOTIFY
go by to update it data for that resource.
>> [the ACK  could be a response message containing the current value of the
subscribed resource at time of subscription]

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Mon, 7 Jun 2010 10:30:11 +0200

Hi

not sure to understand but it sounds as an interesting way to see things. Multiple response messages to the same initial GET request message?

The initial GET request acts as subscription request to a certain resource. The first response message returns the value of the resource at time of subscription and subsequent responses act as notification messages about resource changes in the time.

Questions:

how to keep track of initial GET request and subsequent responses? using a sort of transaction id shared among request and responses messages?

how to distinguish this by a classic GET request/response transaction (one request followed by only one response)?

how to realize spontaneous notifications, i.e. notifications no triggered by a subscription? 

Adriano

From: [email-masked] [mailto:[email-masked]] On Behalf Of Angelo P. Castellani
Sent: lunedì 7 giugno 2010 9.59
To: Cullen Jennings (fluffy)
Cc: Adriano Pezzuto (apezzuto); core
Subject: Re: [core] SUB/NOT - the sea level view

I agree with Adriano comments, and I really like the POST/DELETE (or GET?) mapping of the subscriptions. We really need to define new HTTP verbs to define a standard a subscription format?

A solution can be, a SUBSCRIBE action is nothing more than a GET which responses are repeated using some criterion (threshold, every N seconds, etc.).

The trigger of the response, in my opinion, can be ranging a lot depending upon the application, so could be inserted in the body of the request. A possible version of the body format can be agreed, however it should be extensible to fit particular cases.

ACK'ing the request or the responses is really transport dependant. If we use TCP, ACKs are already there. If we use UDP, some ACK packet format can be agreed to provide some level of reliability to UDP. etc.

   Source                   Sink       
     |           GET          |         

To realize this we can define some Options that will make that GET (or POST?) request have the same meaning of a SUBSCRIBE (seems easier to define new Options to make this eventually adopted by HTTP, or maybe there is some Option already there we can overload in some way).

In this way we have easily the very initial value, and because the packet format is the same for a standard response and for a NOTIFY its easier for a CoAP/HTTP proxy to update its cached value.

Subscription can be updated/refreshed/deleted with the same message GET (or POST?) message (delete -> Repeats=false) and we can get in this way the value on subscription deletion.

In this way I'm quite confident that node software architecture also can be simpler, because a lot of code/procedures can be shared between GET and SUBSCRIBE/NOTIFY with no particular effort.

Angelo

---

From: Guido Moritz <[email-masked]>
Date: Mon, 7 Jun 2010 23:10:23 +0200

Are we discussing the same topic now in 2 separated threads?

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

>Multiple response messages to the same initial GET request message?

In the thread of the link above is already a discussion raised by Zach about
asynchronous messaging pattern that fits into this question.

Jep, ist required. But not only for subscriptions, because of async
messaging for all messages!

>how to fit with REST requirements? safety/idempotency?

That’s the beaf. Is sub/not THE extension that does not fit into REST?

Same as above. GET is semantically clear for a single request/response, but
not as both singe GET and event subscription.

by a subscription? 

What is a notification without a subscription? Broadcasting messages? Spam?

Guido

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Adriano Pezzuto (apezzuto)
Gesendet: Montag, 7. Juni 2010 10:30
An: Angelo P. Castellani; Cullen Jennings (fluffy)
Cc: core
Betreff: Re: [core] SUB/NOT - the sea level view

Hi

Questions:

how to realize spontaneous notifications, i.e. notifications no triggered by
a subscription? 

Adriano

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Angelo P. Castellani
Sent: lunedì 7 giugno 2010 9.59
To: Cullen Jennings (fluffy)
Cc: Adriano Pezzuto (apezzuto); core
Subject: Re: [core] SUB/NOT - the sea level view

   Source                   Sink       
     |           GET          |         

To realize this we can define some Options that will make that GET (or
POST?) request have the same meaning of a SUBSCRIBE (seems easier to define
new Options to make this eventually adopted by HTTP, or maybe there is some
Option already there we can overload in some way).

Angelo

---

From: Guido Moritz <[email-masked]>
Date: Mon, 7 Jun 2010 23:12:11 +0200

I apologize, but I cross post the answer in both threads handling the same
topic (from my point of view). 

----------------------------

by a subscription? 

Guido

Hi

Questions:

Adriano

   Source                   Sink       
     |           GET          |         

Angelo

---

From: Mark Baker <[email-masked]>
Date: Mon, 7 Jun 2010 17:19:33 -0400

> it only changes the way the resource *reports* its actual state.

The issue with GET and safety isn't whether the resource changes state
or not, its that the client is explicitly *only* asking that
information be returned.

What you're describing here is where the sender of the GET has the
intention of establishing a long-lived relationship.  Such an exchange
is therefore *not* safe, and so cannot use GET.

Mark.

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 8 Jun 2010 14:27:38 +0200

Mark,

I understand your point, however I write just some more thoughts about this.

Reading RFC2626 Sec. 9.1.1, what I understand using a GET or a HEAD implies
that no action is taken on the server. In this way an user knows that GET is
a "safe" request, no "damage" can happen because of this.

But if one GET is safe, a recurrent GET seems still safe; surely a
relationship is defined (at transport when possible and yes it can be very
long).

Having a look at the RFC is said that GET SHOULD be safe (no MUST)...

In my opinion there are benefits in choosing GET to do something like this,
mainly the simplified software architecture in the node and/or proxy.

Best,
Angelo

---

From: Mark Baker <[email-masked]>
Date: Tue, 8 Jun 2010 09:07:59 -0400

> relationship is defined (at transport when possible and yes it can be very

I don't follow.  The meaning of each GET message is independent of the
connection on which it arrives, so there's no relationship there.

> Having a look at the RFC is said that GET SHOULD be safe (no MUST)...

Right.  See the last paragraph of 9.1.1 for an explanation of why
that's the case.  That's really the key point here.

> mainly the simplified software architecture in the node and/or proxy.

I can't see any significant benefits over using an existing unsafe
method, or the creation of a new method.

Mark.

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 8 Jun 2010 16:18:19 +0200

Mark,

there could be benefits in the constrained node/proxy sw architecture,
because it doesn't need to handle a method different from GET but only a
specialization using option(s) of GET... Code to handle this is supposed to
be directly reusable and shared with GET.

However it is not a very strong optimization, so if using GET there is a
substantial violation of the HTTP specification (I can't understand fully
the reason, GET is a read-only method and Subscribed-GET will be the same),
I agree with you that another method (or a new one) should be used.

Best,
Angelo

---

From: Zach Shelby <[email-masked]>
Date: Fri, 11 Jun 2010 15:10:37 +0300

I think I didn't answer to this earlier. 

> Over the year I have had the pleasure of being in many conversations about what a stateless protocol is, what REST is, HTTP, polling, asynchronous notifications, web based RPC, and blowing soap bub…

You have the honor of getting the CoRE WG's first ticket Cullen! We'll think of a prize in Maastricht (beer works?). Now this also means you need to write a 2-page ID on this once we converge so that the WG doesn't forget what we decided upon ;-)

> We have two nodes - I will call them Source and Sink. 

Source and Sink - YUCK. If we don't want to use client/server then I think Robert's suggestion of consumer/provider is better.

>      |    SUB      |         

This is also my understanding of what we want to achieve. 

> Sink starts by sending a message I will label "SUB" to the Source. The SUB messages says which resource the Sink would like to be informed about when the resource changes. The Source sends a OK or…

One thing missing in this high-level description is that NOTIFY keeps happening until the SUB times out. So we can think of a  SUB resulting in a single NOTIFY to be equivalent to a long poll. 

I do think it is important in the diagram above that we are able to ACK both the subscribe and the NOTIFY. 

> The Sink could be a HTTP proxy that mapped this to COMET, WebSocket, or plain old polling, XMPP, SMTP, just about anything. As far as I can tell, pretty much everything people have been proposing f…

Regarding an HTTP proxy, we should decide on one other important model concept here. When we talk about "mapping" SUB/NOT to HTTP - we should strictly be considering a split-model where the HTTP proxy performs the needed SUBs on behalf of whatever mechanism is used on the HTTP side, and the resulting NOTIFY is cached and then used by the HTTP side mechanism. This also serves to shield constrained devices from way too many subscribers out there. This brings me to another point - we need to assume that a constrained end-point will only be able to handle a small number of simultaneous subscriptions. 

> a) how to cancel a subscription 

Update the SUB (re-subscribe) with a zero lifetime. 

> b) how to get the initial value of the subscription around the time you subscribe 

This can be included by default in the ACK to the SUB.

> c) what sort of filtering is available to limit the types of resource changes that result in a NOTIFY 

In my opinion this is out of scope for CoAP. If the application wants to include a payload-specific filter it need to do that in the payload of the SUB message.

> d) lifespan of subscription how to refresh a subscription

We need a SUB_LIFETIME parameter for every SUB message. The subscription is refreshed by sending the SUB again.
> e) caching and interaction with sleeping device 

One important requirement is for a cache to easily be able to cache responses to a request for resource A  as well as a NOTIFY about resource A. So both the GET and the NOTIFY must contain the same URI.

We do need to consider how a subscriber is able to get the first SUB to a sleeping device. Is an intermediate proxy able to cache a SUB message until a sleeping device wakes up? How does it determine that the device woke up? 

> We have to be clear on how this maps to HTTP and possibly other protocols. One of the problems with HTTP is it has so many ways of doing asynchronous notifications that it hard to decide what to ma…

Yep, I agree. And even the mapping to HTTP is easy with the split model as the NOTIFY is simply cached. After that the HTTP side can offer the resource to polls, HiBy, Webhooks or whatever. 

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