Extended Range Options about canopus HOT 4 OPEN

Thanks for the hint.

I just went through a major refactoring and now i'm fixing all my broken test cases.

I'll need to comb thru the CoAP specs again and start implementing/testing the fine details such as the one you've mentioned here.

from canopus.

@h0ru5 , Would the option identified as critical (Critical = (onum & 1) also apply to options beyond 256?

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

from canopus.

The problem is: if the option is recognized or not is actually something that can be answered by the user of your library.

I would recommend to just document it that if there is a critical option with a number >255 where the application does not know how to handle, then the application should return the error, but not do any automated "Bad Option" replies in the library.

@mkovatsc : given your experience in CoAP, maybe you could comment how you would recommend handling critical non-standard Options for a library?

from canopus.

After discussing with some colleagues, the suggestion would be following:

• to insert a function parallel to BytesToMessage (as Golang does not support optional parameters)
• that has an additional parameter to accept a callback of type func(*CoapMessage msg, OptionCode code, []byte value) bool that gets called for every received extended Option allows users to handle custom/extended options.
• The boolean return can indicate whether on not the option was handled

from canopus.