Subject: [core] Considering how to use Token

From: "weigengyu" <[email-masked]>
Date: Mon, 14 Jul 2014 09:15:07 +0800

Hi all, 

I have a question about using token when considering implementation of CoAP. 
My question is whether the Token is needed in  a message of Empty?

In RFC7252, Page 21, 
“Separate from the message type, a message may carry a request, a response, or be Empty. 
This is signaled by the Request/Response Code field in the CoAP Header 
and is relevant to the request/response model. 
Possible values for the field are maintained in the CoAP Code Registries (Section 12.1).
An Empty message has the Code field set to 0.00. 
The Token Length field MUST be set to 0 and bytes of data MUST NOT be present after the Message ID field. 
If there are any bytes, they MUST be processed as a message format error. “

According to RFC7252,
the message of Empty is used to acknowlege the CON message by MID,  and Token is meaningless.
Could the token be omitted in the message of Empty? 

Regards, 

Gengyu WEI
Network Technology Center
School of Computer 
Beijing University of Posts and Telecommunications

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 14 Jul 2014 12:10:48 +0200

Hi,

> Could the token be omitted in the message of Empty? 

The text you are referring to clearly states that an Empty message
contains no token. If there is data after the 4-byte header, the
recipient will treat this as an error.

Gruesse
Olaf

---

From: "weigengyu" <[email-masked]>
Date: Mon, 14 Jul 2014 21:25:12 +0800

Hi Olaf,

> recipient will treat this as an error.

The RFC7252'text are " The Token Length field MUST be set to 0 ".
As I understand that it means there is Token option but the token length 
field is ZERO.
It does not means there is no Token option.
If there is no Token option, there is no necessary to set the token length 
field.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Olaf Bergmann
Sent: Monday, July 14, 2014 6:10 PM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] Considering how to use Token

Hi,

Gruesse
Olaf

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 14 Jul 2014 15:43:12 +0200

"weigengyu" <[email-masked]> writes:

> As I understand that it means there is Token option but the token
> length field is ZERO.
> If there is no Token option, there is no necessary to set the token
> length field.

There is no Token option at all in any message. In RFC 7252, a token is
a sequence of 0--8 bytes. The header field TKL which is always present
gives the actual length of the token included after the base header. As
a consequence, you cannot distinguish between a token of length 0 and no
token because both have TKL == 0 and nothing else.

Gruesse
Olaf

---

From: "weigengyu" <[email-masked]>
Date: Mon, 14 Jul 2014 22:25:10 +0800

Hi, Olaf,

The difference is clear.

No Token option is there no any fields about token.
Zero length token is a kind of token only the token length is set to Zero.
When a token length is set to Zero, that means there is a token.

An Empty message with a Zero length token works the same as No token option.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Olaf Bergmann
Sent: Monday, July 14, 2014 9:43 PM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] Considering how to use Token

Gruesse
Olaf

---

From: "weigengyu" <[email-masked]>
Date: Thu, 17 Jul 2014 14:45:38 +0800

Hi,

Thanks Olaf and Kepeng for your explainationgs.

There is question of implemetation of CoAP Empty message and ZLT.
Why the empty message must use Zero length token?

In RFC7252 page 21,
"An Empty message has the Code field set to 0.00. The Token Length
field MUST be set to 0 and bytes of data MUST NOT be present after the 
Message ID field.

As the Zero length token in the Empty message does not index any request and 
response,
the client should keep the relation between MID and the REQUEST's Token as 
long as to send each message of REQUEST.
when it receives an Empty message, the client can see which request the 
Empty Code belongs to
only by the relation between MID and the REQUEST's Token instead of ZLT.

Is it possbile to use the REQUEST's Token in the Empty message?
If yes, the client can get directly from the received Empty message that 
which request will has a separate response by Token.
And the client will not need to keep the relation between MID and the 
request's Token for every REQUESTs.

Regards,

Gengyu WEI
-----原始邮件----- 
From: weigengyu
Sent: Monday, July 14, 2014 10:25 PM
To: Olaf Bergmann
Cc: [email-masked]
Subject: Re: [core] Considering how to use Token

Hi, Olaf,

