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

I would agree that asynchronous notifications as a default are a better model in a resource constrained environment. Polling could be used as an option when resources allow. The architecture and philosophy is similar to the one used in network management where devices send notifications at boot time (coldStart) or when an application initializes (warmStart), while a management application (typically not powered constrained) may poll periodically the devices to make sure notifications were not lost. 

Dan

> -----Original Message-----
> From: 6lowapp-bounces@ietf.org 
> [mailto:6lowapp-bounces@ietf.org] On Behalf Of Don Sturek
> Sent: Tuesday, January 26, 2010 10:43 PM
> To: paduffy@cisco.com; 6lowapp@ietf.org
> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00
> 
> 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: 6lowapp-bounces@ietf.org 
> [mailto:6lowapp-bounces@ietf.org] On Behalf Of Paul Duffy
> Sent: Tuesday, January 26, 2010 11:46 AM
> To: 6lowapp@ietf.org
> 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: 6lowapp-bounces@ietf.org [mailto:6lowapp-bounces@ietf.org] 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
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
> 
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
> 