Subject: [core] RFC7252 - 5.4.1 Critical/Elective

From: Achim Kraus <[email-masked]>
Date: Tue, 21 Apr 2020 18:48:47 +0200

Hi list,

I have some detail questions about:

RFC7252 - 5.4.1 Critical/Elective

Point 3:

 > Unrecognized options of class "critical" that occur in a
 > Confirmable response, or piggybacked in an Acknowledgement, MUST
 > cause the response to be rejected (Section 4.2).

"or piggybacked" "MUST" "rejected"

I have my doubts about rejecting a ACK. Is that really intended?
In my opinion, that violates the usual message sequences.

Point 2 and 4:

 > Unrecognized options of class "critical" that occur in a
 > Confirmable request MUST cause the return of a 4.02 (Bad Option)
 > response. This response SHOULD include a diagnostic payload
 > describing the unrecognized option(s) (see Section 5.5.2).

 > Unrecognized options of class "critical" that occur in a Non-
 > confirmable message MUST cause the message to be rejected
 > (Section 4.3).

My interpretation:
Point 2 addresses CON requests
Point 4 NON messages

A NON request would therefore match point 4. But why should the outcome
(response 4.02 or rejected) depend on the message type CON/NON?
Was there a reason for that? Or is my interpretation wrong?

best regards
Achim

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 21 Apr 2020 19:01:11 +0200

Hi Achim,

> In my opinion, that violates the usual message sequences.

4.2: 
   Rejecting an
   Acknowledgement or Reset message (including the case where the
   Acknowledgement carries a request or a code with a reserved class, or
   the Reset message is not Empty) is effected by silently ignoring it.

> Was there a reason for that? Or is my interpretation wrong?

4.3:
   Rejecting a Non-
   confirmable message MAY involve sending a matching Reset message, and
   apart from the Reset message the rejected message MUST be silently
   ignored.

Since Non-confirmable messages are not guaranteed to arrive, it doesn’t make a lot of sense to put a MUST mandate on what needs to be returned.
I’m not sure why we mandated the 4.02 for Confirmable; probably so there is a reliable way for a client to find out whether an option is supported.

Grüße, Carsten

---

From: Achim Kraus <[email-masked]>
Date: Tue, 21 Apr 2020 20:26:34 +0200

Hi Carsten,

thanks for your fast answers!

>     the Reset message is not Empty) is effected by silently ignoring it.

So for piggybacked that results in silently ignoring it.

> I’m not sure why we mandated the 4.02 for Confirmable; probably so there is a reliable way for a client to find out whether an option is supported.

So rejecting the NON-Request maybe considered as normal case,
and the CON-Request, maybe considered as a special case to check,
if an option is supported.

That helps a lot.

best regards
Achim

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 22 Apr 2020 12:25:03 +0200

> if an option is supported.

I find this slightly weird... There shouldn't really be any difference
between CON and NON at the request/response layer.

Klaus

---

From: Achim Kraus <[email-masked]>
Date: Wed, 22 Apr 2020 19:01:39 +0200

>> So rejecting the NON-Request maybe considered as normal case, >> and the CON-Request, maybe considered as a special case to check,>>
if an option is supported.> > I find this slightly weird... There
shouldn't really be any difference> between CON and NON at the
request/response layer.> > Klaus>
Therefore I asked "But why should the outcome (response 4.02 or
rejected) depend on the message type CON/NON?"

Anyway, it seems to be a not too big issue.
Californium got only two complains in 2 years, so I fix it according the
RFC and we will see, if new complains arrives.

Achim