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

Hi,

The recently approved HYBI WG will be taking on use cases very like
this.  The BOF discussed documenting the "long poll" approach (a
request that the client understands will not receive a response until
event or timeout occurs), long-body approach (not recommending) as
replacements to expensive repeated polling approaches.  That ended up
not being a required output of the WG according to its charter, but
that WG does have expertise in how clients know when to  poll or ask
for a notification and how servers know that the client knows what to
expect.

Lisa

On Tue, Jan 26, 2010 at 9:56 AM, Adriano Pezzuto (apezzuto)
<apezzuto@cisco.com> 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
>
> --
> 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: +358 40 7796297
>
> 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
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
> _______________________________________________
> 6lowapp mailing list
> 6lowapp@ietf.org
> https://www.ietf.org/mailman/listinfo/6lowapp
>