]> Updates to the IANA Registration Procedures for Constrained Application Protocol (CoAP) Content-Formats Linaro
thomas.fossati@linaro.org
IoTconsultancy.nl
esko.dijk@iotconsultancy.nl
WIT core IANA registration update CoAP Content-Format This document updates RFC 7252 by modifying the registration procedures for the "CoAP Content-Formats" IANA registry, within the "Constrained RESTful Environments (CoRE) Parameters" registry group. This document also introduces a new column, "Media Type", to the registry. Furthermore, this document reserves Content-Format identifiers 64998 and 64999 for use in documentation.
Introduction describes the registration procedures for the "CoAP Content-Formats" IANA registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group . (Note that the columns of this registry have been revised according to .) In particular, it defines the rules for obtaining Constrained Application Protocol (CoAP) Content-Format identifiers from the "IETF Review or IESG Approval" range of the registry (256-9999) as well as from the "First Come First Served" (FCFS) range of the registry (10000-64999). For the FCFS range, these rules do not involve the designated expert and are managed solely by IANA personnel to finalize the registration. Unfortunately, the rules do not explicitly require checking that the combination of Content-Type (i.e., Media Type with optional parameters) and Content Coding associated with the requested CoAP Content-Format is semantically valid. This task is generally non-trivial, requires knowledge from multiple documents and technologies, and should not be solely demanded from the registrar. This lack of guidance may engender confusion in both the registering party and the registrar, and it has already led to erroneous registrations. This document updates by modifying the registration procedures for the "CoAP Content-Formats" registry to mitigate the risk of unintentional or malicious errors. These updates amend the different ranges of the registry, introduce a review procedure to be performed for most ranges of the registry, and allow the registration of temporary Content-Format identifiers. This document also introduces a new column, "Media Type", to the registry. Furthermore, this document reserves Content-Format identifiers 64998 and 64999 for use in documentation.
Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the terms "Media Type", "Content Coding", "Content-Type", and "Content Format" as defined in . In this document, those terms are fully capitalized.
Security Considerations This document updates the registration procedures of CoAP Content-Formats to reduce the chances of malicious manipulation of the associated registry. Otherwise, it does not change the Security Considerations of .
IANA Considerations This document updates the IANA procedures defined in for registering CoAP Content-Formats as described in . It also adds a new note concerning temporary registrations () and reserves Content-Format IDs 64998 and 64999 for documentation ().
CoAP Content-Formats Registry This section and its subsections replace . Internet Media Types are identified by a string, such as "application/xml" . In order to minimize the overhead of using Media Types to indicate the format of payloads, has defined a registry for a subset of Internet Media Types to be used in CoAP and assigned each, in combination with a Content Coding, a numeric identifier. The name of the registry is "CoAP Content-Formats", within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Each entry in the registry must include the Content Type, the Content Coding (if any), the Media Type registered with IANA, the numeric identifier in the range 0-65535 to be used for that Media Type in CoAP, 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 Coding information with a request or response; for that reason, the Content Coding (if any) is also specified for each identifier. If multiple Content Codings 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 can be defined for a CoAP Content-Format entry. The registration procedures for CoAP Content-Formats are described in . Registration Procedures for CoAP Content-Formats
Range Registration Procedures Note
0-255 Expert Review Review procedure described in RFC 9876, .
256-9999 IETF Review with Expert Review or IESG Approval with Expert Review Review procedure described in RFC 9876, .
10000-19999 Expert Review Review procedure described in RFC 9876, .
20000-32999 First Come First Served FCFS is allowed if the registration has no parameters, the registration has an empty Content Coding, the Media Type is not yet used in this registry, and the Media Type is registered (or approved for registration) in the "Media Types" registry .
33000-64997 Expert Review Review procedure described in RFC 9876, .
64998-64999 Reserved for Documentation
65000-65535 Experimental Use No operational use
Because the namespace of single-byte identifiers is so small, the IANA policy for additions in the range 0-255 inclusive to the registry is "Expert Review" as described in Section of RFC 8126. For the handling of temporary allocations within the 0-255 range, see also . The 256-9999 range has registration procedures requiring "IETF Review with Expert Review" or "IESG Approval with Expert Review". In particular:
  • All assignments according to "IETF Review with Expert Review" are made on an "IETF Review" basis per Section of RFC 8126 with "Expert Review" additionally required per Section of RFC 8126. The procedure for early IANA allocation of Standards Track code points defined in also applies. When such a procedure is used, IANA will ask the designated expert(s) to approve the early allocation before registration. In addition, working group chairs are encouraged to consult the expert(s) early during the process outlined in .
  • All assignments according to "IESG Approval with Expert Review" are made on an "IESG Approval" basis per Section of RFC 8126 with "Expert Review" additionally required per Section of RFC 8126.
