Internet DRAFT - draft-bormann-core-proactive-ct
draft-bormann-core-proactive-ct
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]
