]> 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 RFC7252 regarding 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 identifier 64999 for use in documentation. 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" 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 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 (DE) 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 has already led to erroneous registrations. In , 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 identifier 64999 for use in documentation.

Conventions and Definitions 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.

Examples for Erroneous Registrations 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. All the example registration requests use a CoAP Content-Format with identifier 64999. For each of the following example registration requests, one can create a similar instance where the requested registration is for a CoAP Content-Format identifier within the "IETF Review or IESG Approval" range. Likewise, such registrations 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 a (hypothetical) Content-Format ID 64900 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	-	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 with (hypothetical) Content-Format ID 64900 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

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 64900 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 for URNs, the Namespace Identifier (example in this example) 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"	-	64900
application/eat+cwt;eat_profile="urn:EXAMPLE:1"	-	64999

Updates to RFC 7252 This section updates and introduces four new subsections, 12.3.1 to 12.3.4.

Updates to Section 12.3 "CoAP Content-Formats Registry" RFC Editor: in this section, please replace RFCthis with the RFC number assigned to this document and remove this note. The CoAP Content-Formats registration procedures defined in are modified as shown in . Updated CoAP Content-Formats Registration Procedures

Range	Registration Procedures	Notes
0-255	Expert Review	Review procedure described in RFCthis, .
256-9999	IETF Review with Expert Review or IESG Approval with Expert Review	Review procedure described in RFCthis,
10000-19999	Expert Review	Review procedure described in RFCthis, .
20000-32999	First Come First Served (FCFS)	FCFS is allowed if the registration: * has no parameters, and * has an empty Content Coding, and * 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-64998	Expert Review	Review procedure described in RFCthis, .
64999	-	Reserved for Documentation
65000-65535	Experimental Use	No operational use

The 256-9999 range now 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 with "Expert Review" additionally required per . 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 with "Expert Review" additionally required per .

The registration policy for the 10000-19999 and 33000-64998 ranges is "Expert Review", following the procedure described in . The registration policy for the 20000-32999 range is FCFS, as before. 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. A new column with the title "Notes" has been added to the CoAP Content-Formats Registration Procedures shown in . For the handling of temporary allocations within the 0-255 range see also .

New Section 12.3.1 "Temporary Content-Format Registrations" This section clarifies that the "CoAP Content-Formats" registry allows temporary registrations within the 0-64998 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 IANA "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 IANA 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-64998 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.

New Section 12.3.2 "Adding 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 is requested to add a new column "Media Type" to the registry. This new column is placed directly 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 IANA "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. Note that the registration request procedure remains unchanged. A 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.

New Section 12.3.3 "Expert Review Procedure" The Designated Expert (DE) 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 either be 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 of the "Hypertext Transfer Protocol (HTTP) Parameters" .

For the 0-255 range, in addition to the checks described above, the DE is instructed to also evaluate the requested codepoint concerning the limited availability of the 1-byte codepoint space. For the 256-64998 range, a similar criterion may also apply where combinations of Media Type parameters and Content Coding choices consume considerable codepoint space.

New Section 12.3.4 "Preferred Format for the Content Type Field" This section defines the preferred string format for including a requested Content Type into 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 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 Media Type and parameters.

Security Considerations This document 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 This document updates the IANA procedures defined in for registering CoAP Content-Formats as described in .

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.

New Note Addition RFC Editor: in this section, please replace RFCthis with the RFC number assigned to this document and remove this note. IANA is instructed to add the following note to the registry:

• "Note: As per RFCthis, temporary registrations within the 0-255 range are approved by Designated Experts. These registrations are not subject to the formal renewal process."

Reserving Content-Format Identifier 64999 for Documentation IANA is instructed to reserve Content-Format identifier 64999 for use in documentation.

References Normative References This memo describes the process for early allocation of code points by IANA from registries for which "Specification Required", "RFC Required", "IETF Review", or "Standards Action" policies apply. This process can be used to alleviate the problem where code point allocation is needed to facilitate desired or required implementation and deployment experience prior to publication of an RFC, which would normally trigger code point allocation. The procedures in this document are intended to apply only to IETF Stream documents. 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. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. 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. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. IANA IANA IANA IANA Informative References A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI) that is assigned under the "urn" URI scheme and a particular URN namespace, with the intent that the URN will be a persistent, location-independent resource identifier. With regard to URN syntax, this document defines the canonical syntax for URNs (in a way that is consistent with URI syntax), specifies methods for determining URN-equivalence, and discusses URI conformance. With regard to URN namespaces, this document specifies a method for defining a URN namespace and associating it with a namespace identifier, and it describes procedures for registering namespace identifiers with the Internet Assigned Numbers Authority (IANA). This document obsoletes both RFCs 2141 and 3406.

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