[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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,
              <https://www.rfc-editor.org/info/rfc6838>.

   [RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252,
              DOI 10.17487/RFC7252, June 2014,
              <https://www.rfc-editor.org/info/rfc7252>.

9.2.  Informative References

   [RFC1590]  Postel, J., "Media Type Registration Procedure", RFC 1590,
              DOI 10.17487/RFC1590, March 1994,
              <https://www.rfc-editor.org/info/rfc1590>.

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]


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/