Subject: Re: [core] Subscribe/Notify for CoAP

From: Guido Moritz <[email-masked]>
Date: Wed, 2 Jun 2010 08:21:54 +0200

Dear WG,

I agree to focus on the ToDos and not on the maybes. But a comprehensive
eventing concept includes more than only the method/message type. It
requires lease concepts, filtering mechanisms ... It would also require
mechanisms to assign incoming NOTIFYs to a specific SUBSCRIBTION if one and
the same client has SUBSCRIBED to more than one event of the same device. Is
this out of scope of COAP or should it be considered already at this point
to have a straight forward and clean protocol design? Hence it might be
reasonable to have SUBSCRIBE and NOTIFY as single methods and grouping every
sub functionality as type below the method?

However, as HTTP has no native mechanism to feature eventing, for eventing
it would be always required to have a caching intermediate entity (proxy,
gateway, what ever). This one can provide which interface ever to the
external networks (HTPP, polling, WebHooks, XMPP, WS-Eventing, ...). So this
is implementation specific and might not be considered in COAP at all.

Guido

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Zach
> Shelby
> Gesendet: Freitag, 28. Mai 2010 14:50
> An: Adriano Pezzuto
> Cc: core
> Betreff: Re: [core] Subscribe/Notify for CoAP
> 
> Hi,
> 
> This is a really good conversation. One thing we need to do is remember
what
> our minimum requirements are for subscribe/notify and not try to solve
> something more than we should. From what I know it is sufficient to be
able to
> receive notifications when a URI changes or periodically. You might
consider
> new URIs under this URI path to be changes to a URI though...
> 
> On May 28, 2010, at 3:08 PM, Adriano Pezzuto (apezzuto) wrote:
> 
> > Hello,
> > with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no
> needs to have an explicit SUBSCRIBE method.
> 
> This is what coap-01 assumes.
> 
> > If we want support a more oriented peer-to-peer transaction on CoAP, it
> looks to me both SUB and NOTIFY should be treated as messages.
> 
> The Request/Response model can be used peer-to-peer, and in CoAP you can
even
> use a Request asynchronously. Additionally, we want a native RESTful
> subscribe/notify technique, that is, we want to subscribe to resources and
be
> susequently notified about those resources when they change.
> 
> In that sense, you can think of a subscription as a request to receive
> asynchronous notifications about a resource (about a URI). This can be
> achieved by:
> 
> 1.  as a SUBSCRIBE Request on the URI with some option indicating the
lifetime
> as in coap-01,
> 2.  as a Subcsribe message (no methods) on the URI with some option,
> 3.  or as a POST Request on the URI with options indicating that this is
> actually a subscription and the lifetime.  This bends the meaning of POST
> quite a bit and might be prone to mistakes?
> 
> The asynchronous response is a harder one. Can we bend the meaning of a
> Request for making asynchronous notifications? Also a notification
includes a
> URI about a resource on the requestor, which is inverse from normal
Requests
> in REST. So the options here are:
> 
> 1. as a Notify message about a URI (no methods) as in coap-01,
> 2. as a NOTIFY Request about a URI as was in coap-00,
> 3. hmmm... reusing CRUD methods really doesn't work for this one at all...
> 
> I wonder what the HTTP designers would have done if this would have been a
> requirement back then? Maybe we should ask them...
> 
> Zach
> 
> >
> > Adriano
> >
> > From: [email-masked]
> [mailto:[email-masked]]
> > Sent: venerdì 28 maggio 2010 13.52
> > To: Adriano Pezzuto (apezzuto)
> > Cc: core; [email-masked]; [email-masked]
> > Subject: Re: [core] Subscribe/Notify for CoAP
> >
> > > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not
> methods!
> >
> > SUBSCRIBE can be just an asynchronous GET on update then I think it is a
> method and NOTIFY is an asynchronous response so a message.
> > But if we want to have selective notifications when a resource is
created,
> updated or deleted then I think you're right NOTIFY and SUBSCRIBE are
> messages.
> >
> > Does that make sense ?
> >
> > Matthieu
> >
> > "Adriano Pezzuto (apezzuto)" <[email-masked]>
> >
> >
> >
> >
> > "Adriano Pezzuto (apezzuto)" <[email-masked]>
> > Envoyé par : [email-masked]
> > 28/05/2010 12:50
> >
> > A
> > <[email-masked]>
> > cc
> > core <[email-masked]>
> > Objet
> > Re: [core] Subscribe/Notify for CoAP
> >
> > Hi Roberto,
> > I understand your point and personally agree on M2M is quite different
from
> web page model. On the architectural RESTful style, the method information
> tells the server what to do with data kept in the URI information.
> >
> > So strictly speaking, both NOTIFY and SUBSCRIBE are message types not
> methods!
> >
> > Adriano
> >
> > From: Robert Cragie [mailto:[email-masked]]
> > Sent: venerdì 28 maggio 2010 11.53
> > To: Adriano Pezzuto (apezzuto)
> > Cc: Paul Duffy (paduffy); Zach Shelby; core
> > Subject: Re: [core] Subscribe/Notify for CoAP
> >
> > I think the point here is that there are two levels we are considering.
> >
> > At the lowest (foundation) level, there are the transaction messages as
> described below. This provides a flexible mechanism for the application
with
> regard to synchronicity and threading. This is important for the types of
> devices CoAP is being aimed at.
> >
> > Above that, the methods can be used according to the architectural
style. So
> in this case, it is RESTful (COnstrained Restful Environments), which will
> naturally limit the number of methods and how transactions occur.
> >
> > The actual architecture using a combination of the methods and messages
also
> depends on what is required at the application layer. Consider a typical
> client which wants to subscribe to a resource. That client controls the
feed
> of data but needs a component which is capable of handling (possibly
> buffering) the data it receives through notifications. Is this a separate
> server? Or would we want to consider it part of an enhanced client model
which
> is able to process feeds of data? These are the sort of models which have
led
> to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub,
RESTMS
> etc.) based around HTTP which are all essentially ingenious ways of
getting
> around the limitations imposed by HTTP and how it is processed for
anything
> which deviates from the classic web page access model.
> >
> > I think the aim of CoAP should be clean from the word go with regard to
> supporting these more peer-to-peer transactions, where the client can
exist on
> either entity and both entities can feed data to each other; typical in
M2M
> applications.
> >
> > Robert
> >
> > Robert Cragie (Pacific Gas & Electric)
> >
> > Gridmerge Ltd.
> > 89 Greenfield Crescent,
> > Wakefield, WF4 4WA, UK
> > +44 1924 910888
> > +1 415 513 0064
> > http://www.gridmerge.com
> >
> > On 27/05/2010 7:08 PM, Adriano Pezzuto (apezzuto) wrote:
> > Hi Robert,
> >
> > in my personal opinion, the option 1a) brings some sort of ambiguity to
CoAP
> specs.
> >
> > My be my understatement of new CoAP specs is not so deep, but now we
have 5
> methods and 3 message types: request, response and notify. Which methods
are
> allowed with which messages types?
> > I suppose you have to use PUT/POST method with notify message for asynch
> data notification. How to make a subscribe? I suppose you would use a
> SUBSCRIBE method with request/response message or SUBSCRIBE with notify
> message? Also what about POST/DELETE methods in a notify message? They not
> make any sense..
> >
> > I think the choice is between: option 1) -> only CRUD methods and option
1b)
> -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both
solutions.
> >
> > Adriano
> >
> > From: Robert Cragie [mailto:[email-masked]]
> > Sent: mercoledì 26 maggio 2010 20.09
> > To: Adriano Pezzuto (apezzuto)
> > Cc: Paul Duffy (paduffy); Zach Shelby; core
> > Subject: Re: [core] Subscribe/Notify for CoAP
> >
> > Hi Adrian,
> >
> > I would also prefer to keep the protocol in CoAP asynchronous. You can
> always map an asynchronous protocol to a synchronous one but, as we see in
> HTTP, it always ends up as a kludge to do it the other way round. The
efforts
> which have been gone to to make HTTP quasi-asynchronous via all the
schemes
> mentioned below and many more besides (all non-interoperable of course) is
> testament to how important this is for M2M communication.
> >
> > So, back to Zach's list, I favor 1a) for the following reasons:
> >
> > Foundation level of messages:
> >
> > 1. request/response can be asynchronous or synchronous messages (as
there is
> a transaction ID in there)
> > 2. notify is an asynchronous message
> > Derived methods:
> >
> > I think it makes sense to add a pub/sub model as a useful mechanism for
M2M.
> >
> > So, looking at it the other way round: It will be entirely possible to
> translate whatever is currently built on HTTP to CoAP based on the above,
with
> all its restrictions regarding synchronous and client/server transactions.
> What may be harder is to translate directly is a CoAP-based application to
> HTTP. So I guess the question is: Do we want to be hamstrung to
synchronous
> client/server transactions as dictated by HTTP and provide a direct
mapping to
> HTTP, then have to come up with similar kludges for asynchronous
peer-to-peer
> transactions as has been done in numerous ways for HTTP, or do we want to
> define the protocol cleanly to start with and accept that some sort of
> transaction relaying/conversion would have to take place at a mapping
node?
> >
> > Robert
> > Robert Cragie (Pacific Gas & Electric)
> >
> > Gridmerge Ltd.
> > 89 Greenfield Crescent,
> > Wakefield, WF4 4WA, UK
> > +44 1924 910888
> > +1 415 513 0064
> > http://www.gridmerge.com
> >
> > On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
> > Hi,
> > it looks to me that CoAP should use an explicit sub/notify mechanism
since
> this is the core of the machine-to-machine interaction model.
> > HTTP suffers of this lack and we have seen a plethora of solutions to
give
> an asynch taste to it. Webhooks and websockets are only the lasts of the
list.
> > As someone has already pointed out on this list, it is theoretically
> possible to describe sub/notify using only CRUD methods but it looks a
little
> bit tricky and verbose.
> >
> > Now we have a chance to build from scratch a new protocol with and I
think
> using explicit sub/notify methods with a clear and well defined semantic
is
> the best option. It is easily understanding from every developer and will
> prevent to build other fanny solutions on top of the CoAP. HTTP does not
have
> this well defined semantic and (for hundreds of other reasons also) it is
not
> used as wide protocol for machine-to-machine communication.
> >
> > CoAP - as binary protocol - and with an explicit asynch model has a
chance
> to be a really wide protocol for M2M communication not only for
constrained
> environments.
> >
> > my 2 cents
> >
> > - adriano
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul
> Duffy (paduffy)
> > Sent: mercoledì 26 maggio 2010 0.47
> > To: Zach Shelby
> > Cc: core
> > Subject: Re: [core] Subscribe/Notify for CoAP
> >
> > On 5/25/2010 6:41 PM, Zach Shelby wrote:
> >
> > Hi,
> >
> > On May 26, 2010, at 12:23 AM, Charles Palmer wrote:
> >
> >
> > Hi folks
> >
> > It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0
> work, so that it is as easy as possible for ZigBee SE to use CoRE when
ready.
> That suggests to me that we should align with their subscribe/notify
process.
> >
> >
> > I am not sure I understand that. I mean, ZigBee SE2.0 is defining an
> application specific subscribe/notify mechanism for that purpose so far
for
> HTTP. This uses standard HTTP methods and some custom payload and REST
> interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that
> respect, so alignment is already OK there. Nothing stopping someone from
using
> SE2.0 over CoAP.
> >
> > Specifying a native susbcription/notify into CoAP is another matter. We
> can't adopt a solution specific to one application as that won't solve the
> problems of other applications nor general HTTP mapping at all (probably
would
> make it worse). It seems that for the near future there will be a bunch of
> HTTP push mechanisms in use without any clear standard appearing - or am I
> wrong there?
> >
> >
> >
> >
> > If COAP extends HTTP semantics with new subscription methods, it will
> > not be possible to easily interchange HTTP/COAP, and translation
> > gateways will become more complex to implement.
> >
> >
> >
> > Zach
> >
> >
> > Regards - Charles
> >
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul
> Duffy
> > Sent: 25 May 2010 03:48
> > To: Zach Shelby
> > Cc: core
> > Subject: Re: [core] Subscribe/Notify for CoAP
> >
> > Recommend something like #2, primarily to avoid introducing non HTTP
> > method semantics, simplifying HTTP/COAP translation.gateways, etc.
> >
> >
> > On 5/24/2010 11:49 AM, Zach Shelby wrote:
> >
> > (thread renamed)
> >
> > We have two different paths with regard to a subscribe/notify mechanism
for
> CoAP:
> >
> > 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP
really
> does not include this concept.
> > 1a) Notify as a message and SUBSCRIBE as a method. This is currently
used in
> coap-01.
> > 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we
had a
> good list discussion about this leading to a. In practice it doesn't make
a
> big difference if notification is a message or method.
> >
> > 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0
> proposal or GENA.
> >
> > So far we have focused on 1 in the WG, and every now and again 2 comes
up.
> At least I am not convinced that we need to suffer the drawbacks of HTTP
here.
> Anyways 2 does not help our mapping to HTTP in reality very much as there
is
> no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up
> anyways translating between multiple HTTP frameworks depending on the
> application. So instead of doing a CoAP Notify/Subscribe to Webhooks
mapping,
> you will could end up having to do a CoAP Webhooks to HTTP GENA mapping.
> >
> >
> >
> > I don't understand this last para. If CoAP sticks to the semantics of
> > the current HTTP methods, would this not offer a fairly straightforward
> > translation to/from HTTP?
> >
> >
> >
> > From what I have heard so far 1 still seems like a wise choice, although
I
> need to look at Webhooks more deeply. In reality many applications specify
> their own way of doing a push interface using REST methods and specific
> payloads (ZigBee SE2.0 is such an example). That is just fine, and might
be
> used instead of a specific CoAP notify/subscribe in that case. So 1
doesn't
> prevent the application using its own mechanism, it just provides a native
way
> for doing push.
> >
> > What do people think?
> >
> > Zach
> >
> > On May 17, 2010, at 6:44 PM,[email-masked]
> wrote:
> >
> >
> >
> > Hi,
> >
> > My comments about the subscribe/notify mechanism of Zigbee IP.
> >
> > Pros:
> > - Derived from the webhooks concept
> > - If used by CORE it will be easier to map to HTTP because it uses only
CRUD
> verbs.
> > - The subscription message is extendable and could support advanced
options
> (delays, increment, ...)
> > - Only one listening port whatever the transport binding is.
> >
> > Cons:
> > - No interoperability without well known URIs and a well defined
> subscription message format (Not sure CoAP draft is the right place to
specify
> this).
> > - XML/EXI is too complex to be the required format for the default
> subscription/notification mechanism.
> > - The notification should not require a subsequent GET to retrieve the
> content.
> > - Subresource subscription is redundant.
> >
> > Hope this could help,
> > Matthieu
> >
> >
> > "Charles Palmer"<[email-masked]>
> >
> >
> >
> >
> > "Charles Palmer"<[email-masked]>
> > Envoyé par : [email-masked]
> > 15/05/2010 14:06
> >
> > A
> > "core"<[email-masked]>
> > cc
> > Objet
> > Re: [core] Selecting a WG document for CoAP
> >
> > Dear all
> >
> > Those interested in the subscribe/notify discussion might like to look
> > at the draft Smart Energy Profile 2.0 Application Protocol
> > Specification. It is available here:
> > http://zigbee.org/Markets/ZigBeeSmartEnergy/ZigBeeSmartEnergy20PublicApp
> > licationProfile.aspx
> >
> > It manages subscribe/notify by using POST. This seems to remove the need
> > for SUBSCRIBE and notify.
> >
> > "Imagine a host A, which exposes a resource at http{s}://A/resource and
> > a second host B, which wishes to learn of changes to this resource. To
> > facilitate a subscription/ notification mechanism, A would expose a
> > resource http{s}://A/sub and B would expose a resource http{s}://B/ntfy.
> > To subscribe to notifications regarding http{s}://A/resource, B would
> > send a POST to the address http{s}://A/sub/B containing the URI of the
> > resource of interest (http{s}://A/resource) and the URI of B's
> > notification resource (http{s}://B/ntfy). Following this subscription
> > step, should A wish to notify B of a change to the resource addressed at
> > http{s}://A/resource, A would send a POST to the address
> > http{s}://B/ntfy containing the URI of the resource changed
> > (http{s}://A/resource) and the URI of A's subscription resource
> > (http{s}://A/sub/B), should A wish to change its subscription. The host
> > B can then query the resource (or not) at its leisure."
> >
> > Sleepy nodes are not allowed to subscribe, and must poll.
> >
> > Regards - Charles Palmer
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Angelo P. Castellani
> > Sent: 14 May 2010 13:14
> > To: Zach Shelby
> > Cc: core
> > Subject: Re: [core] Selecting a WG document for CoAP
> >
> > Zach,
> >
> > thanks for the comments, but please refer to my most recent e-mail for
> > a more specific list of technical issues I'm pointing to.
> >
> > I want to do only a little integration to what I've written there.
> >
> > In my very personal opinion, to maximize adherence with the REST model
> > and minimize implementation effort SUBSCRIBE and NOTIFY should be
> > mapped to methods (as discussed many times together...).
> >
> > Uniform interface principle (Fielding PhD dissertation Section 5.1.5,
> > "The central feature that distinguishes the REST architectural style
> > [...]") states that to simplify the software architecture, resource
> > interfaces/interfaces should be as general as possible.
> >
> > I agree with this principle in this specific case, mainly because
> > handling a special message type for notify leads node software design
> > to a more complex architecture.
> >
> > The reason is that this new message type requires special handling and
> > introduces a complexity in the software modularization.
> >
> > Best,
> > Angelo
> >
> > On Fri, May 14, 2010 at 13:06, Zach Shelby<[email-masked]> wrote:
> >
> >
> > Hi Angelo,
> >
> > On May 13, 2010, at 14:24 , Angelo P. Castellani wrote:
> >
> >
> >
> > Dear C. Bormann, all,
> >
> > before deciding for the final direction, I've the following
> > observations about draft-shelby-core-coap-01
> >
> > While I mostly share Zach's view of the protocol approach, and
> > appreciate many aspects of the proposal, there are in my opinion
> >
> >
> > still
> >
> >
> > some open issues that need to be at least discussed before the
> >
> >
> > current
> >
> >
> > document can be selected.
> >
> >
> > Of course there are plenty of open issues. Remember that working group
> >
> >
> > documents still undertake as much change and improvement as the WG
> > wants, so by no means is coap-01 set in stone. I would expect at least
> > 5-10 more revisions still along the way. Already several of your ideas
> > have been integrated into coap-01, and several more are under
> > consideration, so it is coming along. Patience ;-)
> >
> >
> >
> > In particular, I would like to highlight the following:
> >
> > a) As it is now, it is not possible to have a straightforward
> > translation of HTTP -> CoAP and viceversa: see
> > http://www.ietf.org/mail-archive/web/core/current/msg00133.html (this
> > impacts the scalability of the web service model too)
> >
> >
> > In coap-01 the Method names are now identical to HTTP methods. The
> >
> >
> > Req/Res interaction is a direct translation. The URI hierarchy is
> > compatible, and the URI binary code format we are still working on
> > obviously. The only thing that takes some state to translate is
> > Subscribe/Notify. But note, Subscribe/Notify takes some state no matter
> > how you do it, even with HTTP-HTTP there is no clean and easy way to
> > handle subscriptions.
> >
> >
> >
> > b) Moreover, CoAP's implementation is not as simple as it should be.
> > I've investigated the implementation and some design choices (as
> > Options) are leading to very high program complexity (ROM) on a
> > MSP430-based device.
> >
> >
> > This we can definitely improve, and already made several optimizations
> >
> >
> > from -00 to -01. Here I need some very concrete proposals though. Also
> > remember that many things are optional, for example subscribe/notify is
> > not required if you don't need it.
> >
> >
> >
> > c) Finally when comparing HTTP message size with CoAP message size,
> > the resulting compression isn't as good as you may expect.
> >
> > Example:
> > HTTP: GET /sensor/temp.xml HTTP/1.0 = 32 B
> > CoAP: 24 B with options parsing procedure requiring an added
> > implementation complexity
> >
> >
> > Right, that is not how it will work in practice. Working with a real
> >
> >
> > HTTP server that HTTP header will be more complex, and on the CoAP side
> > you would chose shorter URLs. The biggest improvement possible here is
> > from using binary coded URLs of course. We need to look at a wider range
> > of interactions and real HTTP headers as well to check that we are
> > efficient enough.
> >
> >
> >
> > Addressing all these points potentially leads to major technical
> > modifications (especially point a) on the current draft, hence it is
> > appropriate in my opinion to discuss these points before making the
> > final decision.
> >
> >
> > I am not sure what else you have in mind for a). If we just forget
> >
> >
> > about Subscribe/Notify then you are good to go. But then you are also
> > not fulfilling the charter or the industry needs in that respect.
> >
> >
> > Thanks,
> > Zach
> >
> >
> >
> > Best regards,
> >
> > Angelo P. Castellani
> >
> >
> > On Mon, May 10, 2010 at 18:51, Carsten Bormann<[email-masked]>wrote:
> >
> >
> > The CORE WG has a milestone to select a WG document for CoAP in
> >
> >
> > April:
> >
> >
> > http://datatracker.ietf.org/wg/core/charter/
> > ...
> > Apr 2010 Select WG document for basis of the CoAP protocol
> >
> > Of the various documents that have been contributed,
> >
> >
> > draft-shelby-core-coap has significant discussion, as well as the
> > largest number of updates (including a previous version that was still
> > called -6lowapp-coap).
> >
> >
> > Today, another updated version of that draft was announced. See
> > http://www.ietf.org/mail-archive/web/core/current/msg00138.html
> > for the announcement and
> > http://tools.ietf.org/html/draft-shelby-core-coap-01
> > for the draft itself.
> >
> > However, as the authors say, there are still significant TODOs.
> >
> > Are we in a state yet where we can say whether this is the right
> >
> >
> > direction for the WG to take?
> >
> >
> > If yes, is it the right direction? Should we adopt it as a WG
> >
> >
> > document?
> >
> >
> > If you don't think we can say yet, is there a set of technical
> >
> >
> > decisions you would like the authors to take with priority?
> >
> >
> > Note that once a document has become a WG document, the authors act
> >
> >
> > as editors for the working group, making (and usually fleshing out the
> > details of) any change that the WG decides it needs.
> >
> >
> > If you think we can still improve the draft, this is not an obstacle
> >
> >
> > to making it a WG document.
> >
> >
> > But of course we shouldn't do that if we intend to reverse its
> >
> >
> > fundamental technical direction.
> >
> >
> > In order to stay roughly in sync with our milestones, we should
> >
> >
> > reach at a decision on how to go forward this week.
> >
> >
> > Gruesse, Carsten
> >
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
> >
> >
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
> >
> > --
> > 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
> >
> >
> >
> >
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
> > --------------------------------
> > Onzo is a limited company number 06097997 registered in England& Wales.
The
> > registered office is 6 Great Newport Street, London, WC2H 7JB, United
> Kingdom.
> >
> > This email message may contain confidential and/or privileged
information,
> and
> > is intended solely for the addressee(s). If you have received this email
in
> > error, please notify Onzo immediately. Unauthorised copying, disclosure
or
> > distribution of the material in this email is forbidden.
> > --------------------------------
> >
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > ______________________________________________________________________
> >
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
> >
> >
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
> > --------------------------------
> > Onzo is a limited company number 06097997 registered in England& Wales.
The
> > registered office is 6 Great Newport Street, London, WC2H 7JB, United
> Kingdom.
> >
> > This email message may contain confidential and/or privileged
information,
> and
> > is intended solely for the addressee(s). If you have received this email
in
> > error, please notify Onzo immediately. Unauthorised copying, disclosure
or
> > distribution of the material in this email is forbidden.
> > --------------------------------
> >
> >
> >
> >
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
> >
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> >
>
____________________________________________________________________________
__
> _______________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> >
> > _______________________________________________
> > core mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/core
> 
> --
> 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
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Vlad Trifa <[email-masked]>
Date: Wed, 2 Jun 2010 10:12:34 +0300

