idnits 2.17.1 draft-bormann-core-proactive-ct-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 30, 2018) is 2099 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1590 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Best Current Practice K. Hartke 5 Expires: January 1, 2019 Ericsson 6 June 30, 2018 8 Proactively Assigning CoAP Content-Format Numbers to Registered Media 9 Types 10 draft-bormann-core-proactive-ct-00 12 Abstract 14 In order to use a media type with the Constrained Application 15 Protocol (CoAP), a numeric identifier needs to be registered for it, 16 the Content-Format number. 18 RFC 7252 defines registration procedures for Content-Format numbers. 19 The present document defines a proactive procedure to register a 20 Content-Format number for many of the media types that are registered 21 and discusses the benefits and limitations of that approach. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 1, 2019. 40 Copyright Notice 42 Copyright (c) 2018 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Media Types and Content-Format Numbers . . . . . . . . . . . 3 60 3. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.1. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.2. Potential Mishaps . . . . . . . . . . . . . . . . . . . . 4 64 4.2.1. Race Conditions . . . . . . . . . . . . . . . . . . . 4 65 4.2.2. Depletion of Pre-Registration Space . . . . . . . . . 5 66 5. Instructions to the Designated Expert . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 9.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 75 1. Introduction 77 To identify representation formats in a concise form, the Constrained 78 Application Protocol (CoAP) uses numeric identifiers, the Content- 79 Format Numbers [RFC7252]. A Content-Format number identifies a media 80 type [RFC6838] and a content coding (usually the identity coding). 81 Content-Format numbers are assigned in the CoAP Content-Formats 82 Registry, as defined in Section 12.3 of [RFC7252]. 84 At the time of writing, a couple dozen Content-Format numbers are 85 registered. Any new application that needs to register new media 86 types for use with CoAP can define the Content-Format numbers for its 87 media types as well. However, using existing applications and their 88 media types over CoAP is complicated by the need to register the 89 Content-Format numbers for these media types. 91 As of 2018, less than 2000 media types have been registered in the 92 Media Type Registry managed by [RFC6838], in a registry established 93 by [RFC1590] in 1994. No trends significantly accelerating the 94 growth of this registry are currently anticipated. 96 The size of the space available for Content-Format numbers is a 97 16-bit unsigned number. It is therefore very well possible to go 98 ahead and pre-define a Content-Format number for each media type 99 (where possible). When CoAP was defined, the space between 1000 and 100 9999 was informally set aside for this purpose (as part of the space 101 between 256 and 9999 that is reserved for future use in IETF 102 specifications, with IETF Review or IESG Approval). 104 The present document defines how the assignment of Content-Format 105 numbers for each existing media type and media type registered in the 106 future is performed. 108 1.1. Terminology 110 This memo uses terms from [RFC7252] and [RFC6838]. 112 2. Media Types and Content-Format Numbers 114 A Content-Format number identifies a media type with all the media 115 type parameters, as well as a content-coding to be used with the 116 media type. E.g., Content-Format 0 stands for "text/plain; 117 charset=utf-8" with identity content-coding. 119 It is generally not easy to extract from its registration the 120 parameters and ranges of parameter values that will be used with a 121 media type. The present document therefore only attempts to handle 122 media type parameters for one specific case: Where a charset needs to 123 be defined, this is always set to "utf-8". 125 Where parameters other than charset are needed by an application, it 126 will continue to need to register Content-Format numbers despite the 127 proactive registration defined here. 129 Similarly, any content-coding beyond identity will need to be defined 130 in a separate registration. 132 Therefore, the proactive registration procedure defined in this 133 document defines a single Content-Format number for each media type, 134 with no parameters (or just charset), and with identity content- 135 coding. This number is assigned by the below Procedure to fall in 136 the space between 1000 and 9999. 138 3. Procedure 140 Content-Format numbers need to be assigned for each existing and new 141 media type. Instead of defining a detailed procedure for this, the 142 present document delegates the definition of the procedure to a 143 designated expert. 145 The designated expert publishes the list of proactively registered 146 Content-Format numbers regularly at 147 https://svn.tools.ietf.org/svn/wg/core/mediatypes.txt 149 The designated expert is requested to 151 o only ever add information to the proactive registration document 152 (no changes or deletions) 154 o ensure that the proactive registration document is updated in some 155 reasonable cadence (e.g., monthly) 157 o provide a way to effect a quick update if such an update is 158 reasonably called for 160 o alert IANA to such updates. 162 IANA regularly (and when alerted) pulls the published list of 163 registrations, detects additions, and adds those additions to its 164 Content-Format registry. 166 4. Discussion 168 4.1. Latency 170 New media types do not immediately cause an update of the pre- 171 registration list, and such an update does not immediately case new 172 Content-Format number registries. Where this latency becomes an 173 issue (e.g., because of deadlines of other standards development 174 organizations that depend on these procedures), the designated expert 175 can be alerted to effect a quick update. 177 New media types that are expressly intended for use in constrained 178 environments of course should not wait for the procedure described 179 here to effect their content-format registration, but should include 180 the registration of a Content-Format number in their IANA 181 considerations, as before. This also makes sure that any additional 182 considerations (such as the potential need for a single-byte content- 183 format number) are taken into account. 185 4.2. Potential Mishaps 187 4.2.1. Race Conditions 189 When the IANA registers a new media type and associated content- 190 format numbers, the registry state could briefly show the new media 191 type but not the new content-format numbers. If an update is created 192 to the pre-registrations at this very moment, the assignment of 193 redundant Content-Format numbers could not be prevented. 195 The present document does not attempt to prevent the registration of 196 redundant Content-Format numbers. So, "application/json" is both 197 identified by Content-Format number 50 [RFC7252] and by the Content- 198 Format number 4330 assigned under the pre-registration procedure. 200 4.2.2. Depletion of Pre-Registration Space 202 When a survey was run June 2018, 1726 media types were registered. 203 1006 of these have no parameters and will be proactively assigned a 204 Content-Format number under this scheme. 276 more have just one 205 parameter, "charset", and will also be proactively assigned a 206 Content-Format number by setting this parameter to "utf-8". 208 418 media types have parameters that would require manual assignment 209 of appropriate parameter values. This is not envisioned for the 210 scheme described in this document. Finally, 26 media types could not 211 easily be automatically analyzed and would require manual processing 212 before sorting into one of the categories; this document leaves it up 213 to the designated expert to decide whether to perform this processing 214 and where. 216 In summary, as of the time of the survey, about 1/7 of the space 217 envisioned for the scheme will be used by the media type 218 registrations performed in the first 24 years of the registry (and 219 the entire space reserved in turn is a bit less than 1/7 of the total 220 space for Content-Format numbers). 222 Sudden changes in the patterns of media type registrations, although 223 not anticipated at this time, could lead to depletion of the pre- 224 registration space. This would not be a disaster, but would simply 225 return Content-Format number registration to the situation before 226 proactive registration (with the existing assignment of course 227 continuing to be usable). The present document does not attempt to 228 define a solution for this unlikely case. 230 However, the pre-registration procedure could motivate a malicious 231 actor to define a large number of media types just to cause this 232 depletion. One would hope that this is already prevented by the 233 media type registration procedures, but just to reduce the incentive 234 for such an attack, the procedures defined in this document make use 235 of a designated expert that could detect such an attack and allow the 236 designated expert to apply some mitigation. 238 5. Instructions to the Designated Expert 240 The designated expert is instructed to operate along the lines of the 241 procedure described in Section 3, and towards the objectives defined 242 in this document. 244 Between these two, the objectives are the overriding concern. Where 245 the procedure turns out to no longer serve to further the objectives, 246 the designated expert is instructed to adapt the procedure. If 247 substantive changes to the procedure are deemed necessary, the 248 designated expert is instructed to raise a discussion on the mailing 249 list "core-parameters@ietf.org"; if the result of the discussion is a 250 change of moderate extent, the designated expert can simply perform 251 that change, document it on the mailing list, and act based on the 252 updated procedure. 254 (If several designated experts are appointed, the above requires 255 consensus between the designated experts.) 257 Fundamental changes, e.g., stepping out of the boundary of the number 258 space, require further IETF review. 260 6. IANA Considerations 262 This entire document is about a IANA procedure. 264 7. Security Considerations 266 Accurate identification of representation formats can be important 267 for security. Lowering the threshold for obtaining the registrations 268 needed for this identification can therefore have a positive security 269 impact. Conversely, limiting the representation formats pre- 270 registered for each media type to just the single case without 271 parameters and with identity content-coding might encourage imprecise 272 identification. The present document is therefore not to be used as 273 a substitute for registering any more specific Content-Format numbers 274 needed by an application. 276 Procedures as defined in the present document can also be the subject 277 of attacks. See Section 4.2.2 for one such consideration. 279 Acknowledgements 281 TBD 283 9. References 285 9.1. Normative References 287 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 288 Specifications and Registration Procedures", BCP 13, 289 RFC 6838, DOI 10.17487/RFC6838, January 2013, 290 . 292 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 293 Application Protocol (CoAP)", RFC 7252, 294 DOI 10.17487/RFC7252, June 2014, 295 . 297 9.2. Informative References 299 [RFC1590] Postel, J., "Media Type Registration Procedure", RFC 1590, 300 DOI 10.17487/RFC1590, March 1994, 301 . 303 Authors' Addresses 305 Carsten Bormann 306 Universitaet Bremen TZI 307 Postfach 330440 308 Bremen D-28359 309 Germany 311 Phone: +49-421-218-63921 312 Email: cabo@tzi.org 314 Klaus Hartke 315 Ericsson 316 Torshamnsgatan 23 317 Stockholm SE-16483 318 Sweden 320 Email: klaus.hartke@ericsson.com