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

[Zach Shelby <[e-mail]>]

And a figure may help, this is what using a long poll would look like:

Sensor  <---------  coap --------->  Proxy <---------- http -----------> Client	 

	 CREATE subscribe /temp	   <<<	  POST subscribe /temp
			   OK			   >>> 	 	   OK (/sub1)	    
							     *  	      LONG GET /sub1
									       GET stays open....
*/temp changes*						
 		NOTIFY /temp		  >>>	 	    OK (/temp)
		           OK


On Jan 27, 2010, at 10:00 , Zach Shelby wrote:

> I think there is a misunderstanding there. Adriano was describing what technique could be used on the HTTP side to realize the mapping with the CoAP subscribe/notify feature. Obviously the CoAP side would use asynchronous notifications sent by the sensor node, no problem there. When a proxy (server node below) maps that to HTTP, you need to use some kind of long pull technique between the proxy and the HTTP subscriber. Lisa gave a good pointer that the new HYBI working group is chartered to develop a long pull approach for HTTP - which we may be able to make use of.
> 
> Did I summarize that right Adriano?
> 
> Zach
> 
> On Jan 27, 2010, at 9:53 , Van Der Stok, Peter wrote:
> 
>> Hi Zach, Adriano,
>> 
>> I would not be too happy about polling a sleeping device. It kind of beats the original purpose of having a subscription.
>> 
>> Peter
>> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Adriano Pezzuto (apezzuto)
>> Sent: Tuesday 26 January 2010 18:56
>> To: Zach Shelby
>> Cc: 6LoWAPP
>> Subject: Re: [6lowapp] draft-shelby-6lowapp-coap-00
>> 
>> 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
>> 
>> --
>> http://www.sensinode.com
>> http://zachshelby.org - My blog "On the Internet of Things"
>> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
>> Mobile: [phone]
>> 
>> Zach Shelby
>> Head of Research
>> Sensinode Ltd.
>> Kidekuja 2
>> 88610 Vuokatti, FINLAND
>> 
>> This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 6lowapp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowapp
>> _______________________________________________
>> 6lowapp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6lowapp
>> 
>> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
> 
> -- 
> http://www.sensinode.com
> http://zachshelby.org - My blog "On the Internet of Things"
> http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
> Mobile: [phone]
> 
> Zach Shelby
> Head of Research
> Sensinode Ltd.
> Kidekuja 2
> 88610 Vuokatti, FINLAND
> 
> This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof. 
> 
> 
> 
> 
> _______________________________________________
> 6lowapp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6lowapp

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: [phone]

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.