The registration policy for the 10000-19999 and 33000-64997 ranges is "Expert Review", following the procedure described in . The registration policy for the 20000-32999 range is FCFS. A registration request for this range must consist solely of a registered Media Type name in the "Content Type" field, without any parameter names or "Content Coding", and the Media Type must not have been used in this registry yet. If the criteria do not apply, a registration for a different range (which requires "Expert Review") can be requested. 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. In machine-to-machine (M2M) 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 Concise Binary Object Representation (CBOR) might request a more specific type like application/se+cbor.
Temporary Content-Format Registrations This section clarifies that the "CoAP Content-Formats" registry allows temporary registrations within the 0-64997 range. A temporary registration may be created, for example, by an IANA early allocation action . If the referenced Media Type is provisional (that is, included in the "Provisional Standard Media Type Registry" ), then a created registration is always temporary. A temporary registration is marked as such by IANA in the corresponding registry entry. Once the required registration procedure (defined in ) for the temporary ID has successfully completed, and the referenced Media Type is included in the "Media Types" registry , IANA must remove any indication about the temporary nature of the registration so that the entry becomes permanent. If a temporary registration does not successfully complete the registration procedure, IANA must remove the entry and set the Content-Format ID value back to "Unassigned". This may happen, for example, when an Internet-Draft requesting a Content-Format ID is abandoned. If a temporary registration (in any range) refers to a provisional Media Type that is abandoned, IANA must remove the entry and set the Content-Format ID value back to "Unassigned". Note that in the 10000-64997 range, the abandonment of a document requesting a Content-Format ID does not cause an entry to be removed. That is because the required registration procedure for this range does not require completion of any standards process, nor does it require a registering document. Temporary registrations within the 0-255 range are exempt from the formal renewal process outlined in . Specifically, IANA will not monitor the removal of registrations in this range. Instead, the designated experts direct IANA to carry out this task.
Addition of the Media Type Column to the Registry To assist users of the "CoAP Content-Formats" registry in finding detailed information about the Media Type associated with each CoAP Content-Format, and to ensure that a Media Type exists before a new entry can be registered, IANA has added the new column "Media Type" to the registry. This new column is placed to the right of the existing "Content Type" column. The "Media Type" field for each entry lists the (base) Media Type name and provides a hyperlink to registration information for that Media Type as recorded by IANA. If the Media Type is provisional, the hyperlink points to the "Provisional Standard Media Type Registry" . If a provisional Media Type becomes a permanent Media Type, IANA must update the "Media Type" field in the associated registry entries to ensure the hyperlink directs to the registration information for that Media Type. In a registration request, the requester does not need to fill out the "Media Type" field separately, as the necessary information is already provided in the "Content Type" field of the request.
Expert Review Procedure The designated expert is instructed to perform the "Expert Review", as described by the following checklist:
  1. The combination of Content-Type and Content Coding for which the registration is requested must not be already present in the "CoAP Content-Formats" registry.
  2. The Media Type associated with the requested Content-Format must be either registered in the "Media Types" registry or approved for registration. Alternatively, it may be listed in the "Provisional Standard Media Type Registry" . The use of provisional standard Media Types is only permitted for Content-Format identifiers within the ranges of 0-255 and 256-9999.
  3. The optional parameter names must have been defined in association with the Media Type, and any parameter values associated with such parameter names must be as permitted.
  4. The Content Type must be in the preferred format defined in .
  5. If a Content Coding is specified, it must exist (or must have been approved for registration) in the "HTTP Content Coding Registry" within the "Hypertext Transfer Protocol (HTTP) Parameters" registry group .
