Subject: [core] ack message format in confirmable notifications

From: Matthieu Vial <[email-masked]>
Date: Fri, 6 Nov 2015 09:22:04 +0100

Hi all,

There is no example of confirmable notification in RFC7641 and I would like
to clarify the format of the ack message sent by the coap client.

Basically, an ack message to a confirmable notification has no content and
no REST semantics so the code is 0.00.

According to https://tools.ietf.org/html/rfc7252#section-3:
"As a special case, Code 0.00 indicates an Empty message."

So this message should be an empty message.

According to https://tools.ietf.org/html/rfc7252#section-4.1 an empty
message is built as :

"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."

If my understanding of the RFC is right, as a CoAP implementer, do you
enforce 0-length token on server side. Is it something you check in
plugtests ? Is it something we want to enforce in an implementation ?

Thanks,
Matthieu

---

From: Oliver Kleine <[email-masked]>
Date: Fri, 6 Nov 2015 14:26:28 +0100

Hello Matthieu,

according to section 1.2 of RFC 7252 an empty message only contains the 
4-byte header. The token length is a part of the header, the token 
itself is not. This implies a token length of 0 for empty messages just 
because there is no room left for a token of length > 0.

Thus, empty messages with token length > 0 may be considered malformed, 
as a token length > 0 implies a message larger than 4 byte.

Furthermore, on the "semantic" level, there is a difference between a 
token of length 0 in empty and non-empty messages. In non-empty messages 
the token (incl. the one of size 0) is basically used to relate requests 
and responses to each other (see [1] for the plugtests).

This does not hold for empty messages. In empty messages, the token has 
no semantic meaning at all. I guess, that's why there is no plugtest to 
check for token lengths in empty messages.

Best regards,
Oliver

[1] http://rawgit.com/cabo/td-coap3/master/base.html (CORE_10, 11, 12)

On 06.11.2015 09:22, Matthieu Vial wrote:
> Hi all,
>
> There is no example of confirmable notification in RFC7641 and I would
> like to clarify the format of the ack message sent by the coap client.
>
> Basically, an ack message to a confirmable notification has no content
> and no REST semantics so the code is 0.00.
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

-- 

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
     INSTITUT FÜR TELEMATIK

     Ratzeburger Allee 160
     23538 Lübeck

     Tel +49 451 500 5396
     Fax +49 451 500 5382
     [email-masked]

     https://www.itm.uni-luebeck.de/people/kleine

---

From: Matthieu Vial <[email-masked]>
Date: Fri, 6 Nov 2015 15:01:15 +0100

Hi Oliver,

Thanks for your answer.
As I understand your comment, a token length>0 in a notification ack is
malformed but most implementations just don't care. It seems like even if
the RFC says the length MUST be 0 most implement it as SHOULD be 0. Is that
right ?

BR,
Matthieu

On Fri, Nov 6, 2015 at 2:26 PM, Oliver Kleine <[email-masked]>
wrote:

> 4-byte header. The token length is a part of the header, the token itself
> is not. This implies a token length of 0 for empty messages just because
> there is no room left for a token of length > 0.
>
> Thus, empty messages with token length > 0 may be considered malformed, as
> a token length > 0 implies a message larger than 4 byte.
>
> This does not hold for empty messages. In empty messages, the token has no
> semantic meaning at all. I guess, that's why there is no plugtest to check
> for token lengths in empty messages.
>
> Best regards,
> Oliver
>

---

From: Oliver Kleine <[email-masked]>
Date: Fri, 6 Nov 2015 19:22:29 +0100

Hi Matthieu,

some implementations (maybe most of them) accept and proceed empty 
messages with a token length > 0 (and ignore the token, if any).

This is to follow Postels robustness principle (from RFC 793): "Be 
conservative in what you do, be liberal in what you accept from 
others.", i.e. do not (knowingly) send malformed messages but be 
prepared to receive and handle malformed messages from others.

