[core] SUB/NOT - the sea level view

Cullen Jennings <fluffy@cisco.com> Fri, 04 June 2010 18:34 UTC

From: Cullen Jennings <fluffy@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-1-1016490393"
Impp: xmpp:cullenfluffyjennings@jabber.org
Date: Fri, 04 Jun 2010 12:33:53 -0600
Message-Id: <C07D3949-3CC2-4BB1-B8B6-6C2011675D50@cisco.com>
To: core <core@ietf.org>
Mime-Version: 1.0 (Apple Message framework v1078)
Subject: [core] SUB/NOT - the sea level view
Precedence: list

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.

[core] SUB/NOT - the sea level view Cullen Jennings
Re: [core] SUB/NOT - the sea level view Adriano Pezzuto (apezzuto)
Re: [core] SUB/NOT - the sea level view Cullen Jennings
Re: [core] SUB/NOT - the sea level view Angelo P. Castellani
Re: [core] SUB/NOT - the sea level view Angelo P. Castellani
Re: [core] SUB/NOT - the sea level view Adriano Pezzuto (apezzuto)
Re: [core] SUB/NOT - the sea level view Guido Moritz
Re: [core] Subscribe/Notify for CoAP Guido Moritz
Re: [core] SUB/NOT - the sea level view Mark Baker
Re: [core] SUB/NOT - the sea level view Angelo P. Castellani
Re: [core] SUB/NOT - the sea level view Mark Baker
Re: [core] SUB/NOT - the sea level view Angelo P. Castellani
Re: [core] SUB/NOT - the sea level view Zach Shelby