-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extended Range Options #81
Comments
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. |
@h0ru5 , Would the option identified as critical (Critical = (onum & 1) also apply to options beyond 256?
|
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? |
After discussing with some colleagues, the suggestion would be following:
|
The CoAP spec in RFC 7252 defines number ranges for options:
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
The text was updated successfully, but these errors were encountered: