Re: [6lowapp] draft-shelby-6lowapp-coap-00

[Paul Duffy <[e-mail]>]

Hi Adriano,

Given the constraints of REST's messaging patterns,  the method 
described below is essentially polling on an event object.  Any concerns 
with lots of this occurring in a BW limited environment and/or battery 
consumption issues?


On 1/26/2010 12:56 PM, Adriano Pezzuto (apezzuto) wrote:
> Hi Zach,
> I would to give a bit regarding CoAP/HTTP mapping and notification messages from constrained devices to wider Internet and vice versa.
>
> Basically, the issue here is that HTTP has a synchronous request-response model where a NOTIFY is an asynch event. Searching on the REST literature, there is cute way to handle asynch tasks within a synch model. Let to split the asynch operation into more synchronous requests. The first request spawns the operation, and the other requests let the client to be informed about the status of the operation.
>
> Let to consider a client node on the internet subscribing to a server node for a data event notification (e.g. temperature crossing a threshold). The server node is in the constrained environment and a CoAP/HTTP interworking function is running between client and server.
>
> The client node makes its subscribe request by sending a POST message to the server node.
> The server node accepts the request, creates a new resource representing the event and put it in a queue.
> Instead of keeping the client node waiting until the event happens, the server sends to the client (by CoAP/HTTP IWF) an HTTP 202 Accepted and gives it a new URL that represents the new created resource.
> Then the client can make GET requests to that URL until the event happens.
> Once the client has 'consumed' the event it can DELETE the event resource from the server queue.
>
> Better ways exist to accomplish the same task but hope this can help.
>
> Regards,
> Adriano
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Zach Shelby
> Sent: martedì 19 gennaio 2010 14.37
> To: 6LoWAPP
> Subject: [6lowapp] draft-shelby-6lowapp-coap-00
>
> Does anyone have comments/ideas regarding http://www.ietf.org/id/draft-shelby-6lowapp-coap-00.txt that we submitted before the holidays? We would like to start some design work, so any feedback would be really useful. I've identified some areas where we need input/discussion on the list:
>
> 1. Content-type encoding (Section 2.4). Any ideas or suggestions on how to encode this and what is enough space? How should such an encoding be managed, ask IANA to do that? Any pointers to a similar encoding done elsewhere?
>
> 2. Caching (Section 2.6). Should we go towards an in-band or an out-of-band discovery approach? Personally I think an in-band approach is by far the simplest, although it requires some header space when present.
>
> 3. Subscribe/Notify (Section 2.7). This is an area that definitely needs discussion. The current proposal is to use a REST interface to create subscriptions and which are then sent using a NOTIFY message to a call-back URL. How to format the body o the subscription (URL to subscribe to, URL call-back, parameters?).
>
> 4. Resource Discovery (Section 2.9). The proposal is to use a new DISCOVER method which can be sent either unicast or multicast. The only difficult part there is the format of the list of resources (URLs) which would be returned in such a response. This is a little bit like index.html. We had some discussions in Hiroshima that XMPP has developed some ways of coding lists of URLs and that could be re-used. Does someone have a pointer for us on that?
>
> Thanks,
> Zach
>
>