Constrained Application Protocol (CoAP): Corrections and Clarifications
draft-bormann-core-corr-clar-01
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Carsten Bormann | ||
| Last updated | 2023-07-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bormann-core-corr-clar-01
Network Working Group C. Bormann
Internet-Draft Universität Bremen TZI
Updates: 6690, 7252, 7641, 7959, 8132, 8323 (if 23 July 2023
approved)
Intended status: Standards Track
Expires: 24 January 2024
Constrained Application Protocol (CoAP): Corrections and Clarifications
draft-bormann-core-corr-clar-01
Abstract
RFC 7252 defines the Constrained Application Protocol (CoAP), along
with a number of additional specifications, including RFC 7641, RFC
7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that
is used in CoAP self-description documents.
Some parts of the specification may be unclear or even contain errors
that may lead to misinterpretations that may impair interoperability
between different implementations. The present document provides
corrections, additions, and clarifications to the RFCs cited; this
document thus updates these RFCs. In addition, other clarifications
related to the use of CoAP in other specifications, including RFC
7390 and RFC 8075, are also provided.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-bormann-core-corr-clar/.
Discussion of this document takes place on the core Working Group
mailing list (mailto:core@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/core/. Subscribe at
https://www.ietf.org/mailman/listinfo/core/.
Source for this draft and an issue tracker can be found at
https://github.com/core-wg/corrclar.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Bormann Expires 24 January 2024 [Page 1]
Internet-Draft Corrections and Clarifications to CoAP July 2023
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 24 January 2024.
Copyright Notice
Copyright (c) 2023 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 carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Process . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. RFC 7252 . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. RFC7252-5.10.5: Max-Age . . . . . . . . . . . . . . . . . 4
2.2. RFC7252-7.2.1: "ct" Attribute (content-format code) . . . 4
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 5
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Normative References . . . . . . . . . . . . . . . . . . 5
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[RFC7252] defines the Constrained Application Protocol (CoAP), along
with a number of additional specifications, including [RFC7641],
[RFC7959], [RFC8132], and [RFC8323]. [RFC6690] defines the link
format that is used in CoAP self-description documents.
Bormann Expires 24 January 2024 [Page 2]
Internet-Draft Corrections and Clarifications to CoAP July 2023
During implementation and interoperability testing of these RFCs, and
in their practical use, some ambiguities and common
misinterpretations have been identified, as well as a few errors.
The present document summarizes identified issues and provides
corrections needed for implementations of CoAP to interoperate, i.e.,
it constitutes an update to the RFCs referenced. This document also
provides other clarifications related to common misinterpretations of
the specification. References to CoAP should, therefore, also
include this document.
In addition, some clarifications and corrections are also provided
for documents that are related to CoAP, including RFC 7390 and RFC
8075.
1.1. Process
The present document is an Internet-Draft, which is not intended to
be published as an RFC quickly. Instead, it will be maintained as a
running document of the CoRE WG, probably for a number of years,
until the need for new entries tails off and the document can finally
be published as an RFC. (This paragraph to be rephrased when that
happens.)
The status of this document as a running document of the WG implies a
consensus process that is applied in making updates to it. The rest
of this subsection provides more details about this consensus
process. (This is the intended status; currently, the document is an
individual submission only.)
(Consensus process TBD, but it will likely be based on an editor's
version in a publicly accessible git repository, as well as periodic
calls for consensus that lead to a new published Internet-Draft;.)
1.2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
Bormann Expires 24 January 2024 [Page 3]
Internet-Draft Corrections and Clarifications to CoAP July 2023
When a section of this document makes formal corrections, additions
or invalidations to text in a referenced RFC, this is clearly
summarized. The text from the RFC that is being addressed is given
and labeled "INCOMPLETE", "INCORRECT", or "INCORRECT AND
INVALIDATED", followed by the correct text labeled "CORRECTED", where
applicable. When text is added that does not simply correct text in
previous specifications, it is given with the label "FORMAL
ADDITION".
Where a resolution has not yet been agreed, the resolution is marked
PENDING.
In this document, a reference to a section in RFC nnnn is written as
RFC nnnn-<number>, where <number> is the section number.
2. RFC 7252
2.1. RFC7252-5.10.5: Max-Age
In the discussion of [RFC8516], a comment was made that it would be
needed to define the point in time relative to which Max-Age is
defined. A sender might reference it to the time it actually sends
the message containing the option (and paragraph 3 of RFC7252-5.10.5
indeed requests that Max-Age be updated each time a message is
retransmitted). The receiver of the message does not have reliable
information about the time of sending, though. It may instead
reference the Max-Age to the time of reception. This in effect
extends the time of Max-Age by the latency of the packet. This
extension was deemed acceptable for the purposes of [RFC8516], but
may be suboptimal when Max-Age is about the lifetime of a response
object.
INCOMPLETE:
The value is intended to be current at the time of transmission.
PENDING.
2.2. RFC7252-7.2.1: "ct" Attribute (content-format code)
As has been noted in [Err5078], there is no information in [RFC7252]
about whether the "ct" target attribute can be present multiply or
not.
The text does indicate that the value of the attribute MAY be "a
space-separated sequence of Content-Format codes, indicating that
multiple content-formats are available", but it does not repeat the
prohibition of multiple instances that the analogously structured
"rt" and "if" attributes in Sections 3.1 and 3.2 of [RFC6690] have.
Bormann Expires 24 January 2024 [Page 4]
Internet-Draft Corrections and Clarifications to CoAP July 2023
This appears to be an oversight. Published examples in Section 4.1
of [RFC9148] and Section 4.3 of [RFC9176] further illustrate that the
space-separated approach is generally accepted to be the one to be
used. There is no gain to be had from allowing both variants, and it
would be likely to cause interoperability problems.
At the 2022-11-23 CoRE WG interim meeting, there was agreement that
[Err5078] should be marked "VERIFIED", which will be reflected here
once implemented.
INCOMPLETE:
The Content-Format code attribute MUST NOT appear more than once
in a link.
PENDING (to be VERIFIED).
3. IANA Considerations
None yet.
(Individual clarifications may contain IANA considerations; these
will then be referenced here.)
4. Security Considerations
This document provides a number of corrections and clarifications to
existing RFCs, but it does not make any changes with regard to the
security aspects of the protocol. As a consequence, the security
considerations of the referenced RFCs apply without additions.
(To be changed when that is no longer true; probably the security
considerations will then be on the individual clarifications.)
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/rfc/rfc6690>.
Bormann Expires 24 January 2024 [Page 5]
Internet-Draft Corrections and Clarifications to CoAP July 2023
[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/rfc/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/rfc/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016,
<https://www.rfc-editor.org/rfc/rfc7959>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/rfc/rfc8132>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets",
RFC 8323, DOI 10.17487/RFC8323, February 2018,
<https://www.rfc-editor.org/rfc/rfc8323>.
5.2. Informative References
[Err5078] "Errata Report 5078", RFC 7252,
<https://www.rfc-editor.org/errata/eid5078>.
[RFC8516] Keranen, A., ""Too Many Requests" Response Code for the
Constrained Application Protocol", RFC 8516,
DOI 10.17487/RFC8516, January 2019,
<https://www.rfc-editor.org/rfc/rfc8516>.
[RFC9148] van der Stok, P., Kampanakis, P., Richardson, M., and S.
Raza, "EST-coaps: Enrollment over Secure Transport with
the Secure Constrained Application Protocol", RFC 9148,
DOI 10.17487/RFC9148, April 2022,
<https://www.rfc-editor.org/rfc/rfc9148>.
Bormann Expires 24 January 2024 [Page 6]
Internet-Draft Corrections and Clarifications to CoAP July 2023
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, <https://www.rfc-editor.org/rfc/rfc9176>.
Acknowledgements
The present document is modeled after RFC 4815 and the Internet-
Drafts of the ROHC WG that led to it. Many thanks to the co-chairs
of the ROHC WG and WG members that made this a worthwhile and
successful experiment at the time.
Author's Address
Carsten Bormann
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org
Bormann Expires 24 January 2024 [Page 7]