12. IANA Considerations
12.1. CoAP Code Registries
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
12.1.1. Method Codes
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.
12.1.2. Response Codes
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.
12.2. CoAP Option Numbers Registry
This document defines a sub-registry for the Option Numbers used in CoAP options within the "CoRE Parameters" registry. The name of the sub-registry is "CoAP Option Numbers".
Each entry in the sub-registry must include the Option Number, the name of the option, and a reference to the option's documentation.
Initial entries in this sub-registry are as follows:
+--------+------------------+-----------+
| Number | Name | Reference |
+--------+------------------+-----------+
| 0 | (Reserved) | [RFC7252] |
| 1 | If-Match | [RFC7252] |
| 3 | Uri-Host | [RFC7252] |
| 4 | ETag | [RFC7252] |
| 5 | If-None-Match | [RFC7252] |
| 7 | Uri-Port | [RFC7252] |
| 8 | Location-Path | [RFC7252] |
| 11 | Uri-Path | [RFC7252] |
| 12 | Content-Format | [RFC7252] |
| 14 | Max-Age | [RFC7252] |
| 15 | Uri-Query | [RFC7252] |
| 17 | Accept | [RFC7252] |
| 20 | Location-Query | [RFC7252] |
| 35 | Proxy-Uri | [RFC7252] |
| 39 | Proxy-Scheme | [RFC7252] |
| 60 | Size1 | [RFC7252] |
| 128 | (Reserved) | [RFC7252] |
| 132 | (Reserved) | [RFC7252] |
| 136 | (Reserved) | [RFC7252] |
| 140 | (Reserved) | [RFC7252] |
+--------+------------------+-----------+
Table 7: CoAP Option Numbers
The IANA policy for future additions to this sub-registry is split into three tiers as follows. The range of 0..255 is reserved for options defined by the IETF (IETF Review or IESG Approval). The range of 256..2047 is reserved for commonly used options with public specifications (Specification Required). The range of 2048..64999 is for all other options including private or vendor-specific ones, which undergo a Designated Expert review to help ensure that the option semantics are defined correctly. The option numbers between 65000 and 65535 inclusive are reserved for experiments. They are not meant for vendor-specific use of any kind and MUST NOT be used in operational deployments.
+-------------+---------------------------------------+
| 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
The documentation of an Option Number should specify the semantics of an option with that number, including the following properties:
o The meaning of the option in a request.
o The meaning of the option in a response.
o Whether the option is critical or elective, as determined by the Option Number.
o Whether the option is Safe-to-Forward, and, if yes, whether it is part of the Cache-Key, as determined by the Option Number (see Section 5.4.2).
o The format and length of the option's value.
o Whether the option must occur at most once or whether it can occur multiple times.
o The default value, if any. For a critical option with a default value, a discussion on how the default value enables processing by implementations that do not support the critical option (Section 5.4.4).
12.3. CoAP Content-Formats Registry
Internet media types are identified by a string, such as "application/xml" [RFC2046]. In order to minimize the overhead of using these media types to indicate the format of payloads, this document defines a sub-registry for a subset of Internet media types to be used in CoAP and assigns each, in combination with a content- coding, a numeric identifier. The name of the sub-registry is "CoAP Content-Formats", within the "CoRE Parameters" registry.
Each entry in the sub-registry must include the media type registered with IANA, the numeric identifier in the range 0-65535 to be used for that media type in CoAP, the content-coding associated with this identifier, and a reference to a document describing what a payload with that media type means semantically.
CoAP does not include a separate way to convey content-encoding information with a request or response, and for that reason the content-encoding is also specified for each identifier (if any). If multiple content-encodings will be used with a media type, then a separate Content-Format identifier for each is to be registered. Similarly, other parameters related to an Internet media type, such as level, can be defined for a CoAP Content-Format entry.
Initial entries in this sub-registry are as follows:
+--------------------------+----------+----+------------------------+ | Media type | Encoding | ID | Reference | +--------------------------+----------+----+------------------------+ | text/plain; | - | 0 | [RFC2046] [RFC3676] | | charset=utf-8 | | | [RFC5147] | | application/link-format | - | 40 | [RFC6690] | | application/xml | - | 41 | [RFC3023] | | application/octet-stream | - | 42 | [RFC2045] [RFC2046] | | application/exi | - | 47 | [REC-exi-20140211] | | application/json | - | 50 | [RFC7159] | +--------------------------+----------+----+------------------------+
Table 9: CoAP Content-Formats
The identifiers between 65000 and 65535 inclusive are reserved for experiments. They are not meant for vendor-specific use of any kind and MUST NOT be used in operational deployments. The identifiers between 256 and 9999 are reserved for future use in IETF specifications (IETF Review or IESG Approval). All other identifiers are Unassigned.
Because the namespace of single-byte identifiers is so small, the IANA policy for future additions in the range 0-255 inclusive to the sub-registry is "Expert Review" as described in [RFC5226]. The IANA policy for additions in the range 10000-64999 inclusive is "First Come First Served" as described in [RFC5226]. This is summarized in the following table.
+-------------+---------------------------------------+
| Range | Registration Procedures |
+-------------+---------------------------------------+
| 0-255 | Expert Review |
| 256-9999 | IETF Review or IESG Approval |
| 10000-64999 | First Come First Served |
| 65000-65535 | Experimental use (no operational use) |
+-------------+---------------------------------------+
Table 10: CoAP Content-Formats: Registration Procedures
In machine-to-machine applications, it is not expected that generic Internet media types such as text/plain, application/xml or application/octet-stream are useful for real applications in the long term. It is recommended that M2M applications making use of CoAP request new Internet media types from IANA indicating semantic information about how to create or parse a payload. For example, a Smart Energy application payload carried as XML might request a more specific type like application/se+xml or application/se-exi.
12.4. URI Scheme Registration
This document contains the request for the registration of the Uniform Resource Identifier (URI) scheme "coap". The registration request complies with [RFC4395].
URI scheme name. coap
Status. Permanent.
URI scheme syntax. Defined in Section 6.1 of [RFC7252].
URI scheme semantics. The "coap" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP). The resources can be located by contacting the governing CoAP server and operated on by sending CoAP requests to the server. This scheme can thus be compared to the "http" URI scheme [RFC2616]. See Section 6 of [RFC7252] for the details of operation.
Encoding considerations. The scheme encoding conforms to the encoding rules established for URIs in [RFC3986], i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding.
Applications/protocols that use this URI scheme name. The scheme is used by CoAP endpoints to access CoAP resources.
Interoperability considerations. None.
Security considerations. See Section 11.1 of [RFC7252].
Contact. IETF Chair [email protected]
Author/Change controller. IESG [email protected]
References. [RFC7252]
12.5. Secure URI Scheme Registration
This document contains the request for the registration of the Uniform Resource Identifier (URI) scheme "coaps". The registration request complies with [RFC4395].
URI scheme name. coaps
Status. Permanent.
URI scheme syntax. Defined in Section 6.2 of [RFC7252].
URI scheme semantics. The "coaps" URI scheme provides a way to identify resources that are potentially accessible over the Constrained Application Protocol (CoAP) using Datagram Transport Layer Security (DTLS) for transport security. The resources can be located by contacting the governing CoAP server and operated on by sending CoAP requests to the server. This scheme can thus be compared to the "https" URI scheme [RFC2616]. See Section 6 of [RFC7252] for the details of operation.
Encoding considerations. The scheme encoding conforms to the encoding rules established for URIs in [RFC3986], i.e., internationalized and reserved characters are expressed using UTF-8-based percent-encoding.
Applications/protocols that use this URI scheme name. The scheme is used by CoAP endpoints to access CoAP resources using DTLS.
Interoperability considerations. None.
Security considerations. See Section 11.1 of [RFC7252].
Contact. IETF Chair [email protected]
Author/Change controller. IESG [email protected]
References. [RFC7252]
12.6. Service Name and Port Number Registration
One of the functions of CoAP is resource discovery: a CoAP client can ask a CoAP server about the resources offered by it (see Section 7). To enable resource discovery just based on the knowledge of an IP address, the CoAP port for resource discovery needs to be standardized.
IANA has assigned the port number 5683 and the service name "coap", in accordance with [RFC6335].
Besides unicast, CoAP can be used with both multicast and anycast.
Service Name. coap
Transport Protocol. udp
Assignee. IESG [email protected]
Contact. IETF Chair [email protected]
Description. Constrained Application Protocol (CoAP)
Reference. [RFC7252]
Port Number. 5683
12.7. Secure Service Name and Port Number Registration
CoAP resource discovery may also be provided using the DTLS-secured CoAP "coaps" scheme. Thus, the CoAP port for secure resource discovery needs to be standardized.
IANA has assigned the port number 5684 and the service name "coaps", in accordance with [RFC6335].
Besides unicast, DTLS-secured CoAP can be used with anycast.
Service Name. coaps
Transport Protocol. udp
Assignee. IESG [email protected]
Contact. IETF Chair [email protected]
Description. DTLS-secured CoAP
Reference. [RFC7252]
Port Number. 5684
12.8. Multicast Address Registration
Section 8, "Multicast CoAP", defines the use of multicast. IANA has assigned the following multicast addresses for use by CoAP nodes:
IPv4 -- "All CoAP Nodes" address 224.0.1.187, from the "IPv4 Multicast Address Space Registry". As the address is used for discovery that may span beyond a single network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771).
IPv6 -- "All CoAP Nodes" address FF0X::FD, from the "IPv6 Multicast Address Space Registry", in the "Variable Scope Multicast Addresses" space (RFC 3307). Note that there is a distinct multicast address for each scope that interested CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local scopes only.