Hi, sorry to join the discussion only now.

I think we should avoid explicitly defining a messaging/eventing  
construction in coap which would be an "add-on" on top of http. HTTP  
doesn't define any by design, but doesn't mean we can't use/create a  
pattern that implements this behavior, and we just just propose the  
pattern, not turn it into a design. It'd be more useful to stay as  
close as possible to the original http/rest (unless the mapping to  
http/web is more of an "nice-to-have"option that the motivation of  
doing coap), which means it's great if we can show show how to  
implement messaging on top of coap, but avoid inserting additional  
verbs, etc that would not be directly supported in http (thus making  
the mapping between coap-http more complex).

We just wrote a paper on Web-based restful messaging for embedded  
devices which will be presented next month at ICWE, and as it's highly  
relevant to this notification discussion thread, I thought I'd share  
it here.

Please let me know your thoughts/comments/questions,

thx!

Vlad

---

From: Paul Duffy <[email-masked]>
Date: Wed, 02 Jun 2010 20:10:20 -0400

+1

On 6/2/2010 3:12 AM, Vlad Trifa wrote:
>>>> On May 17, 2010, at 6:44 
>>>> PM,[email-masked]
>>> wrote:
>>>>
>>>>
>>>>
>>>> Hi,
>>>>

---

From: Paul Duffy <[email-masked]>
Date: Wed, 02 Jun 2010 20:17:17 -0400

