Re: [core] Subscribe/Notify for CoAP

[Paul Duffy <[e-mail]>]

+1


On 6/2/2010 3:12 AM, Vlad Trifa wrote:
> 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
>
>
>
> On Jun 2, 2010, at 9:21 AM, Guido Moritz wrote:
>
>> 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: [e-mail] [mailto:[e-mail]] 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: [e-mail]
>>> [mailto:[e-mail]]
>>>> Sent: venerdì 28 maggio 2010 13.52
>>>> To: Adriano Pezzuto (apezzuto)
>>>> Cc: core; [e-mail]; [e-mail]
>>>> 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
>>>>
>>>> <image001.gif>"Adriano Pezzuto (apezzuto)" <[e-mail]>
>>>>
>>>>
>>>>
>>>>
>>>> "Adriano Pezzuto (apezzuto)" <[e-mail]>
>>>> Envoyé par : [e-mail]
>>>> 28/05/2010 12:50
>>>>
>>>> <image003.png>
>>>> A
>>>> <image004.png>
>>>> <[e-mail]>
>>>> <image003.png>
>>>> cc
>>>> <image004.png>
>>>> core <[e-mail]>
>>>> <image003.png>
>>>> Objet
>>>> <image004.png>
>>>> Re: [core] Subscribe/Notify for CoAP
>>>> <image004.png>
>>>> <image004.png>
>>>>
>>>> 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:[e-mail]]
>>>> 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
>>>> [phone]
>>>> [phone]
>>>> 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:[e-mail]]
>>>> 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
>>>> [phone]
>>>> [phone]
>>>> 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: [e-mail] [mailto:[e-mail]] 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: [e-mail] [mailto:[e-mail]] 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,[e-mail]
>>> 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
>>>>
>>>>
>>>> <graycol.gif>"Charles Palmer"<[e-mail]>
>>>>
>>>>
>>>>
>>>>
>>>> "Charles Palmer"<[e-mail]>
>>>> Envoyé par : [e-mail]
>>>> 15/05/2010 14:06
>>>>
>>>> <ecblank.gif>
>>>> A
>>>> <ecblank.gif>
>>>> "core"<[e-mail]>
>>>> <ecblank.gif>
>>>> cc
>>>> <ecblank.gif>
>>>> <ecblank.gif>
>>>> Objet
>>>> <ecblank.gif>
>>>> Re: [core] Selecting a WG document for CoAP
>>>> <ecblank.gif> <ecblank.gif>
>>>>
>>>> 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: [e-mail] [mailto:[e-mail]] 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<[e-mail]> 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<[e-mail]>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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> 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: [phone]
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>
>>>> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security System.
>>>> ______________________________________________________________________
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/core
>>>> _______________________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>
>>>>
>>>>
>>>> ______________________________________________________________________
>>>> This email has been scanned by the MessageLabs Email Security System.
>>>>
>>>
>> ____________________________________________________________________________ 
>>
>> __
>>> _______________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/core
>>>>
>>>> _______________________________________________
>>>> core mailing list
>>>> [e-mail]
>>>> 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: [phone]
>>>
>>> _______________________________________________
>>> core mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/core
>>
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>