Subject: [core] Fwd: I-D Action:draft-hartke-coap-observe-01.txt

From: Carsten Bormann <[email-masked]>
Date: Thu, 8 Jul 2010 21:41:39 +0200

Klaus and I have added a fleshed-out minimal specification to the draft so we can discuss this in more specific terms.
(We haven't really had time to update the existing text, which is now maintained as the rationale in an appendix -- maybe we can manage to do this before the I-D cutoff.)

Now I would love to have time to implement that...

Gruesse, Carsten

Begin forwarded message:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Observing Resources in CoAP
> 	Author(s)       : K. Hartke, C. Bormann
> 	Filename        : draft-hartke-coap-observe-01.txt
> 	Pages           : 29
> 	Date            : 2010-07-08
> 
> The state of a resource can change over time.  We want to give
> clients of the CoRE WG CoAP protocol the ability to observe this
> change.  This short I-D provides an example design for such an
> addition to CoAP, in order to be able to discuss the design
> alternatives in specific terms.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-hartke-coap-observe-01.txt

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 16 Jul 2010 15:51:36 +0300

Hi there,

in section 4. "HTTP mapping"

As long as the resource state hasn’t changed, the proxy holds the
request and waits for the resource to change, instead of sending an
empty (304) response.

however the presence of unknown timeouts values anywhere in the path between
client, server and also in any proxy present along the path implies that
sometime the answer can not wait
as long as it that for the resource to change, but an empty (304)
response have to be sent anyway.

http://www.ietf.org/id/draft-loreto-http-timeout-00.txt  is a first
proposal on how to deal with timeout during a
long poll request.

cheers
/Sal

On 7/8/10 10:41 PM, Carsten Bormann wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>    

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 16 Jul 2010 18:44:31 +0300

On 7/16/10 4:27 PM, Carsten Bormann wrote:
> Salvatore,
> these new headers appear to be interesting optimizations.
> In my previous work that used long-polling I have never found an absolute need to solve the problems you are noting, though.
> I also think it would be dangerous to have an HTTP mapping that relies on new features that aren't universally deployed today.
>
> So if your proposal is picked up on the HTTP side, what do you think should be the transition strategy?
>    
I am not suggesting to use the header(s) proposed in the draft, the 
draft was just a pointer to better explain the fact that
in the HTTP side the long delay in an answer (in this case in a long 
polling request) can cause time-out (in the client or in an intermediary)
making impossible deliver the answer once the server has one to provide 
back to the client.
That  is something that IMO is worth to be mentioned in the draft.

/Sal

-- 
Salvatore Loreto
www.sloreto.com

> (As far as I can see, there is no impact on the CoAP side, just potentially on the preferred headers used by an HTTP mapper.)
>
> Gruesse, Carsten
>
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 16 Jul 2010 15:27:59 +0200

Salvatore,

Gruesse, Carsten