Folks,

My understanding is that COAP is directed to the WEB of things.  I take 
that to mean going with the grain of pervasively  deployed WEB 
infrastructure.  Unless there is an overwhelming compelling reason to do 
otherwise, IMO COAP needs to implement a strict subset of HTTP 
semantics.  Otherwise, we open the door to complexity re: translating 
HTTP/COAP, and history has shown complex app gateways will always be a 
challenge.

There are several ways to support pub/sub using stock HTTP methods.  I 
suggest we do so.

Cheers

On 6/2/2010 2:21 AM, Guido Moritz wrote:
>>> "Adriano Pezzuto (apezzuto)"<[email-masked]>
>>>
>>>
>>>
>>>
>>> "Adriano Pezzuto (apezzuto)"<[email-masked]>
>>> core<[email-masked]>
>>> Robert Cragie (Pacific Gas&  Electric)
>>>
>>> Gridmerge Ltd.
>>> 89 Greenfield Crescent,
>>> Wakefield, WF4 4WA, UK
>>> +44 1924 910888
>>> +1 415 513 0064
>>> http://www.gridmerge.com
>>>
>>> Robert Cragie (Pacific Gas&  Electric)
>>>
>>> Gridmerge Ltd.
>>> 89 Greenfield Crescent,
>>> Wakefield, WF4 4WA, UK
>>> +44 1924 910888
>>> +1 415 513 0064
>>> http://www.gridmerge.com
>>>

---

From: Richard Kelsey <[email-masked]>
Date: Wed, 02 Jun 2010 22:31:29 -0400

> Date: Wed, 02 Jun 2010 20:17:17 -0400
> From: Paul Duffy <[email-masked]>
> 

Given the variety of ways people do pub/sub using stock HTTP
methods, it isn't clear that we can keep both COAP and the
COAP/HTTP gateways simple while still supporting multiple
pub/sub methods on the HTTP side.  By making the translation
of one form of HTTP pub/sub easy, we could easily make the
translation of others harder.

If we want to have COAP/HTTP gateways that support different
HTTP pub/sub methods, then it might be better to add pub/sub
to COAP directly, in a way that is not a strict subset of
HTTP.

Do we support several ways of doing pub/sub in HTTP, or just
one?  If we do pick just one, can others be easily translated
into it?
                                -Richard Kelsey

---

From: Zach Shelby <[email-masked]>
Date: Thu, 3 Jun 2010 10:47:03 +0300

> one?  If we do pick just one, can others be easily translated

So far I have seen at least 10 different ways of doing some kind of pub/sub/event/notify/feed over HTTP with no clear winner. If we choose one of those then we will end up fighting a war here about why we didn't choose someone's favorite. If we choose multiple then we are putting way too much complexity on constrained devices. If we make a new one then we are adding yet another to the mess. Regardless of what we do, a general CoAP-HTTP proxy will likely end up having to support multiple HTTP schemes.

Defining an HTTP mapping is one piece of our work here, but it is not the main design goal. CoAP will often be used end-to-end without HTTP translation, and mappings to other protocols such as XMPP will surely become common. 
One of our charter requirements is to provide a push mechanism as it is even more critical in embedded systems than on the Web today.

As a proxy doing CoAP-HTTP mapping will usually also be a caching proxy, I don't see a real complexity problem with doing native sub/notify inside the constrained network with CoAP. Receiving a notify about a CoAP resource simply updates the cache entry for that resource. The response to a GET updates the same entry. A proxy will also likely need to do subscription aggregation in the real-world to protect constrained nodes from handling lager numbers of subscriptions. So we can consider it a split model.

Another reason I have for preferring a native sub/notify mechanism for CoAP is that the current HTTP design patterns are just broken when it comes to REST. We can talk about that more, but overloading POST and PUT for making subscriptions and notification is confusing and involves more complexity and payload processing. That also makes caching notifications more difficult. Using an explicit SUBSCRIBE and NOTIFY follows the REST architecture better, is easier to understand, and simpler to implement. 

I think we should take a shot at an improved native mechanism for coap-02, implement it widely, and get some real HTTP mapping experience. Later in the WG process if we find that having native SUB/NOTIFY is more painful than beneficial (or if nobody is using it) we can always remove it and fall back on an HTTP pattern.

Zach

---

From: Mark Baker <[email-masked]>
Date: Thu, 3 Jun 2010 09:37:33 -0400

> Another reason I have for preferring a native sub/notify mechanism for CoAP is that the current HTTP design patterns are just broken when it comes to REST. We can talk about that more, but overload…

Agreed, more or less, for SUBSCRIBE, but I would expect that POST (and
possibly PUT, for notification updates) could replace NOTIFY.

I'd also like to point out that defining non-HTTP-native methods for
CoAP doesn't prevent a clean HTTP mapping.  It just means that you
also need to define them for HTTP.

Mark.

---

From: Geoff Mulligan <[email-masked]>
Date: Thu, 03 Jun 2010 07:56:15 -0600

+1!!

	geoff

---

From: "Stuber, Michael" <[email-masked]>
Date: Thu, 3 Jun 2010 08:17:48 -0700

+1.  

The joy (and curse) of simple protocols is that you can encapsulate just
about anything in them.  I think Zach's point about the wide variety of
mechanisms for doing sub/notify over HTTP is dead on.  For
interoperability in a constrained world, I would prefer a light-weight
native mechanism.  If a given application space settles on a particular
sub/notify paradigm for HTTP, they can build the translation between the
one they like and CoAp into their gateway.  Apps that run CoAp end to
end will have a clean, consistent, native way of doing sub/notify.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Zach Shelby
Sent: Thursday, June 03, 2010 12:47 AM
To: Richard Kelsey
Cc: [email-masked]
Subject: Re: [core] Subscribe/Notify for CoAP

So far I have seen at least 10 different ways of doing some kind of
pub/sub/event/notify/feed over HTTP with no clear winner. If we choose
one of those then we will end up fighting a war here about why we didn't
choose someone's favorite. If we choose multiple then we are putting way
too much complexity on constrained devices. If we make a new one then we
are adding yet another to the mess. Regardless of what we do, a general
CoAP-HTTP proxy will likely end up having to support multiple HTTP
schemes.

Zach

---

From: Mikko Saarnivala <[email-masked]>
Date: Thu, 03 Jun 2010 18:58:00 +0300

> end will have a clean, consistent, native way of doing sub/notify.

+1 - I completely agree

-- 
Mikko Saarnivala

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 10:37:21 -0600

>> end will have a clean, consistent, native way of doing sub/notify.

Does this imply that this group will define a new HTTP method for
sub/notify or a CoAp-specific method? If the latter, will this group use
HTTP methods for everything else?

Just curious to see where we stand on HTTP-native vs. CoAp-specific. I
freely admit that I might have missed the relevant discussion this list.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Stuber, Michael" <[email-masked]>
Date: Thu, 3 Jun 2010 09:41:32 -0700

CoAp specific.  My point is that a single CoAp specific method could be mapped to wide variety of HTTP mechanisms if desired.  I don't think there is any need for yet another HTTP sub/notify mechanism, and it certainly isn't in our charter to define one.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, June 03, 2010 9:37 AM
To: [email-masked]
Subject: Re: [core] Subscribe/Notify for CoAP

On 6/3/10 9:58 AM, Mikko Saarnivala wrote:
>> The joy (and curse) of simple protocols is that you can encapsulate 
>> just about anything in them.  I think Zach's point about the wide 
>> variety of mechanisms for doing sub/notify over HTTP is dead on.  For 
>> interoperability in a constrained world, I would prefer a 
>> light-weight native mechanism.  If a given application space settles 
>> on a particular sub/notify paradigm for HTTP, they can build the 
>> translation between the one they like and CoAp into their gateway.  
>> Apps that run CoAp end to end will have a clean, consistent, native way of doing sub/notify.
> 
> +1 - I completely agree

Does this imply that this group will define a new HTTP method for sub/notify or a CoAp-specific method? If the latter, will this group use HTTP methods for everything else?

Just curious to see where we stand on HTTP-native vs. CoAp-specific. I freely admit that I might have missed the relevant discussion this list.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: "Don Sturek" <[email-masked]>
Date: Thu, 3 Jun 2010 09:41:44 -0700

Hi Peter,

I assume the following from this discussion:
1)  We need a fixed mapping between CoAP and HTTP.  The relevant HTTP actions are GET, PUT, POST and DELETE
2)  We could re-use the same actions in CoAP or we could use something like Subscribe/Notify in CoAP then provide a mapping to HTTP GET, PUT, POST, DELETE.

Is this captured correctly?  

Don

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, June 03, 2010 9:37 AM
To: [email-masked]
Subject: Re: [core] Subscribe/Notify for CoAP

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 10:44:48 -0600

On 6/3/10 10:41 AM, Stuber, Michael wrote:
> CoAp specific.  My point is that a single CoAp specific method could
> be mapped to wide variety of HTTP mechanisms if desired. 

So, to clarify, will we use:

1. CoAp-specific methods for everything.

Or:

2. CoAp-specific methods only for sub/notify, and HTTP for everything else.

> I don't
> think there is any need for yet another HTTP sub/notify mechanism,
> and it certainly isn't in our charter to define one.

I fully agree with that sentiment.

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 10:54:23 -0600

> 2. CoAp-specific methods only for sub/notify, and HTTP for everything else.

Never mind, I hadn't revisited draft-shelby-core-coap in a while and
forgot that we were doing CoAp-specific methods for everything.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Stuber, Michael" <[email-masked]>
Date: Thu, 3 Jun 2010 10:00:30 -0700

I think the goal is for #1 and #2 to be the same thing.  That is, CoAp will provide commands that are the direct equivalent of GET, PUT, POST, and DELETE so that the mapping is 1 to 1 for these commands.  Of course, I would expect the implementations to be CoAp specific, as HTTP is text based and CoAp is designed as a binary protocol.  If you look at 3.2 of the Zach's CoAp draft it shows:

                           +-----------+------+
                           | Method    | Code |
                           +-----------+------+
                           | GET       | 0    |
                           | POST      | 1    |
                           | PUT       | 2    |
                           | DELETE    | 3    |
                           | SUBSCRIBE | 4    |
                           +-----------+------+

But maybe I've misunderstood your question.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Saint-Andre
Sent: Thursday, June 03, 2010 9:45 AM
To: [email-masked]
Subject: Re: [core] Subscribe/Notify for CoAP

Or:

> I don't
> think there is any need for yet another HTTP sub/notify mechanism, and 
> it certainly isn't in our charter to define one.

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 03 Jun 2010 11:13:44 -0600

On 6/3/10 11:00 AM, Stuber, Michael wrote:
> I think the goal is for #1 and #2 to be the same thing.  That is,
> CoAp will provide commands that are the direct equivalent of GET,
> PUT, POST, and DELETE so that the mapping is 1 to 1 for these
> commands.  Of course, I would expect the implementations to be CoAp
> specific, as HTTP is text based and CoAp is designed as a binary
> protocol.

