]> Linaro

thomas.fossati@linaro.org

IoTconsultancy.nl

esko.dijk@iotconsultancy.nl

Web and Internet Transport Constrained RESTful Environments IANA registration update CoAP Content-Format 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 The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction describes the registration procedures for the "CoAP Content-Formats" registry within the "CoRE Parameters" registry group . (Note that the columns of this registry have been revised according to .) 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. 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.

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 () () 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 .

Examples for Erroneous Registrations 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 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 Media Type with 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 Media Type with 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 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. 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

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

Security Considerations 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 .

IANA Considerations The CoAP Content-Formats registration procedures defined in are modified as shown in . Updated CoAP Content-Formats Registration Procedures

Range	Registration Procedures	Note
0-255	Expert Review	Full review described in RFCthis,
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,
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 . A new column with the title "Note" has been added to the registry, which contains information about expected checks.

"Full" Expert Review 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 , 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.

"Lightweight" Expert Review Checks For the 10000-64999 range, the Designated Expert is instructed to perform the "lightweight" 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 exist (or must have been approved for registration) in the "Media Types" registry ;
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. 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" .

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 this note from the registry when this document is approved for publication. RFC-Editor: please remove this section once the note has been removed.

References Normative References The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Sensor Measurement Lists (SenML) media types support multiple types of values, from numbers to text strings and arbitrary binary Data Values. In order to facilitate processing of binary Data Values, this document specifies a pair of new SenML fields for indicating the content format of those binary Data Values, i.e., their Internet media type, including parameters as well as any content codings applied. IANA IANA IANA

Acknowledgments Thank you Amanda Baber, Carsten Bormann, Francesca Palombini, and Marco Tiloca for your reviews, comments, suggestions and fixes.