Subject: Re: [core] draft-ietf-core-coap-06 Request Timeout

From: Salvatore Loreto <[email-masked]>
Date: Wed, 29 Jun 2011 12:49:23 +0300

I know I am biased here,
but I do like to possibility for a client to specify the max time it is 
willing to wait for a response

of course differently from the HTTP world, in CoRe we have to deal with 
sleeping sensors so
maybe other then a new response code "can't provide the data in time" , 
as proposed by Carsten,
we also need a more general response code that can be sent by a Proxy 
"the sensor is sleeping"

more what really means inserting the Request Timeout header in a 
POST/PUT request:
if the sensor is not able to handle the request in that interval of 
time, what it the right behavior?
should the request simple be discarded or what?

cheers
/Sal

-- 
Salvatore Loreto
www.sloreto.com

On 5/10/11 4:06 PM, Carsten Bormann wrote:
> On May 10, 2011, at 03:17, Likepeng wrote:
>
>> I have a draft to let the client to define a timeout in the request:
>> http://tools.ietf.org/id/draft-li-core-coap-response-mode-option-00.txt
>>
>> [...]
>> I would like to get feedback from you on the draft.
> Sure.
>
> 1) Get rid of the P bit.
>     Influencing this is none of the client's business.
>     It is not even useful for a client -- since the option is elective, the client cannot even rely on it being heeded.
>     There is no option in TCP to control whether the peer should send its data piggybacked on an ACK either.
>
> 2) I think I like the T part of the option.
>     However, it should be rephrased as
>
> 	"indicates the length of time from the time of request the response would be useful for the client".
>
>     Because that's all we can say.  If the server doesn't have the data, it doesn't have it.
>
>     Representing T in exponential form sounds fine to me (but we have had some arguments on duration representation before).  I would deliberately keep the spec open on whether the base is milliseconds or 1024s of a second -- the clocks are not going to be that precise anyway, and this might help some implementations that count in 1024s ("mibiseconds") or in whole seconds.
>
> 3) T should not have a default value.
>
>     (I'm not going to repeat why that would be a mistake, see my previous messages.)
>
> 4) We also need a new response code, "can't provide the data in time".
>
>     This is a code that a server that already knows it won't be able to meet the deadline can send early on.
>     (Note that the client cannot rely on getting the response code, because the server might have failed in the meantime.)
>
> We haven't really discussed the difference between what is Connection-Timeout in draft-thomson-hybi-http-timeout-00 and this option, which is similar to Request-Timeout in that draft.
>
> Gruesse, Carsten
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>