RFC 7252, 5.8 Method Definitions => 4.05 (Method Not Allowed) piggybacked response

[boaks]

RFC 7252, 5.8 Method Definitions

In this section, each method is defined along with its behavior. A
request with an unrecognized or unsupported Method Code MUST generate
a 4.05 (Method Not Allowed) piggybacked response.

What should happen, if a NON request uses a unrecognized/unsupported Method Code?

I vague remember, that there is some specific in handling NON requests, but I fail to see it again.

(Related to Californium issue 2346 )

[chrysn]

Never noticed this requirement before. Given that proxies may operate across different latency domains, I don't see how this would be enforceable. (It'd effectively rule out separate responses from them.)

[boaks]

I found it again, but it wasn't about method codes.

RFC7252, 5.4.1 Options - Critical/Elective

o 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).

o 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).

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

Here CON and NON request are handled different, one with an error response, the other with a optional RST.

So, still not that sure, what we should use in case of method codes.

[boaks]

Related to issue #14

[boaks]

Mailing list:

Responses to NON with 4.02

RFC7252 - 5.4.1 Critical/Elective

(Therefore I remembered that similar discussion.)

[mrdeep1]

RFC7252 Section 4.3 goes on to say

                                                                                              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.

As this is a MAY, this does not preclude the use of a 4.02 (#14) or 4.05 for the response.

So, given that CON and TCP transport respond with 4.02 or 4.05, I do not see why NON MAY respond with a 4.02 or 4.05 for consistency across all the variants.

[boaks]

I do not see

May point was more, that for the critical options there was a explicit reference to section 4.3, here I was missing that.