Re: [core] Subscribe/Notify for CoAP

[Paul Duffy <[e-mail]>]

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:
> 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
>
>