idnits 2.17.1 draft-bormann-core-corr-clar-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC6690, but the abstract doesn't seem to directly say this. It does mention RFC6690 though, so this could be OK. -- The draft header indicates that this document updates RFC8132, but the abstract doesn't seem to directly say this. It does mention RFC8132 though, so this could be OK. -- The draft header indicates that this document updates RFC7252, but the abstract doesn't seem to directly say this. It does mention RFC7252 though, so this could be OK. -- The draft header indicates that this document updates RFC7959, but the abstract doesn't seem to directly say this. It does mention RFC7959 though, so this could be OK. -- The draft header indicates that this document updates RFC7641, but the abstract doesn't seem to directly say this. It does mention RFC7641 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 24, 2018) is 2010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-06) exists of draft-ietf-core-too-many-reqs-05 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Bormann 3 Internet-Draft Universitaet Bremen TZI 4 Updates: 6690, 7252, 7641, 7959, 8132, October 24, 2018 5 8323 (if approved) 6 Intended status: Standards Track 7 Expires: April 27, 2019 9 Constrained Application Protocol (CoAP): Corrections and Clarifications 10 draft-bormann-core-corr-clar-00 12 Abstract 14 RFC 7252 defines the Constrained Application Protocol (CoAP), along 15 with a number of additional specifications, including RFC 7641, RFC 16 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that 17 is used in CoAP self-description documents. 19 Some parts of the specification may be unclear or even contain errors 20 that may lead to misinterpretations that may impair interoperability 21 between different implementations. The present document provides 22 corrections, additions, and clarifications to the RFCs cited; this 23 document thus updates these RFCs. In addition, other clarifications 24 related to the use of CoAP in other specifications, including RFC 25 7390 and RFC 8075, are also provided. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on April 27, 2019. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Process . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. RFC 7252 . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. RFC7252-5.10.5: Max-Age . . . . . . . . . . . . . . . . . 4 66 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 68 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 70 5.2. Informative References . . . . . . . . . . . . . . . . . 5 71 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 74 1. Introduction 76 [RFC7252] defines the Constrained Application Protocol (CoAP), along 77 with a number of additional specifications, including [RFC7641], 78 [RFC7959], [RFC8132], and [RFC8323]. [RFC6690] defines the link 79 format that is used in CoAP self-description documents. 81 During implementation and interoperability testing of these RFCs, and 82 in their practical use, some ambiguities and common 83 misinterpretations have been identified, as well as a few errors. 85 The present document summarizes identified issues and provides 86 corrections needed for implementations of CoAP to interoperate, i.e., 87 it constitutes an update to the RFCs referenced. This document also 88 provides other clarifications related to common misinterpretations of 89 the specification. References to CoAP should, therefore, also 90 include this document. 92 In addition, some clarifications and corrections are also provided 93 for documents that are related to CoAP, including RFC 7390 and RFC 94 8075. 96 1.1. Process 98 The present document is an Internet-Draft, which is not intended to 99 be published as an RFC quickly. Instead, it will be maintained as a 100 running document of the CoRE WG, probably for a number of years, 101 until the need for new entries tails off and the document can finally 102 be published as an RFC. (This paragraph to be rephrased when that 103 happens.) 105 The status of this document as a running document of the WG implies a 106 consensus process that is applied in making updates to it. The rest 107 of this subsection provides more details about this consensus 108 process. (This is the intended status; currently, the document is an 109 individual submission only.) 111 (Consensus process TBD, but it will likely be based on an editor's 112 version in a publicly accessible git repository, as well as periodic 113 calls for consensus that lead to a new published Internet-Draft;.) 115 1.2. Terminology 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in 120 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 When a section of this document makes formal corrections, additions 124 or invalidations to text in a referenced RFC, this is clearly 125 summarized. The text from the RFC that is being addressed is given 126 and labeled "INCOMPLETE", "INCORRECT", or "INCORRECT AND 127 INVALIDATED", followed by the correct text labeled "CORRECTED", where 128 applicable. When text is added that does not simply correct text in 129 previous specifications, it is given with the label "FORMAL 130 ADDITION". 132 Where a resolution has not yet been agreed, the resolution is marked 133 PENDING. 135 In this document, a reference to a section in RFC nnnn is written as 136 RFC nnnn-, where is the section number. 138 2. RFC 7252 139 2.1. RFC7252-5.10.5: Max-Age 141 In the discussion of [I-D.ietf-core-too-many-reqs], a comment was 142 made that it would be needed to define the point in time relative to 143 which Max-Age is defined. A sender might reference it to the time it 144 actually sends the message containing the option (and paragraph 3 of 145 RFC7252-5.10.5 indeed requests that Max-Age be updated each time a 146 message is retransmitted). The receiver of the message does not have 147 reliable information about the time of sending, though. It may 148 instead reference the Max-Age to the time of reception. This in 149 effect extends the time of Max-Age by the latency of the packet. 150 This extension was deemed acceptable for the purposes of 151 [I-D.ietf-core-too-many-reqs], but may be suboptimal when Max-Age is 152 about the lifetime of a response object. 154 INCOMPLETE: 155 The value is intended to be current at the time of transmission. 157 PENDING. 159 3. IANA Considerations 161 None yet. 163 (Individual clarifications may contain IANA considerations; these 164 will then be referenced here.) 166 4. Security Considerations 168 This document provides a number of corrections and clarifications to 169 existing RFCs, but it does not make any changes with regard to the 170 security aspects of the protocol. As a consequence, the security 171 considerations of the referenced RFCs apply without additions. 173 (To be changed when that is no longer true; probably the security 174 considerations will then be on the individual clarifications.) 176 5. References 178 5.1. Normative References 180 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 181 Requirement Levels", BCP 14, RFC 2119, 182 DOI 10.17487/RFC2119, March 1997, 183 . 185 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 186 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 187 . 189 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 190 Application Protocol (CoAP)", RFC 7252, 191 DOI 10.17487/RFC7252, June 2014, 192 . 194 [RFC7641] Hartke, K., "Observing Resources in the Constrained 195 Application Protocol (CoAP)", RFC 7641, 196 DOI 10.17487/RFC7641, September 2015, 197 . 199 [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in 200 the Constrained Application Protocol (CoAP)", RFC 7959, 201 DOI 10.17487/RFC7959, August 2016, 202 . 204 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 205 FETCH Methods for the Constrained Application Protocol 206 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 207 . 209 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 210 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 211 May 2017, . 213 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 214 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 215 Application Protocol) over TCP, TLS, and WebSockets", 216 RFC 8323, DOI 10.17487/RFC8323, February 2018, 217 . 219 5.2. Informative References 221 [I-D.ietf-core-too-many-reqs] 222 Keranen, A., "Too Many Requests Response Code for the 223 Constrained Application Protocol", draft-ietf-core-too- 224 many-reqs-05 (work in progress), October 2018. 226 Acknowledgements 228 The present document is modeled after RFC 4815 and the Internet- 229 Drafts of the ROHC WG that led to it. Many thanks to the co-chairs 230 of the ROHC WG and WG members that made this a worthwhile and 231 successful experiment at the time. 233 Author's Address 235 Carsten Bormann 236 Universitaet Bremen TZI 237 Postfach 330440 238 Bremen D-28359 239 Germany 241 Phone: +49-421-218-63921 242 Email: cabo@tzi.org