Expand description
CoAP Code Registries
generated from RFC7252 section 12.1
This document defines two sub-registries for the values of the Code field in the CoAP header within the “Constrained RESTful Environments (CoRE) Parameters” registry, hereafter referred to as the “CoRE Parameters” registry.
Values in the two sub-registries are eight-bit values notated as three decimal digits c.dd separated by a period between the first and the second digit; the first digit c is between 0 and 7 and denotes the code class; the second and third digits dd denote a decimal number between 00 and 31 for the detail.
All Code values are assigned by sub-registries according to the following ranges:
0.00 Indicates an Empty message (see Section 4.1).
0.01-0.31 Indicates a request. Values in this range are assigned by
the "CoAP Method Codes" sub-registry (see Section 12.1.1).
1.00-1.31 Reserved
2.00-5.31 Indicates a response. Values in this range are assigned by
the "CoAP Response Codes" sub-registry (see
Section 12.1.2).
6.00-7.31 Reserved
RFC7252 Section 12.1.1 Method Codes
## Method Codes [_generated from RFC7252 section 12.1.1_](https://datatracker.ietf.org/doc/html/rfc7252#section-12.1.1)The name of the sub-registry is “CoAP Method Codes”.
Each entry in the sub-registry must include the Method Code in the range 0.01-0.31, the name of the method, and a reference to the method’s documentation.
Initial entries in this sub-registry are as follows:
+------+--------+-----------+
| Code | Name | Reference |
+------+--------+-----------+
| 0.01 | GET | [RFC7252] |
| 0.02 | POST | [RFC7252] |
| 0.03 | PUT | [RFC7252] |
| 0.04 | DELETE | [RFC7252] |
+------+--------+-----------+
Table 5: CoAP Method Codes
All other Method Codes are Unassigned.
The IANA policy for future additions to this sub-registry is “IETF Review or IESG Approval” as described in [RFC5226].
The documentation of a Method Code should specify the semantics of a request with that code, including the following properties:
o The Response Codes the method returns in the success case.
o Whether the method is idempotent, safe, or both.
RFC7252 Section 12.1.2 Response Codes
## Response Codes [_generated from RFC7252 section 12.1.2_](https://datatracker.ietf.org/doc/html/rfc7252#section-12.1.2)The name of the sub-registry is “CoAP Response Codes”.
Each entry in the sub-registry must include the Response Code in the range 2.00-5.31, a description of the Response Code, and a reference to the Response Code’s documentation.
Initial entries in this sub-registry are as follows:
+------+------------------------------+-----------+
| Code | Description | Reference |
+------+------------------------------+-----------+
| 2.01 | Created | [RFC7252] |
| 2.02 | Deleted | [RFC7252] |
| 2.03 | Valid | [RFC7252] |
| 2.04 | Changed | [RFC7252] |
| 2.05 | Content | [RFC7252] |
| 4.00 | Bad Request | [RFC7252] |
| 4.01 | Unauthorized | [RFC7252] |
| 4.02 | Bad Option | [RFC7252] |
| 4.03 | Forbidden | [RFC7252] |
| 4.04 | Not Found | [RFC7252] |
| 4.05 | Method Not Allowed | [RFC7252] |
| 4.06 | Not Acceptable | [RFC7252] |
| 4.12 | Precondition Failed | [RFC7252] |
| 4.13 | Request Entity Too Large | [RFC7252] |
| 4.15 | Unsupported Content-Format | [RFC7252] |
| 5.00 | Internal Server Error | [RFC7252] |
| 5.01 | Not Implemented | [RFC7252] |
| 5.02 | Bad Gateway | [RFC7252] |
| 5.03 | Service Unavailable | [RFC7252] |
| 5.04 | Gateway Timeout | [RFC7252] |
| 5.05 | Proxying Not Supported | [RFC7252] |
+------+------------------------------+-----------+
Table 6: CoAP Response Codes
The Response Codes 3.00-3.31 are Reserved for future use. All other Response Codes are Unassigned.
The IANA policy for future additions to this sub-registry is “IETF Review or IESG Approval” as described in [RFC5226].
The documentation of a Response Code should specify the semantics of a response with that code, including the following properties:
o The methods the Response Code applies to.
o Whether payload is required, optional, or not allowed.
o The semantics of the payload. For example, the payload of a 2.05 (Content) response is a representation of the target resource; the payload in an error response is a human-readable diagnostic payload.
o The format of the payload. For example, the format in a 2.05 (Content) response is indicated by the Content-Format Option; the format of the payload in an error response is always Net-Unicode text.
o Whether the response is cacheable according to the freshness model.
o Whether the response is validatable according to the validation model.
o Whether the response causes a cache to mark responses stored for the request URI as not fresh.
Examples
use toad_msg::Code;
assert_eq!(Code { class: 2,
detail: 5 }.to_string(),
"2.05".to_string());
Fields
class: u8
The “class” of message codes identify it as a request or response, and provides the class of response status:
class | meaning |
---|---|
0 | Message is a request |
2 | Message is a success response |
4 | Message is a client error response |
5 | Message is a server error response |
detail: u8
2-digit integer (range [0, 32)
) that provides granular information about the response status.
Will always be 0
for requests.
Implementations
sourceimpl Code
impl Code
sourcepub const fn new(class: u8, detail: u8) -> Self
pub const fn new(class: u8, detail: u8) -> Self
Create a new Code
use toad_msg::Code;
let content = Code::new(2, 05);
sourcepub fn to_human(&self) -> [char; 4]
pub fn to_human(&self) -> [char; 4]
Get the human string representation of a message code
Returns
A char
array
This is to avoid unnecessary heap allocation,
you can create a String
with FromIterator::<String>::from_iter
,
or if the alloc
feature of toad
is enabled there is a ToString
implementation provided for Code.
use toad_msg::Code;
let code = Code { class: 2,
detail: 5 };
let chars = code.to_human();
let string = String::from_iter(chars);
assert_eq!(string, "2.05".to_string());
sourcepub fn kind(&self) -> CodeKind
pub fn kind(&self) -> CodeKind
Get whether this code is for a request, response, or empty message
use toad_msg::{Code, CodeKind};
let empty: Code = Code::new(0, 0);
assert_eq!(empty.kind(), CodeKind::Empty);
let req = Code::new(1, 1); // GET
assert_eq!(req.kind(), CodeKind::Request);
let resp = Code::new(2, 5); // OK CONTENT
assert_eq!(resp.kind(), CodeKind::Response);
Trait Implementations
sourceimpl Ord for Code
impl Ord for Code
1.21.0 · sourcefn max(self, other: Self) -> Self
fn max(self, other: Self) -> Self
1.21.0 · sourcefn min(self, other: Self) -> Self
fn min(self, other: Self) -> Self
1.50.0 · sourcefn clamp(self, min: Self, max: Self) -> Selfwhere
Self: PartialOrd<Self>,
fn clamp(self, min: Self, max: Self) -> Selfwhere
Self: PartialOrd<Self>,
sourceimpl PartialOrd<Code> for Code
impl PartialOrd<Code> for Code
sourcefn partial_cmp(&self, other: &Code) -> Option<Ordering>
fn partial_cmp(&self, other: &Code) -> Option<Ordering>
1.0.0 · sourcefn le(&self, other: &Rhs) -> bool
fn le(&self, other: &Rhs) -> bool
self
and other
) and is used by the <=
operator. Read more