Extended Range Options

[h0ru5]

The CoAP spec in RFC 7252 defines number ranges for options:

          +-------------+---------------------------------------+
          |       Range | Registration Procedures               |
          +-------------+---------------------------------------+
          |       0-255 | IETF Review or IESG Approval          |
          |    256-2047 | Specification Required                |
          |  2048-64999 | Expert Review                         |
          | 65000-65535 | Experimental use (no operational use) |
          +-------------+---------------------------------------+

           Table 8: CoAP Option Numbers: Registration Procedures

Other CoAP libs (e.g. californium in Java) allow you to retrieve these unkwon options just handling their number and value as bytes. It enables you to also use extended options which is crucial e.g. when mapping between coap and HTTP.

To use this, it would just require some small tweaks in the option handling as currently the delta-encoding is geared just towards a single byte and options that are not in the RFC are ignored.

see also: https://tools.ietf.org/html/rfc7252#section-3.1

[zubairhamed]

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.

[zubairhamed]

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

[h0ru5]

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?

[h0ru5]

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