Re: [core] Handling tokens for No-response

[Likepeng <[e-mail]>]

> Could anyone help to tell what does "An empty token value" in CoAP -18 mean?
> Is it the zero length token or the value of token being zero?

In my understanding, "empty token value" means zero-length token.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: core [mailto:[e-mail]] 代表 weigengyu
> 发送时间: 2014年4月23日 8:47
> 收件人: Dijk, Esko; Abhijan Bhattacharyya
> 抄送: [e-mail]
> 主题: Re: [core] Handling tokens for No-response
> 
> Hi all,
> 
> I agree that No-Response may need for some situations.
> 
> But the different between zero length of token and the value of  token being
> zeron should be clear.
> 
> Could anyone help to tell what does "An empty token value" in CoAP -18
> mean?
> Is it  the zero length token or the value of token being zero?
> 
> Regards,
> 
> Gengyu
> Network Technogy Center
> School of Computer
> Beijing University of Posts and Telecommunications
> 
> -----原始邮件-----
> From: Dijk, Esko
> Sent: Tuesday, April 22, 2014 5:34 PM
> To: Abhijan Bhattacharyya
> Cc: [e-mail]
> Subject: Re: [core] Handling tokens for No-response
> 
> Hello Abhijan,
> 
> I forgot to mention that using  the No-Response Option is not a guarantee
> that no response will come. It actually MAY come since the Option is elective.
> That is something that needs to be taken into account by a client in its Token
> re-use strategy. If not it leads to interoperability issues, or not?
> E.g. "client expects no answer to its request with Token=0, so it sends out a
> new request with Token=0, but server does not recognize No-Response option,
> and sends a response, then the client receives the old delayed response with
> Token=0 instead of the newer response with same Token".
> 
> Esko
> 
> -----Original Message-----
> From: core [mailto:[e-mail]] On Behalf Of Dijk, Esko
> Sent: Tuesday, April 22, 2014 08:53
> To: Carsten Bormann; Abhijan Bhattacharyya
> Cc: [e-mail]
> Subject: Re: [core] Handling tokens for No-response
> 
> Hi,
> 
> if there's no time limit that can be defined for Token re-use, what time
> would an implementer of a client need to choose?   (I know we chose not to
> define 'patience' in CoAP, but an implementer would still need to make a sane
> choice here.) Can we argue that Patience i.e. max response delay will be "a few
> minutes" and hence Token can be re-used safely after a time far longer than
> that, say 15 minutes?
> 
> For those cases where the implementer of the CoAP client knows that a
> response may take very long (e.g. see OMA LWM2M case, "queue mode"
> function, where a response could take e.g. one day) he could adapt the
> Patience to something much longer.
> 
> Would that be a feasible approach?
> I feel that it would be beneficial if the No-Response draft would say something
> about this Token re-use for unicast and multicast NON requests.
> If several people in the CoRE WG saw it wrong, it may be worth pointing out as
> well to a non-CoRE audience ;)
> 
> Esko
> 
> -----Original Message-----
> From: Carsten Bormann [mailto:[e-mail]]
> Sent: Thursday, April 17, 2014 15:08
> To: Abhijan Bhattacharyya
> Cc: weigengyu; Dijk, Esko; Rahman, Akbar; [e-mail]
> Subject: Re: [core] Handling tokens for No-response
> 
> On 17 Apr 2014, at 14:22, Abhijan Bhattacharyya
> <[e-mail]> wrote:
> 
> > We cannot, as a general proposition, get rid of tokens while using
> > No-response considering potential use of this option with a GET  for
> > proactive cancellation of an observe session (Ref: <1> section 3.8 of
> > draft-ietf-core-observe-13 and
> > <2>http://www.ietf.org/mail-archive/web/core/current/msg05331.html).
> > A GET request to cancel an observe session must carry a token to
> > associate itself with the existing observe session.
> 
> While this is true, this is not the point that I was making.
> I was pointing out that a request that is defined in such a way that it MAY elicit
> a response (depending on some condition unknown to the client at the
> time) generates hardship for the client, because in the absence of a response it
> does not know whether it can retire the token or still has to expect a response
> for that.
> 
> Now if the client does not care about whether any response coming back is
> related back to the right request, it can reuse tokens at liberty.
> (Including the zero-length token, which is in no way special, except that it is
> indeed shorter than any other token.)
> 
> > So, as elaborated by Esko, possibly it would be good to suggest some
> > time-out (so its a MAY and not a MUST to give flexibility to the
> > application developer as pointed out by Akbar ). The present draft
> > adapts the definition of NON_LIFETIME as the reuse interval for message IDs.
> > Would it be a good idea to adapt the same definition as the re-use
> > interval for tokens also? The definition of NON_LIFETIME encompasses
> > EXCHANGE_LIFETIME as well.
> 
> In CoAP, we have timers at the message layer, not at the request/response
> layer.
> Most clients will have a "patience" up to which they will expect a response, but
> we currently do not expose this at the protocol level.
> (With some new option, the client could pose a deadline to the server, or the
> server could promise a deadline to the client.
> http://tools.ietf.org/html/draft-bormann-coap-misc-26#appendix-B.4 has
> more about that.)
> 
> Gr.AN|N_e, Carsten
> 
> 
> ________________________________
> 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.
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
> 
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core