Correct.

> But maybe I've misunderstood your question.

My question was misinformed. Please ignore. :)

---

From: Robert Cragie <[email-masked]>
Date: Thu, 03 Jun 2010 20:59:10 +0100

HTTP was designed to work on a synchronous client/server model. Whilst 
that may suit desktop PC's running browsers and servers running httpd, 
it is not entirely appropriate for M2M. The plethora of schemes to 
implement push processing for HTTP (all incompatible) goes to show that 
there is no one clean solution for this and most of the ones I have 
looked at are no more than ingenious kludges to get HTTP to do something 
it isn't used to doing. A lot of them already use HTTP asynchronously, 
thus moving away from the traditional usage model. Even then, most of 
them are there to service server-to-server transactions or web mashups 
etc. and don't really address the requirements for distributed control 
entities e.g. sensors and actuators (to use abstract terms), especially 
those built on constrained embedded systems.

We seem to be at a fork in the road now with the two paths of:

   1. Basing CoAP on the HTTP transaction model
   2. Basing CoAP on a more typical M2M transaction model

The advantage of using (1) would be an easier job at a gateway node. The 
clear disadvantage of (1) is that it doesn't map well to the threading 
models typically used in embedded systems (see my earlier post). It 
could be made to map but there will inevitably have to be some 
additional specification over the underlying communication to fit 
embedded device models. This will then become in effect yet another 
RestMS/PubSubHubbub/Webhooks/RMS (see Vlad Trifa's post).

The advantage of (2) is that it gives an opportunity to model 
transactions more closely to those typical to an embedded environment. 
There is nothing to prevent this model extending into the web generally 
using translations at a gateway or indeed building wider CoAP systems in 
the internet which can handle the asynchronous multi-threaded 
transaction models natively.

In a nutshell, using (1) is propagating the status quo, which is by no 
means a bad thing, but I am not sure if it is appropriate for CORE. (2) 
is acknowledging the unique properties of constrained and embedded 
environments and building a transaction model more appropriate to such 
devices.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com <http://www.gridmerge.com/>

On 03/06/2010 3:31 AM, Richard Kelsey wrote:
>> From: Paul Duffy<[email-masked]>
>>

---

From: "Simpson, Robby (GE Energy Services)" <[email-masked]>
Date: Thu, 3 Jun 2010 16:56:52 -0400

_IF_ HTTP mapping is a priority, then I believe defining new methods for
SUBSCRIBE and/or NOTIFY is problematic.

As many have already pointed out, there are a plethora of
Subscribe/Notify mechanisms built on top of HTTP, often with differing
design goals.  Should CoAp define its own SUBSCRIBE and/or NOTIFY
methods, then painstaking mappings of the plethora for HTTP will need to
be made -- something that is going to be painful, problematic, costly at
translation points, and (IMO) somewhat of a layer violation.

On the other hand, if CoAp sticks to the HTTP methods, then it should
natively be able to support the plethora of HTTP mechanisms, and will
allow for differing design goals without having to pick a single rigid
mechanism.  For instance, should there be a single notification resource
vs a notification method, vs ...

- Robby

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stuber, Michael
Sent: Thursday, June 03, 2010 12:42 PM
To: [email-masked]
Subject: Re: [core] Subscribe/Notify for CoAP

CoAp specific.  My point is that a single CoAp specific method could be
mapped to wide variety of HTTP mechanisms if desired.  I don't think
there is any need for yet another HTTP sub/notify mechanism, and it
certainly isn't in our charter to define one.

-----Original Message-----

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: "Stuber, Michael" <[email-masked]>
Date: Thu, 3 Jun 2010 14:00:17 -0700

I think you've captured it well, though my hope is that the transaction
models aren't actually that far apart.  Clearly I favor approach #2.  I
don't believe we need HTTP for embedded.  If folks want HTTP for
embedded devices, run HTTP, and tune it as much as you reasonable can.
I believe we need a protocol that addresses the unique needs of the
embedded/constrained space as a primary goal.  Mapping to HTTP is
necessary and desired, as it allows these devices to easily tie into the
larger internet, but it is reasonable to expect that the device that
bridges the gap should have the resources to facilitate the conversion.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robert Cragie
Sent: Thursday, June 03, 2010 12:59 PM
To: [email-masked]
Subject: Re: [core] Subscribe/Notify for CoAP

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

	Date: Wed, 02 Jun 2010 20:17:17 -0400
	From: Paul Duffy <[email-masked]> <mailto:[email-masked]> 
	 
	My understanding is that COAP is directed to the WEB of things.
I take 
	that to mean going with the grain of pervasively  deployed WEB 
	infrastructure.  Unless there is an overwhelming compelling
reason to do 
	otherwise, IMO COAP needs to implement a strict subset of HTTP 
	semantics.  Otherwise, we open the door to complexity re:
translating 
	HTTP/COAP, and history has shown complex app gateways will
always be a 
	challenge.
	 
	There are several ways to support pub/sub using stock HTTP
methods.  I 
	suggest we do so.

---

From: Paul Duffy <[email-masked]>
Date: Thu, 03 Jun 2010 18:48:35 -0400

We seem to be at a fork in the road now with the two paths of:
> The advantage of using (1) would be an easier job at a gateway node. 
> The clear disadvantage of (1) is that it doesn't map well to the 
> threading models typically used in embedded systems (see my earlier 
> post). It could be made to map but there will inevitably have to be 
> some additional specification over the underlying communication to fit 
> There is nothing to prevent this model extending into the web 
> generally using translations at a gateway or indeed building wider 
> CoAP systems in the internet which can handle the asynchronous 
> multi-threaded transaction models natively.
>
> means a bad thing, 

Which is my main issue.

1. HTTP semantics are not a perfect fit, but IMO (like it or not) the 
WEB of things needs to align with those semantics (warts and all).  Its 
a close enough, good enough fit.

2. Subscriptions are resources.  They are created, have a lifetime, can 
be enumerated, and are destroyed.  From coap-2 "servers keep track of 
subscriptions...", "a subscription SHOULD be removed...", etc.  
Subscriptions are resources.

Example. I use SUBSCRIBE to create a subscription.  Would I subsequently 
do GET to enumerate?  DELETE to remove?  PUT to modify?  SUBSCRIBE 
method seems a RESTfully twisted special case of POST.

Cheers

> but I am not sure if it is appropriate for CORE. (2) is acknowledging 
> the unique properties of constrained and embedded environments and 
> building a transaction model more appropriate to such devices.
>
> Robert
>

---

From: Vlad Trifa <[email-masked]>
Date: Fri, 4 Jun 2010 09:42:16 +0300

verbs, etc that would not be directly part of http (thus making the  
mapping between coap-http more complex).

Please let me know your thoughts/comments/questions, thx!

Vlad

---
vlad m. trifa - institute for pervasive computing
swiss federal institute of technology, eth zurich
phone: +41 44 632 08 62 -- web: www.vladtrifa.com

On Jun 4, 2010, at 12:00 AM, Stuber, Michael wrote:

> I think you’ve captured it well, though my hope is that the  
> transaction models aren’t actually that far apart.  Clearly I favor  
> approach #2.  I don’t believe we need HTTP for embedded.  If folks  
> want HTTP for embedded devices, run HTTP, and tune it as much as you  
> reasonable can.  I believe we need a protocol that addresses the  
> unique needs of the embedded/constrained space as a primary goal.   
> Mapping to HTTP is necessary and desired, as it allows these devices  
> to easily tie into the larger internet, but it is reasonable to  
> expect that the device that bridges the gap should have the  
> resources to facilitate the conversion.
>
> From: [email-masked] [mailto:[email-masked]] On Behalf  
> Of Robert Cragie
> HTTP was designed to work on a synchronous client/server model.  
> Whilst that may suit desktop PC's running browsers and servers  
> running httpd, it is not entirely appropriate for M2M. The plethora  
> of schemes to implement push processing for HTTP (all incompatible)  
> goes to show that there is no one clean solution for this and most  
> of the ones I have looked at are no more than ingenious kludges to  
> get HTTP to do something it isn't used to doing. A lot of them  
> already use HTTP asynchronously, thus moving away from the  
> traditional usage model. Even then, most of them are there to  
> service server-to-server transactions or web mashups etc. and don't  
> really address the requirements for distributed control entities  
> e.g. sensors and actuators (to use abstract terms), especially those  
> built on constrained embedded systems.
>
> Basing CoAP on the HTTP transaction model
> Basing CoAP on a more typical M2M transaction model
> some additional specification over the underlying communication to  
> fit embedded device models. This will then become in effect yet  
> another RestMS/PubSubHubbub/Webhooks/RMS (see Vlad Trifa's post).
>
> transactions more closely to those typical to an embedded  
> environment. There is nothing to prevent this model extending into  
> the web generally using translations at a gateway or indeed building  
> wider CoAP systems in the internet which can handle the asynchronous  
> In a nutshell, using (1) is propagating the status quo, which is by  
> no means a bad thing, but I am not sure if it is appropriate for  
> CORE. (2) is acknowledging the unique properties of constrained and  
> embedded environments and building a transaction model more  
> appropriate to such devices.
>
> Robert

---

From: Robert Cragie <[email-masked]>
Date: Fri, 04 Jun 2010 11:55:40 +0100

Hi Paul,

I'm not overly fond of SUBSCRIBE as a method either, to be honest. I 
think to be truly RESTful, there are two approaches to subscription:

   1. Don't separate it from the resource and use synchronous
      request/response with long polling. The subscription is effected
      by a blocking wait on the resource which gets responded to when it
      has been updated.
   2. Have an explicit separate subscription resource where a notify
      resource is registered and to where notifications are sent

(1) is more elegant in some respects because in (2) there is a logical 
separation from the subscription and the resource itself. In (1), the 
subscription is effectively dynamic, i.e. the server has to keep tags on 
the client requests and respond to all requests as appropriate. There 
are then variations with respect to the delivery mechanism, e.g. update 
only (queue in client potentially), queue in server, streaming 
(multipart delivery).

If you consider the transaction models, I still think there is a benefit 
for adding the notify message type to request/response, i.e. an 
asynchronous message which is not paired with any other message, 
although I accept it is not strictly necessary. This has benefits for 
streaming models etc. With regard to the actual methods, I think we 
should stick to the CRUD methods used in RESTful architectures.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 03/06/2010 11:48 PM, Paul Duffy wrote:
>> no means a bad thing, 
> WEB of things needs to align with those semantics (warts and all).  
> Its a close enough, good enough fit.
>
> 2. Subscriptions are resources.  They are created, have a lifetime, 
> can be enumerated, and are destroyed.  From coap-2 "servers keep track 
> of subscriptions...", "a subscription SHOULD be removed...", etc.  
> Example. I use SUBSCRIBE to create a subscription.  Would I 
> subsequently do GET to enumerate?  DELETE to remove?  PUT to modify?  
> SUBSCRIBE method seems a RESTfully twisted special case of POST.
>
> Cheers
>
>

---

From: Zach Shelby <[email-masked]>
Date: Fri, 4 Jun 2010 15:59:05 +0300

On May 29, 2010, at 12:21 AM, Brian Frank wrote:

> My two cents: 
> 
> Personally I find it confusing to have both a message type *and* a method.
> 
> Do we really need both?  It seems we just combine the two into a single method byte.  Maybe reserve a bit to say a message is a response to a GET, PUT, DELETE, etc.

Interesting way of looking at things. Maybe we are making this too complex with having both messages and methods. Instead we could think of this simply as sending Methods and receiving a Response. That would save a couple bits (and parsing) from the header too. In the end, does HTTP even have messages types at all? In practice an HTTP client is just sending a method and receiving a response code. 

Another good concept we discussed off-line with Guido Moritz was whether we should think of the CoAP message as being synchronous at all. Already we have determined that talking about CoAP in terms of clients and servers doesn't work (coap-01 tries to avoid that terminology). Instead we just talk about peer CoAP end-points, which seems to work.

As we are working with UDP the message model can be thought of as being just asyncronous, when the A bit is not set then no response will come. If the A bit is set a response should come, but even with a large delay and we may need to retransmit. So the A bit achieves the same as the HTTP req/res model, but we could think of it as two asynchronous CoAP messages. 

Does that make sense to people? 

Zach

> 
> 
> 
> On Fri, May 28, 2010 at 1:22 PM, Robert Cragie <[email-masked]> wrote:
> I think sometimes it makes more sense to think about threads of execution.
> 
> Forgive me for this lengthy preamble but it will hopefully put things into context.
> 
> In the most abstract sense, processing is governed by a thread of execution, which sequences a series of data transformations to expedite the required processing. If a data transformation can be completed synchronously in the thread of execution, then the thread is conceptually easier to understand and follow. Most threading models assume this to be the case and if the data transformation cannot complete, it usually blocks pending the required event to complete the transformation. During blocking, the thread is suspended. In simple CPU models without any sort of scheduler, there are two threads of execution: A main thread, pre-emptable by an interrupt thread, usually not pre-emptable. In the main thread, sub-threads are emulated; data transformations can be simply function calls which don't block and therefore return effectively immediately and synchronously. Blocking data transformations are emulated by storing state relevant to each sub-thread then marshaling each event as it is received e.g. through interrupt handling, which causes the second thread to run and thus allows changing sub-thread state so when the main thread runs, the blocking data transformation can complete. Operating system schedulers for these simple CPUs simply abstract this operation through a kernel and associated task/thread scheduling calls. Continuations are a simpler form used in memory-constrained implementations.
> 
> Why the lengthy pre-amble? However you look at it, what essentially is required for any threading model (using kernel/scheduler, continuations, emulated, whatever) are fundamentally three primitives:
> 	• Request
> 	• Response
> 	• Notify
> A thread of execution will call request and will typically (though not necessarily - see emulated blocking/continuations) wait for a response. If the thread blocks, it is typically woken by another worker thread handling a notify. The worker thread handles notifies asynchronously and buffers and/or signals the associated task accordingly.
> 
> This is why I think the current foundation level of messages in coap-01 is right.
> 
> On top of this, the payload of the messages can reflect the actual method. Personally, I don't see the need for a specific SUBSCRIBE message; a POST/create to a subscription resource seems adequate to me. The notify message can carry a PUT or POST depending on whether the resource was simply updated or appended to (again it is no accident the data types in JSON are as they are).
> 
> Robert 
> On 28/05/2010 2:13 PM, Angelo P. Castellani wrote:
>> In my opinion Subscribe/Notify are special methods of interaction
>> between resources.
>> 
>> 1) SUBSCRIBE: Any resource A can send a Request to SUBSCRIBE with a
>> resource B (to the resource B URI).
>> 
>> When B receives the request, B can (should/must?) answer with a
>> Response to the SUBSCRIBE Request, telling the result of the request
>> (subscription accepted/denied/unsupported?).
>> 
>> 2) NOTIFY: When subscription condition fires the resource B sends a
>> NOTIFY Request to resource A URI.
>> 
>> When A receives the request, A can (should/must?) answer with a
>> Response to the NOTIFY Request, telling the result of the request (OK,
>> cancel subscription, change notify options?).
>> 
>> In each Request must be specified the URI of the resource doing the
>> Request too (Option? From-URI?).
>> 
>> Angelo
>> 
>> On Fri, May 28, 2010 at 14:50, Zach Shelby 
>> <[email-masked]>
>>  wrote:
>>   
>> 
>>> Hi,
>>> 
>>> This is a really good conversation. One thing we need to do is remember what our minimum requirements are for subscribe/notify and not try to solve something more than we should. From what I know it is sufficient to be able to receive notifications when a URI changes or periodically. You might consider new URIs under this URI path to be changes to a URI though...
>>> 
>>>> with this flavor, the SUBSCRIBE may be replaced by a simple POST. So no needs to have an explicit SUBSCRIBE method.
>>>>       
>>>> 
>>>> If we want support a more oriented peer-to-peer transaction on CoAP, it looks to me both SUB and NOTIFY should be treated as messages.
>>>>       
>>>> 
>>> The Request/Response model can be used peer-to-peer, and in CoAP you can even use a Request asynchronously. Additionally, we want a native RESTful subscribe/notify technique, that is, we want to subscribe to resources and be susequently notified about those resources when they change.
>>> 
>>> In that sense, you can think of a subscription as a request to receive asynchronous notifications about a resource (about a URI). This can be achieved by:
>>> 
>>> 1.  as a SUBSCRIBE Request on the URI with some option indicating the lifetime as in coap-01,
>>> 3.  or as a POST Request on the URI with options indicating that this is actually a subscription and the lifetime.  This bends the meaning of POST quite a bit and might be prone to mistakes?
>>> 
>>> The asynchronous response is a harder one. Can we bend the meaning of a Request for making asynchronous notifications? Also a notification includes a URI about a resource on the requestor, which is inverse from normal Requests in REST. So the options here are:
>>> 
>>> I wonder what the HTTP designers would have done if this would have been a requirement back then? Maybe we should ask them...
>>> 
>>> Zach
>>> 
>>>     
>>> 
>>>> Adriano
>>>> 
>>>> From: 
>>>> [email-masked] [mailto:[email-masked]
>>>> ]
>>>> Cc: core; 
>>>> [email-masked]; [email-masked]
>>>> 
>>>>> So strictly speaking, both NOTIFY and SUBSCRIBE are message types not  methods!
>>>>>         
>>>>> 
>>>> SUBSCRIBE can be just an asynchronous GET on update then I think it is a method and NOTIFY is an asynchronous response so a message.
>>>> But if we want to have selective notifications when a resource is created, updated or deleted then I think you're right NOTIFY and SUBSCRIBE are messages.
>>>> 
>>>> Does that make sense ?
>>>> 
>>>> Matthieu
>>>> 
>>>> core 
>>>> <[email-masked]>
>>>> I understand your point and personally agree on M2M is quite different from web page model. On the architectural RESTful style, the method information tells the server what to do with data kept in the URI information.
>>>> 
>>>> So strictly speaking, both NOTIFY and SUBSCRIBE are message types not  methods!
>>>> 
>>>> Adriano
>>>> 
>>>> From: Robert Cragie [
>>>> mailto:[email-masked]
>>>> ]
>>>> At the lowest (foundation) level, there are the transaction messages as described below. This provides a flexible mechanism for the application with regard to synchronicity and threading. This is important for the types of devices CoAP is being aimed at.
>>>> 
>>>> Above that, the methods can be used according to the architectural style. So in this case, it is RESTful (COnstrained Restful Environments), which will naturally limit the number of methods and how transactions occur.
>>>> 
>>>> The actual architecture using a combination of the methods and messages also depends on what is required at the application layer. Consider a typical client which wants to subscribe to a resource. That client controls the feed of data but needs a component which is capable of handling (possibly buffering) the data it receives through notifications. Is this a separate server? Or would we want to consider it part of an enhanced client model which is able to process feeds of data? These are the sort of models which have led to the myriad of solutions (GENA, Webhooks, long polling, pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially ingenious ways of getting around the limitations imposed by HTTP and how it is processed for anything which deviates from the classic web page access model.
>>>> 
>>>> I think the aim of CoAP should be clean from the word go with regard to supporting these more peer-to-peer transactions, where the client can exist on either entity and both entities can feed data to each other; typical in M2M applications.
>>>> 
>>>> Robert
>>>> 
>>>> in my personal opinion, the option 1a) brings some sort of ambiguity to CoAP specs.
>>>> 
>>>> My be my understatement of new CoAP specs is not so deep, but now we have 5 methods and 3 message types: request, response and notify. Which methods are allowed with which messages types?
>>>> I suppose you have to use PUT/POST method with notify message for asynch data notification. How to make a subscribe? I suppose you would use a SUBSCRIBE method with request/response message or SUBSCRIBE with notify message? Also what about POST/DELETE methods in a notify message? They not make any sense..
>>>> 
>>>> I think the choice is between: option 1) -> only CRUD methods and option 1b) -> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both solutions.
>>>> 
>>>> Adriano
>>>> 
>>>> From: Robert Cragie [
>>>> mailto:[email-masked]
>>>> ]
>>>> I would also prefer to keep the protocol in CoAP asynchronous. You can always map an asynchronous protocol to a synchronous one but, as we see in HTTP, it always ends up as a kludge to do it the other way round. The efforts which have been gone to to make HTTP quasi-asynchronous via all the schemes mentioned below and many more besides (all non-interoperable of course) is testament to how important this is for M2M communication.
>>>> 
>>>> 1. request/response can be asynchronous or synchronous messages (as there is a transaction ID in there)
>>>> I think it makes sense to add a pub/sub model as a useful mechanism for M2M.
>>>> 
>>>> So, looking at it the other way round: It will be entirely possible to translate whatever is currently built on HTTP to CoAP based on the above, with all its restrictions regarding synchronous and client/server transactions. What may be harder is to translate directly is a CoAP-based application to HTTP. So I guess the question is: Do we want to be hamstrung to synchronous client/server transactions as dictated by HTTP and provide a direct mapping to HTTP, then have to come up with similar kludges for asynchronous peer-to-peer transactions as has been done in numerous ways for HTTP, or do we want to define the protocol cleanly to start with and accept that some sort of transaction relaying/conversion would have to take place at a mapping node?
>>>> 
>>>> Robert
>>>> it looks to me that CoAP should use an explicit sub/notify mechanism since this is the core of the machine-to-machine interaction model.
>>>> HTTP suffers of this lack and we have seen a plethora of solutions to give an asynch taste to it. Webhooks and websockets are only the lasts of the list.
>>>> As someone has already pointed out on this list, it is theoretically possible to describe sub/notify using only CRUD methods but it looks a little bit tricky and verbose.
>>>> 
>>>> Now we have a chance to build from scratch a new protocol with and I think using explicit sub/notify methods with a clear and well defined semantic is the best option. It is easily understanding from every developer and will prevent to build other fanny solutions on top of the CoAP. HTTP does not have this well defined semantic and (for hundreds of other reasons also) it is not used as wide protocol for machine-to-machine communication.
>>>> 
>>>> CoAP - as binary protocol - and with an explicit asynch model has a chance to be a really wide protocol for M2M communication not only for constrained environments.
>>>> 
>>>> my 2 cents
>>>> 
>>>> - adriano
>>>> 
>>>> From: 
>>>> [email-masked] [mailto:[email-masked]
>>>> ] On Behalf Of Paul Duffy (paduffy)
>>>> It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0 work, so that it is as easy as possible for ZigBee SE to use CoRE when ready. That suggests to me that we should align with their subscribe/notify process.
>>>> 
>>>> 
>>>> I am not sure I understand that. I mean, ZigBee SE2.0 is defining an application specific subscribe/notify mechanism for that purpose so far for HTTP. This uses standard HTTP methods and some custom payload and REST interfaces. CoAP Req/Res is already totally compatible with SE2.0 in that respect, so alignment is already OK there. Nothing stopping someone from using SE2.0 over CoAP.
>>>> 
>>>> Specifying a native susbcription/notify into CoAP is another matter. We can't adopt a solution specific to one application as that won't solve the problems of other applications nor general HTTP mapping at all (probably would make it worse). It seems that for the near future there will be a bunch of HTTP push mechanisms in use without any clear standard appearing - or am I wrong there?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> From: 
>>>> [email-masked] [mailto:[email-masked]
>>>> ] On Behalf Of Paul Duffy
>>>> Sent: 25 May 2010 03:48
>>>> To: Zach Shelby
>>>> Cc: core
>>>> We have two different paths with regard to a subscribe/notify mechanism for CoAP:
>>>> 
>>>> 1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really does not include this concept.
>>>> 1a) Notify as a message and SUBSCRIBE as a method. This is currently used in coap-01.
>>>> 1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a good list discussion about this leading to a. In practice it doesn't make a big difference if notification is a message or method.
>>>> 
>>>> 2. Use an HTTP specific framework such as Webhooks, the ZigBee SE2.0 proposal or GENA.
>>>> 
>>>> So far we have focused on 1 in the WG, and every now and again 2 comes up. At least I am not convinced that we need to suffer the drawbacks of HTTP here. Anyways 2 does not help our mapping to HTTP in reality very much as there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may end up anyways translating between multiple HTTP frameworks depending on the application. So instead of doing a CoAP Notify/Subscribe to Webhooks mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA mapping.
>>>> 
>>>> 
>>>> 
>>>> From what I have heard so far 1 still seems like a wise choice, although I need to look at Webhooks more deeply. In reality many applications specify their own way of doing a push interface using REST methods and specific payloads (ZigBee SE2.0 is such an example). That is just fine, and might be used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't prevent the application using its own mechanism, it just provides a native way for doing push.
>>>> 
>>>> What do people think?
>>>> 
>>>> Zach
>>>> 
>>>> On May 17, 2010, at 6:44 PM,
>>>> [email-masked]
>>>>  wrote:
>>>> 
>>>> 
>>>> 
>>>> Hi,
>>>> 
>>>> - If used by CORE it will be easier to map to HTTP because it uses only CRUD verbs.
>>>> - The subscription message is extendable and could support advanced options (delays, increment, ...)
>>>> - No interoperability without well known URIs and a well defined subscription message format (Not sure CoAP draft is the right place to specify this).
>>>> - XML/EXI is too complex to be the required format for the default subscription/notification mechanism.
>>>> - The notification should not require a subsequent GET to retrieve the content.
>>>> "core"
>>>> <[email-masked]>
>>>> From: 
>>>> [email-masked] [mailto:[email-masked]
>>>> ] On Behalf Of
>>>> Angelo P. Castellani
>>>> Sent: 14 May 2010 13:14
>>>> To: Zach Shelby
>>>> Cc: core
>>>> On Fri, May 14, 2010 at 13:06, Zach Shelby
>>>> <[email-masked]>
>>>>  wrote:
>>>> 
>>>> 
>>>> Hi Angelo,
>>>> 
>>>> On Mon, May 10, 2010 at 18:51, Carsten Bormann
>>>> <[email-masked]>
>>>> wrote:
>>>> 
>>>> 
>>>> Onzo is a limited company number 06097997 registered in England& Wales. The
>>>> registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.
>>>> 
>>>> This email message may contain confidential and/or privileged information, and
>>>> is intended solely for the addressee(s). If you have received this email in
>>>> error, please notify Onzo immediately. Unauthorised copying, disclosure or
>>>> Onzo is a limited company number 06097997 registered in England& Wales. The
>>>> registered office is 6 Great Newport Street, London, WC2H 7JB, United Kingdom.
>>>> 
>>>> This email message may contain confidential and/or privileged information, and
>>>> is intended solely for the addressee(s). If you have received this email in
>>>> error, please notify Onzo immediately. Unauthorised copying, disclosure or
>>>> _____________________________________________________________________________________________________________________
>>>> core mailing list
>>>> 
>>>> [email-masked]

