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

["Don Sturek" <[e-mail]>]

We should try to avoid polling.  A publish/subscribe mechanism where devices
opt in for notification and then are updated asynchronously is best.

Don


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf
Of Paul Duffy
Sent: Tuesday, January 26, 2010 11:46 AM
To: [e-mail]
Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00

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

_______________________________________________
6lowapp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowapp