RFC 7252

The Constrained Application Protocol (CoAP)

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.

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.

+-------------+---------------------------------------+
| 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 <chair@ietf.org>
Author/Change controller.
IESG <iesg@ietf.org>
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 <chair@ietf.org>
Author/Change controller.
IESG <iesg@ietf.org>
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 <iesg@ietf.org>
Contact.
IETF Chair <chair@ietf.org>
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 <iesg@ietf.org>
Contact.
IETF Chair <chair@ietf.org>
Description.
DTLS-secured CoAP
Reference.
[RFC7252]
Port Number.
5684