---

From: Zach Shelby <[email-masked]>
Date: Fri, 4 Jun 2010 16:26:10 +0300

On Jun 3, 2010, at 10:59 PM, Robert Cragie wrote:

> 	• Basing CoAP on the HTTP transaction model
> 	• Basing CoAP on a more typical M2M transaction model

Here you are referring to the Subscribe/Notify mechanism I suppose? For general REST Req/Res interactions CoAP has a bit of both worlds in that we support HTTP methods for working with resources, but the CoAP messaging is more tuned to M2M (multicast support, retransmission, optional responses).

> The advantage of using (1) would be an easier job at a gateway node. The clear disadvantage of (1) is that it doesn't map well to the threading models typically used in embedded systems (see my earlier post). It could be made to map but there will inevitably have to be some additional specification over the underlying communication to fit embedded device models. This will then become in effect yet another RestMS/PubSubHubbub/Webhooks/RMS (see Vlad Trifa's post).

(1) only maps easier at the proxy if the HTTP subscriber would use that specific CoAP model for Sub/Notify using HTTP methods. Besides, I don't understand the argument about the complexity of a CoAP-HTTP proxy? This is not where our constrained requirements are coming from. The main complexity of a proxy will surely not be in the CoAP Sub/Notify to HTTP mapping, and anyways you would often split (and aggregate) the subscriptions and answer HTTP clients with cached resource representations.

