| Internet-Draft | CoAP Content-Format Registrations Update | December 2024 |
| Fossati & Dijk | Expires 22 June 2025 | [Page] |
This document updates the registration procedures for the "CoAP Content-Formats" registry, within the "CoRE Parameters" registry group, defined in Section 12.3 of RFC7252, specifically, those regarding the First Come First Served (FCFS) portion of the registry.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://core-wg.github.io/cf-reg-update/draft-ietf-core-cf-reg-update.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-core-cf-reg-update/.¶
Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (mailto:core@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/core/. Subscribe at https://www.ietf.org/mailman/listinfo/core/.¶
Source for this draft and an issue tracker can be found at https://github.com/core-wg/cf-reg-update.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 June 2025.¶
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Section 12.3 of [RFC7252] describes the registration procedures for the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group [IANA.core-parameters]. (Note that the columns of this registry have been revised according to [Err4954].) In particular, the text defines the rules for obtaining CoAP Content-Format identifiers from the First Come First Served (FCFS) portion of the registry (10000-64999). These rules do not involve the Designated Expert (DE) and are managed solely by IANA personnel to finalize the registration. Unfortunately, the instructions 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, requiring knowledge from multiple documents and technologies, which is not a task to demand solely from the registrar. This lack of guidance may engender confusion in both the registering party and the registrar, and has already led to erroneous registrations.¶
Section 5 of this memo updates the registration procedures for the "CoAP Content-Formats" registry regarding its FCFS portion to reduce the risk of accidental or malicious errors.¶
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 [BCP14] (RFC2119) (RFC8174) 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 Section 2 of [RFC9193].¶
This section contains a few examples of registration requests for a CoAP Content-Format with identifier in the FCFS space (64999) that must not be allowed to succeed.¶
The registrant requests an FCFS Content-Format ID for an unknown media type:¶
| Content Type | Content Coding | ID |
|---|---|---|
| application/unknown+cbor | - | 64999 |
The registrant requests an FCFS Content-Format ID for an existing media type with an unknown parameter:¶
| Content Type | Content Coding | ID |
|---|---|---|
| application/cose; unknown-parameter=1 | - | 64999 |
The registrant requests an FCFS Content-Format ID for an existing media type with an invalid parameter value:¶
| Content Type | Content Coding | ID |
|---|---|---|
| application/cose; cose-type=invalid | - | 64999 |
The registrant requests an FCFS Content-Format ID for an existing media type with an unknown content coding:¶
| Content Type | Content Coding | ID |
|---|---|---|
| application/senml+cbor | inflate | 64999 |
The registrant requests an FCFS Content-Format ID for a media type that includes a parameter set to its default value, while this media type is already registered without that parameter. As a result, this could lead to the creation of two separate Content-Format IDs for the same "logical" entry.¶
| Content Type | Content Coding | ID |
|---|---|---|
| application/my | - | 64900 |
| application/my; parameter=default | - | 64999 |
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 where the "Content Coding" field is left empty.¶
| Content Type | Content Coding | ID |
|---|---|---|
| application/my | - | 64900 |
| application/my | identity | 64999 |
This memo hardens the registration procedures of CoAP Content-Formats in ways that reduce the chances of malicious manipulation of the associated registry.¶
Other than that, it does not change the Security Considerations of [RFC7252].¶
The CoAP Content-Formats registration procedures defined in Section 12.3 of [RFC7252] are modified as shown in Table 7.¶
| Range | Registration Procedures | Note |
|---|---|---|
| 0-255 | Expert Review | Full review described in RFCthis, Section 5.1 |
| 256-9999 | IETF Review or IESG Approval | |
| 10000-64999 (No parameters and empty Content Coding and media type not yet used in this registry) | First Come First Served | Corresponding media type registration required |
| 10000-64999 (Includes parameters and/or Content Coding) | Expert Review | Lightweight review described in RFCthis, Section 5.2 |
| 65000-65535 | Experimental use (no operational use) |
The 10000-64999 range now has two separate registration procedures. If the registration consists solely of a registered media type name in the "Content Type" field, without any parameter names or "Content Coding", and the media type has not yet been used in this registry, then the policy is FCFS, as before. In all other cases, the policy will be Expert Review, following the checklist described in Section 5.2.¶
A new column with the title "Note" has been added to the registry, which contains information about expected checks.¶
For the 0-255 range, the DE is instructed to perform a "Full Review" described in this section, not only the "lightweight" Expert Review that may apply to the 10000-64999 range. For this range, in addition to the checks described in Section 5.2, the DE is instructed to also evaluate the requested codepoint concerning the limited availability of the 1-byte codepoint space. For the 10000-64999 range, this criterion does not apply.¶
For the 10000-64999 range, the Designated Expert is instructed to perform the "lightweight" Expert review, as described by the following checklist:¶
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;¶
The media type associated with the requested Content-Format must exist (or must have been approved for registration) in the "Media Types" registry [IANA.media-types];¶
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;¶
If a Content Coding is specified, it must exist (or must have been approved for registration) in the "HTTP Content Coding" registry of the "Hypertext Transfer Protocol (HTTP) Parameters" [IANA.http-parameters].¶
This section is to be removed before publishing as an RFC.¶
The following note has been added to the registry as a temporary fix:¶
"Note: The validity of the combination of Content Coding, Content Type and parameters is checked prior to assignment."¶
IANA is instructed to remove this note from the registry when this document is approved for publication. RFC-Editor: please remove this section once the note has been removed.¶
Thank you Amanda Baber, Carsten Bormann, Francesca Palombini, and Marco Tiloca for your reviews, comments, suggestions and fixes.¶