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

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

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, "inflate": Attempt at Registering Content-Format with Unknown Content Coding

Content Type	Content Coding	ID
application/senml+cbor	inflate	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

Expert Review with Expert Check "FCFS+" This document introduces the term "Expert Review (Expert Check: FCFS+)" to describe a registration policy that would typically have been handled as FCFS, except the approval checklist is complex enough to require advice from a DE. Such policy can be viewed as a "lightweight" form of the "full" Expert Review. A protocol that requires "Expert Check: FCFS+" for registration of its parameters MUST specify what the FCFS+ checks entail.

CoAP Content-Formats Registration Procedures Update The CoAP Content-Formats registration procedures defined in are modified to transition the 10000-64999 range from FCFS to "Expert Review (Expert Check: FCFS+)", with the FCFS+ checklist described in . Updated CoAP Content-Formats Registration Procedures

Range	Registration Procedures
0-255	Expert Review (Full)
256-9999	IETF Review or IESG Approval
10000-64999	Expert Review (Expert Check: FCFS+)
65000-65535	Experimental use (no operational use)

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 policy that applies to the 10000-64999 range. For the 0-255 range, 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.

FCFS+ Checks The "Expert Check: FCFS+" checklist for the CoAP Content-Formats registry consist of the following steps:

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 in the "Media Types" registry , or IANA has approved its registration;
3. The optional parameter names must exist in association with the media type, and any parameter values associated with such parameter names are as expected;
4. If a Content Coding is specified, it must exist in the "HTTP Content Coding Registry" of the "Hypertext Transfer Protocol (HTTP) Parameters" , or IANA has approved its registration.

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 Carsten Bormann, Francesca Palombini and Marco Tiloca for your reviews and comments.