> The advantage of (2) is that it gives an opportunity to model transactions more closely to those typical to an embedded environment. There is nothing to prevent this model extending into the web generally using translations at a gateway or indeed building wider CoAP systems in the internet which can handle the asynchronous multi-threaded transaction models natively.

Agreed, and I also believe (2) will let us do this in the simplest possible manner for constrained devices while giving us real interoperability. 

> 
> In a nutshell, using (1) is propagating the status quo, which is by no means a bad thing, but I am not sure if it is appropriate for CORE. (2) is acknowledging the unique properties of constrained and embedded environments and building a transaction model more appropriate to such devices.

That said, there is not a huge gap between (1) and (2). We are all agreeing that this should be architecturally RESTful and reasonable to map also to HTTP when needed. We do need to acknowledge that REST in a constrained M2M environment is not equal to HTTP, but may need a (tiny bit of) evolution. 

Zach

---

From: Robert Cragie <[email-masked]>
Date: Fri, 04 Jun 2010 14:28:47 +0100

Hi Zach,

At the end of the day, it obviously all comes down transmitting and 
receiving asynchronous packets going between peers. However I think 
there is some use in identifying at least message types to map to a 
suitable transaction model. Beyond that, we should specify methods, as, 
after all, this is CORE (RESTful environments) - the REST architectural 
style does impose rules here.

I actually think client and server are still valid from the point of 
view of execution, i.e. the client initiates the transaction. Just 
thinking about packets flying about between peers doesn't help from the 
point of view of a processing environment particularly, so again is the 
aim to try to provide a pattern here?

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 04/06/2010 1:59 PM, Zach Shelby wrote:
>> On Fri, May 28, 2010 at 1:22 PM, Robert Cragie<[email-masked]>  wrote:

---

From: Brian Frank <[email-masked]>
Date: Fri, 4 Jun 2010 10:56:41 -0400

+1 to get rid of message type versus message method distinction and having
just a single ack/res mechanism

Regarding subscribe issue - I personally think it will be extremely
difficult to design a subscription mechanism that suites everyone and fits
everyone's application layer.  In oBIX for example we have already have a
fairly sophisticated "watch" mechanism with RESTful ways to manage the
subscription with normal GET/PUT/POST.  If we standardize subscription at
the CoAP layer, then we also have to take into account all sorts of other
ugly complications:
  - timeouts/leases
  - permanent versus temporary subscriptions
  - frequency and min/max push times
  - synchronization of push with sleeping devices

A lot of trouble with HTTP push today is that most of the time we are trying
to figure out how to do it without opening a TCP connection to the client,
since most browsers sit behind some firewall and/or NAT.  I would say
server-to-server with public IP addresses that "HTTP push" is just a
POST dictated by the application layer.

But I can definitely see both sides of the issue.

---

From: Guido Moritz <[email-masked]>
Date: Mon, 7 Jun 2010 14:36:04 +0200

With regard to the actual methods, I think we should stick to the CRUD
methods used in RESTful architectures.

But REST means stateless passive resources. Using PUT/POST to create a
subscription resource that is fired/notified if something changes is almost
not REST. So this is a new required functionality specific for M2M scenarios
which needs clear semantically unambiguously methods. As Zach mentioned
there is no state-of-the-art way of doing sub/not/event/. with HTTP. Some
even rely on TCP on transport layer. So from my point of view this is a) a
new required mechanism that implies new method(s) and thus b) an extension
of REST in general and thus legitimate.

Mapping of COAP to HTTP can be performed by a Gateway/Proxy which has
sufficient computing power. As long as design of COAP does not prevent from
mapping of the eventing concept on the existing HTTP methods, from my point
of view introducing the new methods should not be an issue. This in return
will even allow much more complex scenarios. Deployments in general might
require the proxys for data aggregation, data storage, integration in legacy
systems, .

We should also keep in mind that defining the new methods does not imply to
use them in general. There might be implementations/deployments that will
use polling the sensors once a day instead of using the sub/not mechanism.
As long as both endpoints are capable of the sub/not great, otherwise they
can fall back to default CRUD style.

Guido

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Robert Cragie
Gesendet: Freitag, 4. Juni 2010 12:56
An: [email-masked]
Betreff: Re: [core] Subscribe/Notify for CoAP

Hi Paul,

I'm not overly fond of SUBSCRIBE as a method either, to be honest. I think
to be truly RESTful, there are two approaches to subscription:

1.	Don't separate it from the resource and use synchronous
request/response with long polling. The subscription is effected by a
blocking wait on the resource which gets responded to when it has been
updated.
2.	Have an explicit separate subscription resource where a notify
resource is registered and to where notifications are sent

(1) is more elegant in some respects because in (2) there is a logical
separation from the subscription and the resource itself. In (1), the
subscription is effectively dynamic, i.e. the server has to keep tags on the
client requests and respond to all requests as appropriate. There are then
variations with respect to the delivery mechanism, e.g. update only (queue
in client potentially), queue in server, streaming (multipart delivery).

If you consider the transaction models, I still think there is a benefit for
adding the notify message type to request/response, i.e. an asynchronous
message which is not paired with any other message, although I accept it is
not strictly necessary. This has benefits for streaming models etc. With
regard to the actual methods, I think we should stick to the CRUD methods
used in RESTful architectures.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

