Subject: [core] Comment on draft-ietf-core-coap-09

From: Avi Lior <[email-masked]>
Date: Thu, 14 Jun 2012 23:38:07 -0400

Hi,

I may be missing something.

In section 5.4.2 it states

"If the length of an option value in a request is outside the defined range, that option MUST be
treated like an unrecognized option (see Section 5.4.1)."

I am assuming that this range is what appears in table 1 in section 5.10.

Now looking at the definition of Token in that table it states that token is 1-8.  Therefore a length of zero for token is not allowed by 5.4.2.

Then reading 5.10.1 it states

Thus when the token value is empty, thenToken Option SHOULD be elided for efficiency.

That statement must be wrong right?  based on the logic above you must never send a Token Option with length 0. Right?

The fix is either to change the table to allow a length for token of zero or forbid sending an Token of length zero by changing the text in 5.10.1.

Thanks Avi.

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 15 Jun 2012 11:09:49 +0200

Avi Lior wrote:
> Now looking at the definition of Token in that table it states that token is
> 1-8.  Therefore a length of zero for token is not allowed by 5.4.2.
>
> That statement must be wrong right?  based on the logic above you must never
> send a Token Option with length 0. Right?

Conceptually, each request and each response has a token. There are
18519084246547628289 possible tokens. These tokens are encoded as a
byte sequence, with a length depending on the token between 0 and 8
bytes. When the length is 0, the Token Option is elided in the
message; when the length is 1 to 8, the Token Option with the token as
option value is included.

So both the table and the text in 5.10.1 are correct: a token can be
encoded as a byte sequence of length 0, but the Token Option never
contains a token of length 0.

Do you have a suggestion for improving the text to make this more clear?

Klaus

---

From: Avi Lior <[email-masked]>
Date: Fri, 15 Jun 2012 06:48:25 -0400

Hi Klaus,

On 2012-06-15, at 5:09 , Klaus Hartke wrote:

> snip…..  When the length is 0, the Token Option is elided
[AL] not always. Read 10.5.1 its a SHOULD not a MUST.
> in the
[AL] The text in 10.5.1 does not make it mandatory to elide the a zero length Token Option - its a SHOULD.  Therefore, the table is wrong.  If you like the table to be correct then change the SHOULD in 10.5.1 to a MUST be elided.  As long as you allow an Token Option with zero length then that table has to have 0-8 B.  Right?
> contains a token of length 0.
[AL] I still don't think so.  But I could still be missing something.

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

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 15 Jun 2012 12:53:41 +0200

Avi Lior wrote:
> The text in 10.5.1 does not make it mandatory to elide the a zero length Token Option - its a SHOULD.  Therefore, the table is wrong.  If you like the table to be correct then change the SHOULD in 10.5.1 to a MUST be elided.  As long as you allow an Token Option with zero length then that table has to have 0-8 B.  Right?

It's a "the sender MUST elide the Token Option if the token has a zero
length" and "the recipient MUST be prepared to receive a Token Option
with a zero length token". Text and table should be updated to say
that.

Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 15 Jun 2012 12:57:53 +0200

Klaus Hartke wrote:
> "the sender MUST elide the Token Option if the token has a zero
> length"

Actually it's more like "the sender MAY elide the Token Option if the
token has a zero length; as a matter of implementation quality, an
implementation is generally expected to do this" and "the recipient
MUST be prepared to receive a Token Option with a zero length token".
I don't have a strong opinion on whether the first requirement should
be a MAY with implementation note or a MUST (or a SHOULD).

Klaus

---

From: Avi Lior <[email-masked]>
Date: Fri, 15 Jun 2012 07:23:11 -0400

> with a zero length token". Text and table should be updated to say

Okay.  Amongst other wording you may add, does that mean you are going to change the range in the table from 1-8 to 0-8?

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 15 Jun 2012 19:14:41 +0200

> Okay.  Amongst other wording you may add, does that mean you are going to change the range in the table from 1-8 to 0-8?

Yes, it looks like we need to change this so a recipient does not
treat a Token Option with a zero length token as unrecognised option.
This should also end the confusion between the length of a token and
the length of the Token Option value.

Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 15 Jun 2012 20:13:17 +0200

> treat a Token Option with a zero length token as unrecognised option.

I think that's the wrong direction to resolve this.  The right way is to make sure that senders that want to send a 0 as a Token never send an option at all.

Grüße, Carsten

---

From: Avi Lior <[email-masked]>
Date: Fri, 15 Jun 2012 19:03:16 -0400

Hi,

At the moment I don't have an opinion on how to solve it.  I was pointing out that it is busted.

==========
Avi Lior
H: +1 613.831.9031
M: +1 613.355.7112