Subject: Re: [core] coap #25 (new): Token option

From: "core issue tracker" <[email-masked]>
Date: Mon, 18 Oct 2010 14:54:51 -0000

#25: Token option

Comment(by zach@…):

 Based on the discussions on the mailing list showing interest in
 developing and testing the Token option further, I suggest that we do add
 the Token option to coap-03 as Option ID 11 (Critical) as per coap-misc-06
 (ok, this draft doesn't say much about it...).

 Simple rules:

 1. If a Token Option is included in a request, the response (and any
 subsequent delayed responses) MUST include the same value in a Token
 Option.

 2. If a Token Option is included in a request, any resulting delayed
 response SHOULD NOT include the URI option (for sake of efficiency) as the
 Token is sufficient for matching it with the request.

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |       Owner:  cabo@…      
     Type:  enhancement         |      Status:  new         
 Priority:  minor               |   Milestone:  coap-03     
Component:  coap                |     Version:              
 Severity:  -                   |    Keywords:              
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/25#comment:1>
core <http://tools.ietf.org/core/>

---

From: Zach Shelby <[email-masked]>
Date: Mon, 18 Oct 2010 17:57:02 +0300

This is just to remind everyone that we do have a ticket open for the WG to consider adding the Token Option to coap-03. Since the cutoff for that is next Monday better to get started now. Below are a couple simple rules for doing this to get started with. The goal would be to gain some more implementation experience on this in the Beijing plug-fest, although quite many of us are already using tokens (and did so in the last plugfest already).

Thoughts?

Zach

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: Peter Bigot <[email-masked]>
Date: Mon, 18 Oct 2010 10:05:24 -0500

Based on my argument that some clients would benefit from being able to
control whether asynchronous responses are acceptable to them, I propose
adding:

3.  If a request does not include a Token option, the server MUST provide
its ReST response within the transaction response.

In the absence of this simplicity, we need text defining which ReST
operations can be executed asynchronously without a Token, and how that is
accomplished.

Peter

On Mon, Oct 18, 2010 at 9:54 AM, core issue tracker <[email-masked]>wrote:

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 18 Oct 2010 18:05:16 +0200

On Oct 18, 2010, at 17:05, Peter Bigot wrote:

> Based on my argument that some clients would benefit from being able to control whether asynchronous responses are acceptable to them, I propose adding:
> 
> 3.  If a request does not include a Token option, the server MUST provide its ReST response within the transaction response.

Well, we can't just say MUST; we need to provide an error code for the case where the server can't.

Also, for a GET request, I like the current situation (no option needed) much better.

Gruesse, Carsten

---

From: Peter Bigot <[email-masked]>
Date: Mon, 18 Oct 2010 13:16:22 -0500

Then make it:

3. If a request does not include a Token option, the server MUST provide its
ReST response within the transaction response.  If it cannot do so (i.e.,
can only satisfy the request through an asynchronous response), it MUST
respond with error 400 "Bad Request (TBD)

Replace 400 with some more informative code (I thought we had a ticket
related to extending the error codes in another context, but I don't
recognize it from the titles).

I prefer this wording to making an exception for GET.  Two reasons:
consistency, and support for clients that are unable to accommodate
asynchronous responses.  Nothing prevents a client from sending the GET
without a token, and retransmitting it (and future GETs to the same
authority and/or resource) with one if the server indicates it needs to send
asynchronous responses.  This same pattern is used in my proposal some
border-case failures in the block option.

Other viewpoints on this, please?

BTW: The reason I don't like server-created tokens is that it's the client,
not the server, that needs to disambiguate, and it can't if two servers it
talks to both decide to use the same token to indicate their eventual
response.

Peter

---

From: Zach Shelby <[email-masked]>
Date: Mon, 18 Oct 2010 21:23:19 +0300

Personally, I like this addition, thanks Peter. I do agree that it is clearer for the implementor of a client to know if an asynchronous response may come or not, and safer to avoid server generated tokens. 

Yes, we should have a ticket for expanding our error codes to make them useful, but I forgot to do that. Will make one soon...

Zach

On Oct 18, 2010, at 9:16 PM, Peter Bigot wrote:

> Then make it:
> 
> 3. If a request does not include a Token option, the server MUST provide its ReST response within the transaction response.  If it cannot do so (i.e., can only satisfy the request through an asynchronous response), it MUST respond with error 400 "Bad Request (TBD)
> 
> Replace 400 with some more informative code (I thought we had a ticket related to extending the error codes in another context, but I don't recognize it from the titles).
> 
> I prefer this wording to making an exception for GET.  Two reasons: consistency, and support for clients that are unable to accommodate asynchronous responses.  Nothing prevents a client from sending the GET without a token, and retransmitting it (and future GETs to the same authority and/or resource) with one if the server indicates it needs to send asynchronous responses.  This same pattern is used in my proposal some border-case failures in the block option.
> 
> BTW: The reason I don't like server-created tokens is that it's the client, not the server, that needs to disambiguate, and it can't if two servers it talks to both decide to use the same token to indicate their eventual response.
> 
> Peter
>

---

From: [email-masked]
Date: Tue, 19 Oct 2010 10:14:28 +0200

Hi Peter

I also like the idea an optional implementation of the asynchronous mode.
I think we definitively need a simple way to match a response to a request.
Comparing ((authority option OR source address) AND path option) seems too
complex compared to a simple token comparison.

But I'm a bit afraid of all the bad request error codes that force the
client to reformulate its request.
First the authority option, now the token option, then...
It involves more and more transactions to get a valid response If a client
must try all of them one by one.
What should be the default rules for clients that support asynchronous
responses ? They should always include a token option to avoid an error
code or only include it on demand and cache the result to try to save
bandwith ?

Matthieu

             Peter Bigot                                                   
             <pab@peoplepowerc                                             
             o.com>                                                      A 
             Envoyé par :              Carsten Bormann <[email-masked]>      
             core-bounces@ietf                                          cc 
             .org                      core issue tracker                  
                                       <[email-masked]>,              
                                       [email-masked]                       
             18/10/2010 20:16                                        Objet 
                                       Re: [core] coap #25 (new): Token    
                                       option                              

                                                                           

Then make it:

3. If a request does not include a Token option, the server MUST provide
its ReST response within the transaction response.  If it cannot do so
(i.e., can only satisfy the request through an asynchronous response), it
MUST respond with error 400 "Bad Request (TBD)

I prefer this wording to making an exception for GET.  Two reasons:
consistency, and support for clients that are unable to accommodate
asynchronous responses.  Nothing prevents a client from sending the GET
without a token, and retransmitting it (and future GETs to the same
authority and/or resource) with one if the server indicates it needs to
send asynchronous responses.  This same pattern is used in my proposal some
border-case failures in the block option.

Peter

On Mon, Oct 18, 2010 at 11:05 AM, Carsten Bormann <[email-masked]> wrote:
      On Oct 18, 2010, at 17:05, Peter Bigot wrote:

      > Based on my argument that some clients would benefit from being
      able to control whether asynchronous responses are acceptable to
      them, I propose adding:
      >
      > 3.  If a request does not include a Token option, the server MUST
      provide its ReST response within the transaction response.

      Well, we can't just say MUST; we need to provide an error code for
      the case where the server can't.

      Also, for a GET request, I like the current situation (no option
      needed) much better.

      Gruesse, Carsten

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
______________________________________________________________________
_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Peter Bigot <[email-masked]>
Date: Wed, 20 Oct 2010 09:34:53 -0500

As I catch up on my reviewing, I'm glad Token is going into CoAP-03 as a
critical option.  I think the combination of these three rules simplifies
things a lot, and is the right solution for several problems.  Token should
be thought of as a client-created identifier that associates CoAP
transaction messages with a single REST transaction.  It is the
pseudo-REST-level analogue to the CoAP-level transaction ID.

With the addition of Token, there is never a need for URI-related options to
appear in any response message.  Immediate responses are identified by
transaction ID; delayed responses are identified by Token.

This fixes a problem with the Location option's use in redirects: redirects
to a different authority or scheme could not be supported in an asynchronous
response because the URI component options would be required along with
Uri-Path for correlation with the original request.  Not any more.

Token should also become mandatory for use in CoAP-Observe, again because
it's how the multiple responses get correlated with a subscription request.
In the case of CoAP-Block, I suspect the token SHOULD be the same for every
request associated with a multi-block transfer, simply to preserve its
semantics as being associated with a single REST transaction.

Peter

On Mon, Oct 18, 2010 at 1:23 PM, Zach Shelby <[email-masked]> wrote:

> Personally, I like this addition, thanks Peter. I do agree that it is
> clearer for the implementor of a client to know if an asynchronous response
> may come or not, and safer to avoid server generated tokens.
>
> Yes, we should have a ticket for expanding our error codes to make them
> useful, but I forgot to do that. Will make one soon...
>
> Zach
>
> > BTW: The reason I don't like server-created tokens is that it's the
> client, not the server, that needs to disambiguate, and it can't if two
> servers it talks to both decide to use the same token to indicate their
> eventual response.
> >
> > Peter
> >

---

From: "core issue tracker" <[email-masked]>
Date: Mon, 25 Oct 2010 21:13:04 -0000

#25: Token option

Changes (by zach@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 - Token now included in coap-03

-- 
--------------------------------+-------------------------------------------
 Reporter:  zach@…              |        Owner:  cabo@…      
     Type:  enhancement         |       Status:  closed      
 Priority:  minor               |    Milestone:  coap-03     
Component:  coap                |      Version:              
 Severity:  -                   |   Resolution:  fixed       
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: <https://wiki.tools.ietf.org/wg/core/trac/ticket/25#comment:2>
core <http://tools.ietf.org/core/>