The advantage of using (1) would be an easier job at a gateway node. The
clear disadvantage of (1) is that it doesn't map well to the threading
models typically used in embedded systems (see my earlier post). It could be
made to map but there will inevitably have to be some additional
specification over the underlying communication to fit embedded device
models. This will then become in effect yet another
RestMS/PubSubHubbub/Webhooks/RMS (see Vlad Trifa's post).

The advantage of (2) is that it gives an opportunity to model transactions
more closely to those typical to an embedded environment. There is nothing
to prevent this model extending into the web generally using translations at
a gateway or indeed building wider CoAP systems in the internet which can
handle the asynchronous multi-threaded transaction models natively.

In a nutshell, using (1) is propagating the status quo, which is by no means
a bad thing, 

Which is my main issue.

1. HTTP semantics are not a perfect fit, but IMO (like it or not) the WEB of
things needs to align with those semantics (warts and all).  Its a close
enough, good enough fit.

2. Subscriptions are resources.  They are created, have a lifetime, can be
enumerated, and are destroyed.  From coap-2 "servers keep track of
subscriptions...", "a subscription SHOULD be removed...", etc.
Subscriptions are resources. 

Example. I use SUBSCRIBE to create a subscription.  Would I subsequently do
GET to enumerate?  DELETE to remove?  PUT to modify?  SUBSCRIBE method seems
a RESTfully twisted special case of POST.

Cheers

but I am not sure if it is appropriate for CORE. (2) is acknowledging the
unique properties of constrained and embedded environments and building a
transaction model more appropriate to such devices.

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

Date: Wed, 02 Jun 2010 20:17:17 -0400
From: Paul Duffy  <mailto:[email-masked]> <[email-masked]>

---

From: Guido Moritz <[email-masked]>
Date: Mon, 7 Jun 2010 14:19:32 +0200

+1 for removing message type and leaving only methods.

You mean messaging pattern between the server and client? Of course, for
interoperability reasons there should be a clear specification which is the
correct response on a request. But when using a datagram transport protocol
like UDP and due to the partly expected high delay between request and
response, messaging is be asynchronous by design. So this might be not be
obviously classical client/server communication but more data sink/data
source (or service provider/service consumer in terms of SOAs). Thus
relationship between request and response is part of the application layer
and not of the transport layer like in traditional HTTP. 

Guido

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Robert Cragie
Gesendet: Freitag, 4. Juni 2010 15:29
An: [email-masked]
Betreff: Re: [core] Subscribe/Notify for CoAP

Hi Zach,

At the end of the day, it obviously all comes down transmitting and
receiving asynchronous packets going between peers. However I think there is
some use in identifying at least message types to map to a suitable
transaction model. Beyond that, we should specify methods, as, after all,
this is CORE (RESTful environments) - the REST architectural style does
impose rules here.

I actually think client and server are still valid from the point of view of
execution, i.e. the client initiates the transaction. Just thinking about
packets flying about between peers doesn't help from the point of view of a
processing environment particularly, so again is the aim to try to provide a
pattern here?

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

My two cents: 

Do we really need both?  It seems we just combine the two into a single
method byte.  Maybe reserve a bit to say a message is a response to a GET,
PUT, DELETE, etc.

Interesting way of looking at things. Maybe we are making this too complex
with having both messages and methods. Instead we could think of this simply
as sending Methods and receiving a Response. That would save a couple bits
(and parsing) from the header too. In the end, does HTTP even have messages
types at all? In practice an HTTP client is just sending a method and
receiving a response code. 
 
Another good concept we discussed off-line with Guido Moritz was whether we
should think of the CoAP message as being synchronous at all. Already we
have determined that talking about CoAP in terms of clients and servers
doesn't work (coap-01 tries to avoid that terminology). Instead we just talk
about peer CoAP end-points, which seems to work.
 
As we are working with UDP the message model can be thought of as being just
asyncronous, when the A bit is not set then no response will come. If the A
bit is set a response should come, but even with a large delay and we may
need to retransmit. So the A bit achieves the same as the HTTP req/res
model, but we could think of it as two asynchronous CoAP messages. 

Zach

On Fri, May 28, 2010 at 1:22 PM, Robert Cragie
<mailto:[email-masked]> <[email-masked]> wrote:
I think sometimes it makes more sense to think about threads of execution.
 
Forgive me for this lengthy preamble but it will hopefully put things into
context.
 
In the most abstract sense, processing is governed by a thread of execution,
which sequences a series of data transformations to expedite the required
processing. If a data transformation can be completed synchronously in the
thread of execution, then the thread is conceptually easier to understand
and follow. Most threading models assume this to be the case and if the data
transformation cannot complete, it usually blocks pending the required event
to complete the transformation. During blocking, the thread is suspended. In
simple CPU models without any sort of scheduler, there are two threads of
execution: A main thread, pre-emptable by an interrupt thread, usually not
pre-emptable. In the main thread, sub-threads are emulated; data
transformations can be simply function calls which don't block and therefore
return effectively immediately and synchronously. Blocking data
transformations are emulated by storing state relevant to each sub-thread
then marshaling each event as
 it is received e.g. through interrupt handling, which causes the second
thread to run and thus allows changing sub-thread state so when the main
thread runs, the blocking data transformation can complete. Operating system
schedulers for these simple CPUs simply abstract this operation through a
kernel and associated task/thread scheduling calls. Continuations are a
simpler form used in memory-constrained implementations.
 
Why the lengthy pre-amble? However you look at it, what essentially is
required for any threading model (using kernel/scheduler, continuations,
emulated, whatever) are fundamentally three primitives:
 • Request
 • Response
 • Notify
A thread of execution will call request and will typically (though not
necessarily - see emulated blocking/continuations) wait for a response. If
the thread blocks, it is typically woken by another worker thread handling a
notify. The worker thread handles notifies asynchronously and buffers and/or
signals the associated task accordingly.
 
This is why I think the current foundation level of messages in coap-01 is
right.
 
On top of this, the payload of the messages can reflect the actual method.
Personally, I don't see the need for a specific SUBSCRIBE message; a
POST/create to a subscription resource seems adequate to me. The notify
message can carry a PUT or POST depending on whether the resource was simply
updated or appended to (again it is no accident the data types in JSON are
as they are).
 
Robert 
 
Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com

 

 

Angelo
 
On Fri, May 28, 2010 at 14:50, Zach Shelby 
 <mailto:[email-masked]> <[email-masked]>
 wrote:

Hi,
 
This is a really good conversation. One thing we need to do is remember what
our minimum requirements are for subscribe/notify and not try to solve
something more than we should. From what I know it is sufficient to be able
to receive notifications when a URI changes or periodically. You might
consider new URIs under this URI path to be changes to a URI though...

 

Hello,

 

          

The Request/Response model can be used peer-to-peer, and in CoAP you can
even use a Request asynchronously. Additionally, we want a native RESTful
subscribe/notify technique, that is, we want to subscribe to resources and
be susequently notified about those resources when they change.

lifetime as in coap-01,
 
The asynchronous response is a harder one. Can we bend the meaning of a
Request for making asynchronous notifications? Also a notification includes
a URI about a resource on the requestor, which is inverse from normal
Requests in REST. So the options here are:

 
Zach

Adriano
 
From: 
[mailto:[email-masked]

 

            

SUBSCRIBE can be just an asynchronous GET on update then I think it is a
method and NOTIFY is an asynchronous response so a message.
But if we want to have selective notifications when a resource is created,
updated or deleted then I think you're right NOTIFY and SUBSCRIBE are
messages.
 
Does that make sense ?
 
Matthieu
 
"Adriano Pezzuto (apezzuto)" 
 <mailto:[email-masked]> <[email-masked]>

"Adriano Pezzuto (apezzuto)" 
 <mailto:[email-masked]> <[email-masked]>
 
Envoyé par : 
[email-masked]
 
28/05/2010 12:50
 
A
 
 <mailto:[email-masked]> <[email-masked]>
 
cc
core 
 <mailto:[email-masked]> <[email-masked]>
 
Objet
 
Hi Roberto,
I understand your point and personally agree on M2M is quite different from
web page model. On the architectural RESTful style, the method information
tells the server what to do with data kept in the URI information.

Adriano
 
From: Robert Cragie [

At the lowest (foundation) level, there are the transaction messages as
described below. This provides a flexible mechanism for the application with
regard to synchronicity and threading. This is important for the types of
devices CoAP is being aimed at.
 
Above that, the methods can be used according to the architectural style. So
in this case, it is RESTful (COnstrained Restful Environments), which will
naturally limit the number of methods and how transactions occur.
 
The actual architecture using a combination of the methods and messages also
depends on what is required at the application layer. Consider a typical
client which wants to subscribe to a resource. That client controls the feed
of data but needs a component which is capable of handling (possibly
buffering) the data it receives through notifications. Is this a separate
server? Or would we want to consider it part of an enhanced client model
which is able to process feeds of data? These are the sort of models which
have led to the myriad of solutions (GENA, Webhooks, long polling,
pubsubhubbub, RESTMS etc.) based around HTTP which are all essentially
ingenious ways of getting around the limitations imposed by HTTP and how it
is processed for anything which deviates from the classic web page access
model.
 
I think the aim of CoAP should be clean from the word go with regard to
supporting these more peer-to-peer transactions, where the client can exist
on either entity and both entities can feed data to each other; typical in
M2M applications.
 
Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
 
http://www.gridmerge.com

in my personal opinion, the option 1a) brings some sort of ambiguity to CoAP
specs.
 
My be my understatement of new CoAP specs is not so deep, but now we have 5
methods and 3 message types: request, response and notify. Which methods are
allowed with which messages types?
I suppose you have to use PUT/POST method with notify message for asynch
data notification. How to make a subscribe? I suppose you would use a
SUBSCRIBE method with request/response message or SUBSCRIBE with notify
message? Also what about POST/DELETE methods in a notify message? They not
make any sense..
 
I think the choice is between: option 1) -> only CRUD methods and option 1b)
-> CRUD + SUB/NOTIFY methods, keeping in mind cost/benefits of both
solutions.
 
Adriano
 
From: Robert Cragie [
 
Hi Adrian,
 
I would also prefer to keep the protocol in CoAP asynchronous. You can
always map an asynchronous protocol to a synchronous one but, as we see in
HTTP, it always ends up as a kludge to do it the other way round. The
efforts which have been gone to to make HTTP quasi-asynchronous via all the
schemes mentioned below and many more besides (all non-interoperable of
course) is testament to how important this is for M2M communication.

 
1. request/response can be asynchronous or synchronous messages (as there is
a transaction ID in there)
2. notify is an asynchronous message
Derived methods:

So, looking at it the other way round: It will be entirely possible to
translate whatever is currently built on HTTP to CoAP based on the above,
with all its restrictions regarding synchronous and client/server
transactions. What may be harder is to translate directly is a CoAP-based
application to HTTP. So I guess the question is: Do we want to be hamstrung
to synchronous client/server transactions as dictated by HTTP and provide a
direct mapping to HTTP, then have to come up with similar kludges for
asynchronous peer-to-peer transactions as has been done in numerous ways for
HTTP, or do we want to define the protocol cleanly to start with and accept
that some sort of transaction relaying/conversion would have to take place
at a mapping node?
 
Robert
 
Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
 
http://www.gridmerge.com

On 26/05/2010 7:17 AM, Adriano Pezzuto (apezzuto) wrote:
Hi,
it looks to me that CoAP should use an explicit sub/notify mechanism since
this is the core of the machine-to-machine interaction model.
HTTP suffers of this lack and we have seen a plethora of solutions to give
an asynch taste to it. Webhooks and websockets are only the lasts of the
list.
As someone has already pointed out on this list, it is theoretically
possible to describe sub/notify using only CRUD methods but it looks a
little bit tricky and verbose.
 
Now we have a chance to build from scratch a new protocol with and I think
using explicit sub/notify methods with a clear and well defined semantic is
the best option. It is easily understanding from every developer and will
prevent to build other fanny solutions on top of the CoAP. HTTP does not
have this well defined semantic and (for hundreds of other reasons also) it
is not used as wide protocol for machine-to-machine communication.
 
CoAP - as binary protocol - and with an explicit asynch model has a chance
to be a really wide protocol for M2M communication not only for constrained
environments.
 
my 2 cents
 
- adriano
 
-----Original Message-----
From: 

Hi,

Hi folks
 
It occurs to me that CoRE should be keeping a close eye on ZigBee SE2.0
work, so that it is as easy as possible for ZigBee SE to use CoRE when
ready. That suggests to me that we should align with their subscribe/notify
process.

application specific subscribe/notify mechanism for that purpose so far for
using SE2.0 over CoAP.
 
Specifying a native susbcription/notify into CoAP is another matter. We
can't adopt a solution specific to one application as that won't solve the
problems of other applications nor general HTTP mapping at all (probably
would make it worse). It seems that for the near future there will be a
bunch of HTTP push mechanisms in use without any clear standard appearing -
or am I wrong there?

 

Zach

Regards - Charles

-----Original Message-----
From: 

 
(thread renamed)
 
We have two different paths with regard to a subscribe/notify mechanism for
CoAP:
 
1. Use specific Subscription and Notify mechanisms for CoAP as HTTP really
does not include this concept.
1a) Notify as a message and SUBSCRIBE as a method. This is currently used in
coap-01.
1b) NOTIFY and SUBSCRIBE as methods. This was used in coap-00, but we had a
good list discussion about this leading to a. In practice it doesn't make a
big difference if notification is a message or method.

So far we have focused on 1 in the WG, and every now and again 2 comes up.
At least I am not convinced that we need to suffer the drawbacks of HTTP
here. Anyways 2 does not help our mapping to HTTP in reality very much as
there is no standard way of doing this over HTTP. Thus a CoAP-HTTP proxy may
end up anyways translating between multiple HTTP frameworks depending on the
application. So instead of doing a CoAP Notify/Subscribe to Webhooks
mapping, you will could end up having to do a CoAP Webhooks to HTTP GENA
mapping.

 
>From what I have heard so far 1 still seems like a wise choice, although I
need to look at Webhooks more deeply. In reality many applications specify
their own way of doing a push interface using REST methods and specific
payloads (ZigBee SE2.0 is such an example). That is just fine, and might be
used instead of a specific CoAP notify/subscribe in that case. So 1 doesn't
prevent the application using its own mechanism, it just provides a native
way for doing push.
 
What do people think?
 
Zach

 
Hi,

Pros:
- Derived from the webhooks concept
- If used by CORE it will be easier to map to HTTP because it uses only CRUD
verbs.
- The subscription message is extendable and could support advanced options
(delays, increment, ...)
- Only one listening port whatever the transport binding is.
 
Cons:
specify this).
 
Hope this could help,
Matthieu

"Charles Palmer"
 <mailto:[email-masked]> <[email-masked]>

"Charles Palmer"
 <mailto:[email-masked]> <[email-masked]>
 
Envoyé par : 
[email-masked]
 
15/05/2010 14:06
 
