Update to the IANA CoAP Content-Formats Registration Procedures

Internet-Draft	CoAP Content-Format Registrations Update	December 2024
Fossati & Dijk	Expires 6 June 2025	[Page]

Abstract

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.¶

About This Document

This note is to be removed before publishing as an RFC.¶

The latest revision of this draft can be found at https://thomas-fossati.github.io/draft-cf-reg-update/draft-fossati-core-cf-reg-update.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-fossati-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/thomas-fossati/draft-cf-reg-update.¶

Status of This Memo

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 6 June 2025.¶

Copyright Notice

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.¶

1. Introduction

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 unfair to demand solely from the registrar. This lack of guidance may engender confusion in both the registering party and the registrar, and could eventually lead 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.¶

3. (Bad) Examples

This section contains a few examples of registration requests for a CoAP Content-Format with identifier in the FCFS space (64999) that should not be allowed to succeed.¶

3.1. The Media Type is Unknown

The registrant requests an FCFS Content-Format ID for an unknown media type:¶

Table 1: Attempt at Registering Content-Format for an Unknown Media Type
Content Type	Content Coding	ID
application/unknown+cbor	-	64999

3.2. The Media Type Parameter is Unknown

The registrant requests an FCFS Content-Format ID for an existing media type with an unknown parameter:¶

Table 2: Attempt at Registering Content-Format for Media Type with Unknown Parameter
Content Type	Content Coding	ID
application/cose; unknown-parameter=1	-	64999

3.3. 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:¶

Table 3: Attempt at Registering Content-Format for Media Type with Invalid Parameter Value
Content Type	Content Coding	ID
application/cose; cose-type=invalid	-	64999

3.4. The Content Coding is Unknown

The registrant requests an FCFS Content-Format ID for an existing media type with an unknown content coding, "inflate":¶

Table 4: Attempt at Registering Content-Format with Unknown Content Coding
Content Type	Content Coding	ID
application/senml+cbor	inflate	64999

3.5. 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. 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.¶

Table 5: Attempt at Registering an Equivalent Logical Entry with a Different Content-Format ID (1)
Content Type	Content Coding	ID
application/my	-	64900
application/my; parameter=default	-	64999

3.6. 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 where the "Content Coding" field is left empty.¶

Table 6: Attempt at Registering an Equivalent Logical Entry with a Different Content-Format ID (2)
Content Type	Content Coding	ID
application/my	-	64900
application/my	identity	64999

5. IANA Considerations

The CoAP Content-Formats registration procedures defined in Section 12.3 of [RFC7252] are modified as shown in Table 7.¶

Table 7: Updated CoAP Content-Formats Registration Procedures
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.¶

5.1. "Full" Expert Review Checks

The registration procedure for the 0-255 range has been slightly modified -- from "Expert Review" to "Expert Review (Full)" -- to clearly distinguish it from the "lightweight" Expert Review that may apply to the 10000-64999 range. For the 0-255 range, in addition to the checks described in Section 5.2, the DE must 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.¶

5.2. "Lightweight" Expert Review Checks

The "lightweight" Designated Expert review checklist for the CoAP Content-Formats registry consists of the following steps:¶

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 exist in association with the media type, and any parameter values associated with such parameter names are as expected;¶
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].¶

5.3. Temporary Note Removal

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 it when the this document is approved for publication.¶

6. References

6.1. Normative References

[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7252]: Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

6.2. Informative References

[Err4954]: RFC Errata Report 4954, RFC 7252, <https://www.rfc-editor.org/errata/eid4954>.
[IANA.core-parameters]: IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.
[IANA.http-parameters]: IANA, "Hypertext Transfer Protocol (HTTP) Parameters", <https://www.iana.org/assignments/http-parameters>.
[IANA.media-types]: IANA, "Media Types", <https://www.iana.org/assignments/media-types>.
[RFC9193]: Keränen, A. and C. Bormann, "Sensor Measurement Lists (SenML) Fields for Indicating Data Value Content-Format", RFC 9193, DOI 10.17487/RFC9193, June 2022, <https://www.rfc-editor.org/rfc/rfc9193>.