pub enum OptionMustBeProcessed {
Yes,
No,
}Expand description
§Critical/Elective
generated from RFC7252 section 5.4.1
Options fall into one of two classes: “critical” or “elective”. The difference between these is how an option unrecognized by an endpoint is handled:
o Upon reception, unrecognized options of class “elective” MUST be silently ignored.
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).
Note that, whether critical or elective, an option is never “mandatory” (it is always optional): these rules are defined in order to enable implementations to stop processing options they do not understand or implement.
Critical/elective rules apply to non-proxying endpoints. A proxy processes options based on Unsafe/Safe-to-Forward classes as defined in Section 5.7.
Variants§
Yes
This option must be processed, and a response that ignores it will be rejected.
Corresponds to the option being “critical” in strict CoAP terms
No
This option does not need to be processed, and a response that ignores it will be processed anyway.
Corresponds to the option being “elective” in strict CoAP terms
Trait Implementations§
Source§impl Clone for OptionMustBeProcessed
impl Clone for OptionMustBeProcessed
Source§fn clone(&self) -> OptionMustBeProcessed
fn clone(&self) -> OptionMustBeProcessed
1.0.0 · Source§fn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source. Read more