A
"core"
 <mailto:[email-masked]> <[email-masked]>
 
cc
Objet
 
Dear all

 
licationProfile.aspx

 
 
Regards - Charles Palmer
 
-----Original Message-----
From: 
 
Zach,

 

 
 
Best,
Angelo
 
On Fri, May 14, 2010 at 13:06, Zach Shelby
 <mailto:[email-masked]> <[email-masked]>
 wrote:

Hi Angelo,

 
Dear C. Bormann, all,

still

current

 

http://www.ietf.org/mail-archive/web/core/current/msg00133.html
 (this
impacts the scalability of the web service model too)

 

 
 
Example:

 

Thanks,
Zach

Best regards,
 
Angelo P. Castellani

On Mon, May 10, 2010 at 18:51, Carsten Bormann
 <mailto:[email-masked]> <[email-masked]>
wrote:

April:

 
...

 
 
for the announcement and

for the draft itself.

document?

Gruesse, Carsten

[email-masked]

 
 
[email-masked]

 
http://zachshelby.org - My blog "On the Internet of Things
 <http://6lowpan.net-Mybook> "
http://6lowpan.net - My book  <http://6lowpan.net-Mybook> "
6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

 
 
[email-masked]

This email message may contain confidential and/or privileged information,
and

[email-masked]

 
[email-masked]

 
 
[email-masked]

This email message may contain confidential and/or privileged information,
and

 
 
[email-masked]

[email-masked]

 
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
____________________________________________________________________________
_________________________________________
core mailing list
 
[email-masked]

[email-masked]

 
http://zachshelby.org  - My blog "On the Internet of Things
 <http://6lowpan.net-Mybook> "
http://6lowpan.net - My book  <http://6lowpan.net-Mybook> "
6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

[email-masked]

 
[email-masked]

---

From: Guido Moritz <[email-masked]>
Date: Mon, 7 Jun 2010 22:52:27 +0200

> It is quite plausible under REST that PUT/POST could be used to create
> an active subscription on a node which would then be assigned its own
> URI at which to access it (similar to the Atom feed protocol).  
Right, the creation of this subscription resource might possible using RESTful CRUD. But in origin REST design, the resource must be requested/invoked by the client. But the required behavior for sub/not means an active resource, sending out events on state changes instead of request/response. I think this fits not into origin RESTful design principles!?

Guido

> Von: Karl Ostendorf [mailto:[email-masked]]
> Gesendet: Montag, 7. Juni 2010 18:03
> An: Guido Moritz
> It is quite plausible under REST that PUT/POST could be used to create
> an active subscription on a node which would then be assigned its own
> URI at which to access it (similar to the Atom feed protocol).  As
> long as the node maintains the same representation for all clients and
> not a per-client representation via cookies or other tracking
> mechanism.
> 
> Karl
> 
> On Mon, Jun 7, 2010 at 14:36, Guido Moritz <[email-masked]>
> wrote:
> > not REST.
>  So this is a new required functionality specific for M2M scenarios
> > there is no state-of-the-art way of doing sub/not/event/… with HTTP. Some
> > systems, …
> > Don't separate it from the resource and use synchronous request/response
> > with long polling. The subscription is effected by a blocking wait on the
> > resource which gets responded to when it has been updated.
> > Have an explicit separate subscription resource where a notify resource is
> > registered and to where notifications are sent
> >
> Karl Ostendorf
> http://ostendorf.com/

---

From: Karl Ostendorf <[email-masked]>
Date: Tue, 8 Jun 2010 08:39:26 +0200

I see your point, yes, there is no concept of "pushing" in REST.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 08 Jun 2010 14:41:17 +0100

In my mind the aim for distinguishing the message types and methods is 
an attempt to be able to model transactions appropriate for M2M but 
where a subset of the model could actually map very easily to the 
transactional models currently being used using HTTP

With respect to client/server - I have no issue with whatever 
terminology is used as long as it is appropriate and consistent. 
Sink/source works but implies a push-only to some extent or at least a 
certain 'gravity'; a sink could still pull but that's not the usual 
behavior associated with a sink. Provider/consumer is better as it does 
not imply push/pull (I will use this in the following MSCs)

Here are some random MSCs I drew some time ago for illustration of my 
original concept to show the flexibiltiy. However, fundamentally I agree 
they could all be the same message and the function implied in the 
method. Whether this is clearer or not is a moot point.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> : Request
------------------------------------------> : Response
==========================================> : Notify

1) Long poll, request/response message types

Consumer                                     Provider
   |                                           |
   |  1.) GET to Resource URI                  |
   |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
   |                                           |
   |                                           |
   =                                           =
   |                                           | Resource is updated
   |  2.) 200 OK                               |
   |      [Resource representation]            |
   |<------------------------------------------|
   |  3.) GET to Resource URI                  |
   |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
   |                                           |
   |                                           |
   =                                           =
   |                                           | Resource is updated
   |  4.) 200 OK                               |
   |      [Resource representation]            |
   |<------------------------------------------|
   |  5.) GET to Resource URI                  |
   |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>|
   |                                           |

2) Streaming, notify message types only.

Consumer                                     Provider
   |                                           |
   |  1.) GET to Resource URI                  |
   |==========================================>|
   |                                           |
   |                                           |
   =                                           =
   |                                           | Resource is updated
   |  2.) PUT                                  |
   |      [Resource representation]            |
   |<==========================================|
   |                                           |
   |                                           |
   =                                           =
   |                                           | Resource is updated
   |  3.) PUT                                  |
   |      [Resource representation]            |
   |<==========================================|
   |                                           |

3) Subscription manager, request/response message types

Consumer                                     Provider
   |                                           |
   |  1.) POST to Resource subscription URI    |
   |      [Notify Resource]                    |
   |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| Notify Resource registered
   |  2.) 200 OK                               |
   |<------------------------------------------|
   |                                           |
   |                                           |
   =                                           =
   |                                           | Resource is updated
   |  3.) PUT to Notify Resource URI           |
   |      [Resource representation]            |
   |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
   |  4.) 200 OK                               |
   |------------------------------------------>|
   |                                           |
   |                                           |
   =                                           =
   |                                           |
   |                                           | Resource is updated
   |  5.) PUT to Notify Resource URI           |
   |      [Resource representation]            |
   |<~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
   |  6.) 200 OK                               |
   |------------------------------------------>|
   |                                           |
   |  7.) DELETE to Resource subscription URI  |
   |      [Notify Resource]                    |
   |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| Notify Resource 
unregistered
   |  8.) 200 OK                               |
   |<------------------------------------------|
   |                                           |

4) Subscription manager, request/response/notify message types

Consumer                                     Provider
   |                                           |
   |  1.) POST to Resource subscription URI    |
   |      [Notify Resource]                    |
   |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| Notify Resource registered
   |  2.) 200 OK                               |
   |<------------------------------------------|
   |                                           |
   |                                           |
   =                                           =
   |                                           | Resource is updated
   |  3.) PUT to Notify Resource URI           |
   |      [Resource representation]            |
   |<==========================================|
   |                                           |
   |                                           |
   =                                           =
   |                                           |
   |                                           | Resource is updated
   |  4.) PUT to Notify Resource URI           |
   |      [Resource representation]            |
   |<==========================================|
   |                                           |
   |  5.) DELETE to Resource subscription URI  |
   |      [Notify Resource]                    |
   |~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>| Notify Resource 
unregistered
   |  6.) 200 OK                               |
   |<------------------------------------------|
   |                                           |

Robert

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064

On 07/06/2010 1:19 PM, Guido Moritz wrote:
> You mean messaging pattern between the server and client? Of course, 
> for interoperability reasons there should be a clear specification 
> which is the correct response on a request. But when using a datagram 
> transport protocol like UDP and due to the partly expected high delay 
> between request and response, messaging is be asynchronous by design. 
> So this might be not be obviously classical client/server 
> communication but more data sink/data source (or service 
> provider/service consumer in terms of SOAs). Thus relationship between 
> request and response is part of the application layer and not of the 
> transport layer like in traditional HTTP.
>
> Guido
>
> *Von:* [email-masked] [mailto:[email-masked]] *Im 
> Auftrag von *Robert Cragie
> *Gesendet:* Freitag, 4. Juni 2010 15:29
> *An:* [email-masked]
> *Betreff:* Re: [core] Subscribe/Notify for CoAP
>
> Hi Zach,
>
> suitable transaction model. Beyond that, we should specify methods, 
> as, after all, this is CORE (RESTful environments) - the REST 
> architectural style does impose rules here.
>
> thinking about packets flying about between peers doesn't help from 
> the point of view of a processing environment particularly, so again 
> is the aim to try to provide a pattern here?
>
> Robert
>
>     On Fri, May 28, 2010 at 1:22 PM, Robert Cragie<[email-masked]>  <mailto:[email-masked]>  wrote:
>
>     In the most abstract sense, processing is governed by a thread of execution, which sequences a series of data transformations to expedite the required processing. If a data transformation can be completed synchronously in the thread of execution, then the thread is conceptually easier to understand and follow. Most threading models assume this to be the case and if the data transformation cannot complete, it usually blocks pending the required event to complete the transformation. During blocking, the thread is suspended. In simple CPU models without any sort of scheduler, there are two threads of execution: A main thread, pre-emptable by an interrupt thread, usually not pre-emptable. In the main thread, sub-threads are emulated; data transformations can be simply function calls which don't block and therefore return effectively immediately and synchronously. Blocking data transformations are emulated by storing state relevant to each sub-thread then marshaling each event as
>
>       it is received e.g. through interrupt handling, which causes the second thread to run and thus allows changing sub-thread state so when the main thread runs, the blocking data transformation can complete. Operating system schedulers for these simple CPUs simply abstract this operation through a kernel and associated task/thread scheduling calls. Continuations are a simpler form used in memory-constrained implementations.
>
>       
>
>       . Request
>       . Response
>       . Notify
>         <[email-masked]>  <mailto:[email-masked]>
>
>           wrote:
>
>            
>
>           
>
>                
>
>             Hi,
>
>               
>
>             This is a really good conversation. One thing we need to do is remember what our minimum requirements are for subscribe/notify and not try to solve something more than we should.> From what I know it is sufficient to be able to receive notifications when a URI changes or periodically. You might consider new URIs under this URI path to be changes to a URI though...
>
>               
>
>                 [email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]
>
>                 ]
>
>                 [email-masked]  <mailto:[email-masked]>;[email-masked]  <mailto:[email-masked]>
>
>                   
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                   
>
>                   
>
>                   
>
>                   
>
>                   
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                   
>
>                 Envoyé par :
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                   
>
>                 28/05/2010 12:50
>
>                   

>
>
>                 A
>
>
>                   
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                   
>
>
>                 cc
>
>
>                 core
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                   
>
>
>                 Objet
>
>
>                 [email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]
>
>                 [email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                   wrote:
>
>                   
>
>                   
>
>                   
>
>                 Hi,
>
>                   
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                   
>
>                   
>
>                   
>
>                   
>
>                   
>
>                 "Charles Palmer"
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                   
>
>                 Envoyé par :
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                   
>
>                 15/05/2010 14:06
>
>                   
>
>
>                 A
>
>
>                 "core"
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                   
>
>
>                 cc
>
>
>
>                 Objet
>
>
>                 [email-masked]  <mailto:[email-masked]>  [mailto:[email-masked]
>
>                 ] On Behalf Of
>
>                 Angelo P. Castellani
>
>                 Sent: 14 May 2010 13:14
>
>                 To: Zach Shelby
>
>                 Cc: core
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                   wrote:
>
>                   
>
>                   
>
>                 Hi Angelo,
>
>                   
>
>                 <[email-masked]>  <mailto:[email-masked]>
>
>                 wrote:
>
>                   
>
>                   
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 "  <http://6lowpan.net-Mybook>
>
>                 http://6lowpan.net - My book "  <http://6lowpan.net-Mybook>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>                 [email-masked]  <mailto:[email-masked]>
>
>             "  <http://6lowpan.net-Mybook>
>
>             http://6lowpan.net - My book "  <http://6lowpan.net-Mybook>
>
>             [email-masked]  <mailto:[email-masked]>
>
>         [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>
>     [email-masked]  <mailto:[email-masked]>
>