The difference is clear.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Olaf Bergmann
Sent: Monday, July 14, 2014 9:43 PM
To: weigengyu
Cc: [email-masked]
Subject: Re: [core] Considering how to use Token

Gruesse
Olaf

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

---

From: Likepeng <[email-masked]>
Date: Thu, 17 Jul 2014 07:15:48 +0000

> Is it possible to use the REQUEST's Token in the Empty message?

In my understanding, if the request has zero length token, the response should also have zero length token.

They can be matched.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: core [mailto:[email-masked]] 代表 weigengyu
> 发送时间: 2014年7月17日 14:46
> 收件人: [email-masked]
> 主题: Re: [core] Considering how to use Token
> 
> Hi,
> 
> "An Empty message has the Code field set to 0.00. The Token Length field
> MUST be set to 0 and bytes of data MUST NOT be present after the Message
> ID field.
> 
> response, the client should keep the relation between MID and the REQUEST's
> Token as long as to send each message of REQUEST.
> Empty Code belongs to only by the relation between MID and the REQUEST's
> Token instead of ZLT.
> 
> If yes, the client can get directly from the received Empty message that which
> request will has a separate response by Token.
> There is no Token option at all in any message. In RFC 7252, a token is a
> sequence of 0--8 bytes. The header field TKL which is always present gives the
> actual length of the token included after the base header. As a consequence,
> you cannot distinguish between a token of length 0 and no token because both
> have TKL == 0 and nothing else.
> 
> Gruesse
> Olaf
>

---

From: "weigengyu" <[email-masked]>
Date: Thu, 17 Jul 2014 16:47:22 +0800

HI Kepeng,

Yes.

The client may send a message with a ZTL.
But the Zero Length Token in REQUEST is different from the ZLT in an Empty 
message.
The former is used to match a response with a request.
The latter is meaningless.

And most of the messages carring REQUEST should have tokens not to be ZLT.
The Empty message as ACK will have a ZLT which is meaningless.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Likepeng
Sent: Thursday, July 17, 2014 3:15 PM
To: weigengyu ; [email-masked]
Subject: Re: [core] Considering how to use Token

> Is it possible to use the REQUEST's Token in the Empty message?

In my understanding, if the request has zero length token, the response 
should also have zero length token.

They can be matched.

Kind Regards
Kepeng

> which

---

From: Likepeng <[email-masked]>
Date: Thu, 17 Jul 2014 09:01:02 +0000

> But the Zero Length Token in REQUEST is different from the ZLT in an Empty message.

In my understanding, they are the same. There is no difference.

But let’s hear other's opinion.

Kind Regards
Kepeng

> -----邮件原件-----
> 发件人: weigengyu [mailto:[email-masked]]
> 发送时间: 2014年7月17日 16:47
> 收件人: Likepeng; [email-masked]
> > As the Zero length token in the Empty message does not index any
> > request and response, the client should keep the relation between MID
> > and the REQUEST's Token as long as to send each message of REQUEST.
> > when it receives an Empty message, the client can see which request
> > the Empty Code belongs to only by the relation between MID and the
> > REQUEST's Token instead of ZLT.
> >
> > If yes, the client can get directly from the received Empty message
> > that which request will has a separate response by Token.
> > There is no Token option at all in any message. In RFC 7252, a token
> > is a sequence of 0--8 bytes. The header field TKL which is always
> > present gives the actual length of the token included after the base
> > header. As a consequence, you cannot distinguish between a token of
> > length 0 and no token because both have TKL == 0 and nothing else.
> >
> > Gruesse
> > Olaf
> >

---

From: "weigengyu" <[email-masked]>
Date: Thu, 17 Jul 2014 17:08:14 +0800

OK!

A client may choose to use a ZLT in a REQUEST.
The responder is forced to use ZLT in an Empty message no matter what the 
REQUEST'token is.

Regards,

Gengyu WEI
-----原始邮件----- 
From: Likepeng
Sent: Thursday, July 17, 2014 5:01 PM
To: weigengyu ; [email-masked]
Subject: Re: [core] Considering how to use Token

Kind Regards
Kepeng

---