Best,
Oliver

On 06.11.2015 15:01, Matthieu Vial wrote:
> malformed but most implementations just don't care. It seems like even
> if the RFC says the length MUST be 0 most implement it as SHOULD be 0.
> Is that right ?
>
> BR,
> Matthieu
>
> On Fri, Nov 6, 2015 at 2:26 PM, Oliver Kleine <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hello Matthieu,
>
>     according to section 1.2 of RFC 7252 an empty message only contains
>     the 4-byte header. The token length is a part of the header, the
>     token itself is not. This implies a token length of 0 for empty
>     messages just because there is no room left for a token of length > 0.
>
>     Thus, empty messages with token length > 0 may be considered
>     malformed, as a token length > 0 implies a message larger than 4 byte.
>
>     Furthermore, on the "semantic" level, there is a difference between
>     a token of length 0 in empty and non-empty messages. In non-empty
>     messages the token (incl. the one of size 0) is basically used to
>     relate requests and responses to each other (see [1] for the plugtests).
>
>     This does not hold for empty messages. In empty messages, the token
>     has no semantic meaning at all. I guess, that's why there is no
>     plugtest to check for token lengths in empty messages.
>
>     Best regards,
>     Oliver
>
>         [email-masked] <mailto:[email-masked]>
>          Tel +49 451 500 5396 <tel:%2B49%20451%20500%205396>
>          Fax +49 451 500 5382 <tel:%2B49%20451%20500%205382>
>     [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>

-- 

Oliver Kleine, M.Sc.

UNIVERSITÄT ZU LÜBECK
     INSTITUT FÜR TELEMATIK

     Ratzeburger Allee 160
     23538 Lübeck

     Tel +49 451 500 5396
     Fax +49 451 500 5382

---

From: Robert Cragie <[email-masked]>
Date: Fri, 6 Nov 2015 21:40:51 +0000

I think implementations should really drop messages with Empty code where
the token length is not equal to 0 or the message size is not 4 bytes.
However, I guess it depends what you mean by "accept and proceed" in the
context of dropping messages. As long as the semantic meaning of the Empty
code is processed, then it won't "proceed" much anyway so whether there is
any additional token or even payload is probably moot.

Note the robustness principle is not about handling malformed packets. It
is about handling valid packets formed in a way you wouldn't send yourself.
Malformed (i.e. invalid) packets must be dropped and typically at the first
point of parsing where it is considered malformed.

Robert

On 6 November 2015 at 18:22, Oliver Kleine <[email-masked]>
wrote:

> conservative in what you do, be liberal in what you accept from others.",
> i.e. do not (knowingly) send malformed messages but be prepared to receive
> and handle malformed messages from others.
>
> Best,
> Oliver
>

---

From: "weigengyu" <[email-masked]>
Date: Mon, 9 Nov 2015 10:10:43 +0800

Hi Robert and Oliver, 

By RFC7252, the ACK with Empty resopnse of CON should be 4 byte. 
It is a malformed packet if the token length is not ZERO when an ACK message with Empty response.
   
But, there were arguments to have the Empty response with the token of request which is in preceeding. 
Some implementations accept the empty response with token (the ACK message sige > 4) is rational, 
as it is easy to directly match the request and the response. 

If an ACK with ZERO token lenth is received, for matching the request and response the sender needs to keep the mapping of request token and the message ID. 
After receiving an ACK with ZERO token length, the sender expects and waits for a separate response of the request token. 

Regards,

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

From: Robert Cragie 
Sent: Saturday, November 07, 2015 5:40 AM
To: Oliver Kleine 
Cc: mailto:[email-masked] 
Subject: Re: [core] ack message format in confirmable notifications

I think implementations should really drop messages with Empty code where the token length is not equal to 0 or the message size is not 4 bytes. However, I guess it depends what you mean by "accept and proceed" in the context of dropping messages. As long as the semantic meaning of the Empty code is processed, then it won't "proceed" much anyway so whether there is any additional token or even payload is probably moot. 

Note the robustness principle is not about handling malformed packets. It is about handling valid packets formed in a way you wouldn't send yourself. Malformed (i.e. invalid) packets must be dropped and typically at the first point of parsing where it is considered malformed.

Robert

On 6 November 2015 at 18:22, Oliver Kleine <[email-masked]> wrote:

  Hi Matthieu,

  some implementations (maybe most of them) accept and proceed empty messages with a token length > 0 (and ignore the token, if any).

  This is to follow Postels robustness principle (from RFC 793): "Be conservative in what you do, be liberal in what you accept from others.", i.e. do not (knowingly) send malformed messages but be prepared to receive and handle malformed messages from others.

  Best,
  Oliver

    Hi Oliver,

    Thanks for your answer.

    BR,
    Matthieu

        Hello Matthieu,

        Best regards,
        Oliver

            Hi all,

            There is no example of confirmable notification in RFC7641 and I
            would
            like to clarify the format of the ack message sent by the coap
            client.

            Basically, an ack message to a confirmable notification has no
            content
            and no REST semantics so the code is 0.00.

            According to https://tools.ietf.org/html/rfc7252#section-4.1 an
            empty
            message is built as :

            "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."

            If my understanding of the RFC is right, as a CoAP implementer,
            do you
            enforce 0-length token on server side. Is it something you check in
            plugtests ? Is it something we want to enforce in an
            implementation ?

            Thanks,
            Matthieu

        --

        Oliver Kleine, M.Sc.

        UNIVERSITÄT ZU LÜBECK
             INSTITUT FÜR TELEMATIK

             Ratzeburger Allee 160
             23538 Lübeck

  -- 

  Oliver Kleine, M.Sc.

  UNIVERSITÄT ZU LÜBECK
      INSTITUT FÜR TELEMATIK

      Ratzeburger Allee 160
      23538 Lübeck

      Tel +49 451 500 5396
      Fax +49 451 500 5382

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

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 09 Nov 2015 17:52:54 +0800

> message with Empty response.

Indeed.

> request which is in preceeding.

But that is not how CoAP is defined.  So I don't know why this is coming up.

> as it is easy to directly match the request and the response.

ACK is on the message layer, and message layer matching is by the
message ID.

> If an ACK with ZERO token lenth is received, for matching the request
> and response the sender needs to keep the mapping of request token and
> the message ID.

The token length is not the interesting point here.
An Empty message has Code 0.00; this distinguishes an Empty ACK from an
ACK with a piggybacked response.  (A piggybacked response still has
token length 0 if the request used a token of zero length.)

> After receiving an ACK with ZERO token length, the sender expects and
> waits for a separate response of the request token.

=>

After receiving an ACK with code 0.00, the sender expects and
waits for a separate response that echoes the request token.

Grüße, Carsten

---

From: Matthieu Vial <[email-masked]>
Date: Mon, 9 Nov 2015 13:28:03 +0100

Hi Carsten,

I agree for a separate response. But what about an ACK in return to a CON
notification ? Some implementations include the observe token in the ACK.
Is it considered a valid message ?

Thanks,
Matthieu

---

From: "weigengyu" <[email-masked]>
Date: Mon, 9 Nov 2015 20:52:06 +0800

Hi Matthieu,

It is a malformed message by RFC7252 currently, as I see.
And I think that it needs concerning.

Regards, 

Gengyu WEI

From: Matthieu Vial 
Sent: Monday, November 09, 2015 8:28 PM
To: Carsten Bormann 
Cc: weigengyu ; mailto:[email-masked] 
Subject: Re: [core] ack message format in confirmable notifications

Hi Carsten, 

I agree for a separate response. But what about an ACK in return to a CON notification ? Some implementations include the observe token in the ACK. Is it considered a valid message ?

Thanks,
Matthieu

  Indeed.

  =>

  Grüße, Carsten