For the 0-255 range, in addition to the checks described above, the designated expert is instructed to also evaluate the requested code point concerning the limited availability of the 1-byte code point space. For the ranges 256-9999, 10000-19999, and 33000-64997, a similar criterion may also apply where combinations of Media Type parameters and Content Coding choices consume considerable code point space.
Preferred Format for the Content Type Field This section defines the preferred string format for including a requested Content Type in the "CoAP Content-Formats" registry. During the review process, the designated expert(s) or IANA may rewrite a requested Content Type into this preferred string format before approval. The preferred string format is as defined in and follows these rules:
  1. For any case-insensitive elements, lowercase characters are used.
  2. Parameter values are only quoted if the value is such that it requires use of a quoted-string per . Otherwise, a parameter value is included unquoted.
  3. A single semicolon character without any adjacent whitespace characters is used as the separator between the Media Type and parameters.
Examples of Invalid Registration Requests This section provides examples of registration requests for the "CoAP Content-Formats" registry that are invalid but would be approved under the procedure defined in . The checklist defined in should prevent any of these attempts from succeeding. These examples serve as a representative, but not exhaustive, sample to train the designated expert's eye on invalid registration attempts. All the example registration requests use two CoAP Content-Format identifiers: 64998 and 64999.
The Media Type is Unknown The registrant requests an FCFS Content-Format ID for an unknown Media Type: Attempt at Registering Content-Format for an Unknown Media Type
Content Type Content Coding ID
application/unknown+cbor - 64999
The Media Type Parameter is Unknown The registrant requests an FCFS Content-Format ID for an existing Media Type with an unknown parameter: Attempt at Registering Content-Format for a Media Type with an Unknown Parameter
Content Type Content Coding ID
application/cose;unknown-parameter=1 - 64999
The Media Type Parameter Value is Invalid The registrant requests an FCFS Content-Format ID for an existing Media Type with an invalid parameter value: Attempt at Registering Content-Format for a Media Type with an Invalid Parameter Value
Content Type Content Coding ID
application/cose;cose-type=invalid - 64999
The Content Coding is Unknown The registrant requests an FCFS Content-Format ID for an existing Media Type with an unknown Content Coding: Attempt at Registering Content-Format with Unknown Content Coding
Content Type Content Coding ID
application/senml+cbor inflate 64999
Duplicate Entry with Default Media Type Parameters The registrant requests an FCFS Content-Format ID for a Media Type that includes a parameter set to its default value, while a (hypothetical) Content-Format ID 64998 is already registered for this Media Type without that parameter. As a result, this could lead to the creation of two separate Content-Format IDs for the same "logical" entry. Attempt at Registering an Equivalent Logical Entry with a Different Content-Format ID (1)
Content Type Content Coding ID
application/my - 64998
application/my;parameter=default - 64999
Duplicate Entry with Default Content Coding The registrant requests an FCFS Content-Format ID for the "identity" Content Coding, which is the default coding. If accepted, this request would duplicate an entry with (hypothetical) Content-Format ID 64998 where the "Content Coding" field is left empty. Attempt at Registering an Equivalent Logical Entry with a Different Content-Format ID (2)
Content Type Content Coding ID
application/my - 64998
application/my identity 64999
Duplicate Entry with Equivalent Parameter The registrant requests an FCFS Content-Format ID for a Media Type that includes a parameter. The value of this parameter appears distinct from that of a (hypothetical) previously registered Content-Format ID 64998 that also includes this parameter. However, the semantics of the parameter value are identical to the existing registration. In this example, the eat_profile parameter value (which can be any URI) is set as a Uniform Resource Name (URN) . Since the Namespace Identifier (example, in this case) for URNs is defined as case insensitive, the two registrations are semantically identical. Attempt at Registering an Equivalent Logical Entry with a Different Content-Format ID (3)
Content Type Content Coding ID
application/eat+cwt;eat_profile="urn:example:1" - 64998
application/eat+cwt;eat_profile="urn:EXAMPLE:1" - 64999
New Note and Reference Additions IANA has added the following note to the registry:
Note: As per RFC 9876, temporary registrations within the 0-255 range are approved by designated experts. These registrations are not subject to the formal renewal process in .
IANA has also listed this document as an additional reference for the registry.
Reserving Content-Format Identifiers 64998 and 64999 for Documentation IANA has reserved Content-Format identifiers 64998 and 64999 for use in documentation.
References Normative References Constrained RESTful Environments (CoRE) Parameters IANA Media Types IANA Hypertext Transfer Protocol (HTTP) Parameters IANA Provisional Standard Media Type Registry IANA Informative References Erratum ID 4954 RFC Errata RFC 7252
Acknowledgments Thank you , , , , , , , , , , and for your reviews, comments, suggestions, and fixes.