From: "weigengyu" <[email-masked]>
Date: Thu, 17 Jul 2014 22:34:59 +0800

Hi all,

I put another question of how to use token for block-wise transfer.

The question is what is one REQUEST in block-wise transfer.
When there is a large payload to transfer,
does it belong to one request, or does it is partiioned into multiple 
request.
Understanding what is one request is for using token adquate.

1. In the Abstract of draft-ietf-core-block-14,
" Instead of relying on IP fragmentation, this specification extends
basic CoAP with a pair of "Block" options, for transferring multiple
blocks of information from a resource representation in multiple
request-response pairs. "

The multiple request-response pairs imply that there are many requests for 
transfering the large data.

2. In page 10 of draft-ietf-core-block-14,
"Using one or both Block options, a single REST operation can be split into 
multiple CoAP message exchanges.
As specified in [I-D.ietf-core-coap], each of these message exchanges uses 
their own CoAP Message ID."

this statement implys to transfer a large payload of single REST operation 
into many messages.
It is one request including the large data.

It is not clear in draft-ietf-core-block-14 that it is 1, or 2, or both for 
tranfering large data.
By 1, each block is a request. Each message carrying the block should has an 
unique token.
By 2, every block belongs to one request. Every message carrying the block 
should use the same token.

There have been some discussions by which tokens could be different or the 
same.
In the Abstract of draft-ietf-core-block-14, "the Block options provide a 
minimal way to transfer larger representations in a block-wise fashion."
The Block option over-controls the block request and the block response by 
ignoring  tokens.

But it is unclear how to assign the token.
Or always using the ZLT.

Regards,

Gengyu WEI
-----原始邮件----- 
From: weigengyu
Sent: Thursday, July 17, 2014 5:08 PM
To: Likepeng ; [email-masked]
Subject: Re: [core] Considering how to use Token

OK!

Regards,

Gengyu WEI
-----原始邮件----- 
From: Likepeng
Sent: Thursday, July 17, 2014 5:01 PM
To: weigengyu ; [email-masked]
Subject: Re: [core] Considering how to use Token

Kind Regards
Kepeng

---

From: Likepeng <[email-masked]>
Date: Fri, 18 Jul 2014 01:14:50 +0000

>It is not clear in draft-ietf-core-block-14 that it is 1, or 2, or both for transferring large data.
>By 1, each block is a request. Each message carrying the block should has an unique token.

Carsten explained that the token can be the same or different.
http://www.ietf.org/mail-archive/web/core/current/msg05441.html

> should use the same token.

The spec says "a single REST operation", it does not say it is "one request".

Kind Regards
Kepeng

> 发送时间: 2014年7月17日 22:35
> When there is a large payload to transfer, does it belong to one request, or
> does it is partiioned into multiple request.
> 1. In the Abstract of draft-ietf-core-block-14, " Instead of relying on IP
> fragmentation, this specification extends basic CoAP with a pair of "Block"
> options, for transferring multiple blocks of information from a resource
> representation in multiple request-response pairs. "
> 
> 2. In page 10 of draft-ietf-core-block-14, "Using one or both Block options, a
> single REST operation can be split into multiple CoAP message exchanges.
> this statement implys to transfer a large payload of single REST operation into
> many messages.
> It is not clear in draft-ietf-core-block-14 that it is 1, or 2, or both for tranfering
> large data.
> > In my understanding, if the request has zero length token, the
> > response should also have zero length token.
> >
> > They can be matched.
> >
> > Kind Regards
> > Kepeng
> >
> > > -----邮件原件-----
> > > field MUST be set to 0 and bytes of data MUST NOT be present after
> > > the Message ID field.
> > >
> > > request and response, the client should keep the relation between
> > > MID and the REQUEST's Token as long as to send each message of
> REQUEST.
> > > And the client will not need to keep the relation between MID and
> > > the request's Token for every REQUESTs.
> > >
> > > Regards,
> > >
> > > Gengyu WEI
> > > >> The text you are referring to clearly states that an Empty
> > > >> message contains no token. If there is data after the 4-byte
> > > >> header, the recipient will treat this as an error.
> > > >
> > > > If there is no Token option, there is no necessary to set the
> > > > token length field.
> > >