CoRE Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Best Current Practice K. Hartke Expires: January 1, 2019 Ericsson June 30, 2018 Proactively Assigning CoAP Content-Format Numbers to Registered Media Types draft-bormann-core-proactive-ct-00 Abstract In order to use a media type with the Constrained Application Protocol (CoAP), a numeric identifier needs to be registered for it, the Content-Format number. RFC 7252 defines registration procedures for Content-Format numbers. The present document defines a proactive procedure to register a Content-Format number for many of the media types that are registered and discusses the benefits and limitations of that approach. 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 January 1, 2019. Copyright Notice Copyright (c) 2018 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 Bormann & Hartke Expires January 1, 2019 [Page 1] Internet-Draft Proactively Assigning Content-Format IDs June 2018 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Media Types and Content-Format Numbers . . . . . . . . . . . 3 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.2. Potential Mishaps . . . . . . . . . . . . . . . . . . . . 4 4.2.1. Race Conditions . . . . . . . . . . . . . . . . . . . 4 4.2.2. Depletion of Pre-Registration Space . . . . . . . . . 5 5. Instructions to the Designated Expert . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction To identify representation formats in a concise form, the Constrained Application Protocol (CoAP) uses numeric identifiers, the Content- Format Numbers [RFC7252]. A Content-Format number identifies a media type [RFC6838] and a content coding (usually the identity coding). Content-Format numbers are assigned in the CoAP Content-Formats Registry, as defined in Section 12.3 of [RFC7252]. At the time of writing, a couple dozen Content-Format numbers are registered. Any new application that needs to register new media types for use with CoAP can define the Content-Format numbers for its media types as well. However, using existing applications and their media types over CoAP is complicated by the need to register the Content-Format numbers for these media types. As of 2018, less than 2000 media types have been registered in the Media Type Registry managed by [RFC6838], in a registry established by [RFC1590] in 1994. No trends significantly accelerating the growth of this registry are currently anticipated. Bormann & Hartke Expires January 1, 2019 [Page 2] Internet-Draft Proactively Assigning Content-Format IDs June 2018 The size of the space available for Content-Format numbers is a 16-bit unsigned number. It is therefore very well possible to go ahead and pre-define a Content-Format number for each media type (where possible). When CoAP was defined, the space between 1000 and 9999 was informally set aside for this purpose (as part of the space between 256 and 9999 that is reserved for future use in IETF specifications, with IETF Review or IESG Approval). The present document defines how the assignment of Content-Format numbers for each existing media type and media type registered in the future is performed. 1.1. Terminology This memo uses terms from [RFC7252] and [RFC6838]. 2. Media Types and Content-Format Numbers A Content-Format number identifies a media type with all the media type parameters, as well as a content-coding to be used with the media type. E.g., Content-Format 0 stands for "text/plain; charset=utf-8" with identity content-coding. It is generally not easy to extract from its registration the parameters and ranges of parameter values that will be used with a media type. The present document therefore only attempts to handle media type parameters for one specific case: Where a charset needs to be defined, this is always set to "utf-8". Where parameters other than charset are needed by an application, it will continue to need to register Content-Format numbers despite the proactive registration defined here. Similarly, any content-coding beyond identity will need to be defined in a separate registration. Therefore, the proactive registration procedure defined in this document defines a single Content-Format number for each media type, with no parameters (or just charset), and with identity content- coding. This number is assigned by the below Procedure to fall in the space between 1000 and 9999. 3. Procedure Content-Format numbers need to be assigned for each existing and new media type. Instead of defining a detailed procedure for this, the present document delegates the definition of the procedure to a designated expert. Bormann & Hartke Expires January 1, 2019 [Page 3] Internet-Draft Proactively Assigning Content-Format IDs June 2018 The designated expert publishes the list of proactively registered Content-Format numbers regularly at https://svn.tools.ietf.org/svn/wg/core/mediatypes.txt The designated expert is requested to o only ever add information to the proactive registration document (no changes or deletions) o ensure that the proactive registration document is updated in some reasonable cadence (e.g., monthly) o provide a way to effect a quick update if such an update is reasonably called for o alert IANA to such updates. IANA regularly (and when alerted) pulls the published list of registrations, detects additions, and adds those additions to its Content-Format registry. 4. Discussion 4.1. Latency New media types do not immediately cause an update of the pre- registration list, and such an update does not immediately case new Content-Format number registries. Where this latency becomes an issue (e.g., because of deadlines of other standards development organizations that depend on these procedures), the designated expert can be alerted to effect a quick update. New media types that are expressly intended for use in constrained environments of course should not wait for the procedure described here to effect their content-format registration, but should include the registration of a Content-Format number in their IANA considerations, as before. This also makes sure that any additional considerations (such as the potential need for a single-byte content- format number) are taken into account. 4.2. Potential Mishaps 4.2.1. Race Conditions When the IANA registers a new media type and associated content- format numbers, the registry state could briefly show the new media type but not the new content-format numbers. If an update is created Bormann & Hartke Expires January 1, 2019 [Page 4] Internet-Draft Proactively Assigning Content-Format IDs June 2018 to the pre-registrations at this very moment, the assignment of redundant Content-Format numbers could not be prevented. The present document does not attempt to prevent the registration of redundant Content-Format numbers. So, "application/json" is both identified by Content-Format number 50 [RFC7252] and by the Content- Format number 4330 assigned under the pre-registration procedure. 4.2.2. Depletion of Pre-Registration Space When a survey was run June 2018, 1726 media types were registered. 1006 of these have no parameters and will be proactively assigned a Content-Format number under this scheme. 276 more have just one parameter, "charset", and will also be proactively assigned a Content-Format number by setting this parameter to "utf-8". 418 media types have parameters that would require manual assignment of appropriate parameter values. This is not envisioned for the scheme described in this document. Finally, 26 media types could not easily be automatically analyzed and would require manual processing before sorting into one of the categories; this document leaves it up to the designated expert to decide whether to perform this processing and where. In summary, as of the time of the survey, about 1/7 of the space envisioned for the scheme will be used by the media type registrations performed in the first 24 years of the registry (and the entire space reserved in turn is a bit less than 1/7 of the total space for Content-Format numbers). Sudden changes in the patterns of media type registrations, although not anticipated at this time, could lead to depletion of the pre- registration space. This would not be a disaster, but would simply return Content-Format number registration to the situation before proactive registration (with the existing assignment of course continuing to be usable). The present document does not attempt to define a solution for this unlikely case. However, the pre-registration procedure could motivate a malicious actor to define a large number of media types just to cause this depletion. One would hope that this is already prevented by the media type registration procedures, but just to reduce the incentive for such an attack, the procedures defined in this document make use of a designated expert that could detect such an attack and allow the designated expert to apply some mitigation. Bormann & Hartke Expires January 1, 2019 [Page 5] Internet-Draft Proactively Assigning Content-Format IDs June 2018 5. Instructions to the Designated Expert The designated expert is instructed to operate along the lines of the procedure described in Section 3, and towards the objectives defined in this document. Between these two, the objectives are the overriding concern. Where the procedure turns out to no longer serve to further the objectives, the designated expert is instructed to adapt the procedure. If substantive changes to the procedure are deemed necessary, the designated expert is instructed to raise a discussion on the mailing list "core-parameters@ietf.org"; if the result of the discussion is a change of moderate extent, the designated expert can simply perform that change, document it on the mailing list, and act based on the updated procedure. (If several designated experts are appointed, the above requires consensus between the designated experts.) Fundamental changes, e.g., stepping out of the boundary of the number space, require further IETF review. 6. IANA Considerations This entire document is about a IANA procedure. 7. Security Considerations Accurate identification of representation formats can be important for security. Lowering the threshold for obtaining the registrations needed for this identification can therefore have a positive security impact. Conversely, limiting the representation formats pre- registered for each media type to just the single case without parameters and with identity content-coding might encourage imprecise identification. The present document is therefore not to be used as a substitute for registering any more specific Content-Format numbers needed by an application. Procedures as defined in the present document can also be the subject of attacks. See Section 4.2.2 for one such consideration. Acknowledgements TBD Bormann & Hartke Expires January 1, 2019 [Page 6] Internet-Draft Proactively Assigning Content-Format IDs June 2018 9. References 9.1. Normative References [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . 9.2. Informative References [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, DOI 10.17487/RFC1590, March 1994, . Authors' Addresses Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Email: cabo@tzi.org Klaus Hartke Ericsson Torshamnsgatan 23 Stockholm SE-16483 Sweden Email: klaus.hartke@ericsson.com Bormann & Hartke Expires January 1, 2019 [Page 7]