idnits 2.17.1 draft-amsuess-core-accept-any-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 document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC7252], [RFC7641]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 93: '...rence. A server MUST answer with the ...' RFC 2119 keyword, line 98: '...ccept-Any option MUST NOT be used exac...' RFC 2119 keyword, line 104: '... A proxy MAY ignore this option per ...' RFC 2119 keyword, line 117: '... a proxy SHOULD [ we can't have a MU...' -- 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 date (March 25, 2019) is 1858 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) -- Looks like a reference, but probably isn't: '1' on line 198 == Outdated reference: A later version (-04) exists of draft-ietf-core-multipart-ct-03 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE C. Amsuess 3 Internet-Draft March 25, 2019 4 Updates: 7641 (if approved) 5 Intended status: Standards Track 6 Expires: September 26, 2019 8 Accept-Any option for CoAP 9 draft-amsuess-core-accept-any-00 11 Abstract 13 This memoy defines the Accept-Any option, which provides a more 14 flexible content negotiation than the one originally specified for 15 the Constrained Application Protocol (CoAP) in [RFC7252]. As this is 16 particularly useful with but ruled out in CoAP observation 17 ([RFC7641]), that is updated to allow it. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 26, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 [ This document is being developed in git at 54 https://github.com/chrysn/accept-any [1]. ] 56 When CoAP content format defined in [RFC7252], the choice was made to 57 have the initial content negotiation allow the client to only pick 58 zero or one content format. This is a good choice for many 59 situations and ensures that proxies can cache as much as possible 60 without added complexity. A client that does not know a usable 61 content format would either leave the request field absent, 62 indicating it would accept any response, or try several acceptble 63 values in a series of requests. 65 In line with that choice, observation ([RFC7641]) required 66 notification responses to carry the same content format in the 67 notification as in the original response. 69 For applications that expect a representation to change its 70 representability to change during an observation's lifetime, 71 [I-D.ietf-core-multipart-ct] introduces a way of wrapping responses 72 in an application/multipart-core response. That approach is 73 convenient for bags of representations, but lacks actual content 74 negotiation and produces representations that are not directly usable 75 but need to be processed from inside the multipart representation. 77 This document introduces an additional way for the client to indicate 78 its set of acceptable content formats, and removes the same-content- 79 format limitation during observation. 81 2. The Accept-Any option 83 A new option Accept-Any is defined. It is critical [ I don't fully 84 see why but follow Accept here ], safe-to-foward and part of the 85 cache key. Its format is uint up to 2 long (indicating content 86 types), it is Class E in OSCORE, usable in requests only, and 87 repeatable 89 Repeatability is the only aspect in which it differs from Accept in 90 terms of option properties. 92 Its values indicate a list of acceptable representations in order of 93 decreasing preference. A server MUST answer with the first format it 94 can represent the requested state in, or 4.06 (Not Acceptable) if it 95 could answer successfully but the response would not match any of the 96 option values. 98 The Accept-Any option MUST NOT be used exactly once; that request's 99 meaning would be identical to that of a single Accept option. 100 Instead, a single Accept option is used. 102 2.1. Proxy behavior 104 A proxy MAY ignore this option per its properties (and serve a cached 105 response if the cache key matches), but can implement additional 106 behavior to enhance its cache. 108 A proxy is allowed to serve a cached representation to a request with 109 a different sequence of Accept-Any options, provided the second 110 request has an Accept value of the cached representation, or all the 111 content formats that precede the available content format in the 112 second request's Accept-Any options also preceded the available 113 representation in any earlier (fresh) request's list. 115 When a request that carries Accept-Any is answered 4.06 (or with any 116 but the first format requested by Accept-Any in its Content-Format), 117 a proxy SHOULD [ we can't have a MUST here w/o making it non-safe-to- 118 forward, but I think it's sufficient ] invalidate all known 119 representations in any of the requested formats (or the formats 120 preceeding the returned one, respectively). 122 3. Update to RFC7641 124 3.1. Changed behavior 126 The requirement that subsequent notifications carry the same Content- 127 Format option as the original response ([RFC7641] Section 3.2) is 128 lifted. 130 3.2. Rationale 132 Observing resources whose available representations changed is a key 133 featuer of Accept-Any, and necessary to implement pub-sub topics that 134 have no initial value (but a "null" representation with a dedicated 135 content format) without losing content negotiation and direct 136 usability of the response. 138 The requirement was introduced initially before such content 139 negotiation was thought of, and is not a necessary part to the 140 remainder of the observation document. 142 As long as the limitation is in place, the origin server has no clear 143 action guidance when its resource changes the available content 144 formats (see below). 146 3.3. Impact 148 Changes to the returned media type can either happen when 150 o Accept-Any was sent in the request - in which case both server and 151 client know the updated rules, or 153 o no Accept header was sent - in which case the server whose 154 representation changes to require a new content format has no 155 clear way of indicating that under [RFC7641] (ending with 4.06 Not 156 Acceptable would be close but isn't the expected response to a 157 repeated request); if the server changes the content format in a 158 notification to an unaware client, the client would catch it as a 159 bad response (probably similar to a response with a Content-Format 160 not matching the sent Accept). The client might regard the 161 observation as being aborted while the server does not, and will 162 terminate the observation with a RST on the next notification (or 163 close the connection in TCP). 165 Applications are still free to require constant content formats; 166 clients would treat what could previously be treated as a protocol 167 error would now treat it as an application error. 169 Impact on proxies: A proxy that enforces the previous rule on 170 Content-Format staying constant would close observations (probably 171 with something like 5.02 Bad Gateway), and the client would need to 172 re-establish. No proxy implementations are known that implement that 173 behavior. 175 4. References 177 4.1. Normative References 179 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 180 Application Protocol (CoAP)", RFC 7252, 181 DOI 10.17487/RFC7252, June 2014, 182 . 184 [RFC7641] Hartke, K., "Observing Resources in the Constrained 185 Application Protocol (CoAP)", RFC 7641, 186 DOI 10.17487/RFC7641, September 2015, 187 . 189 4.2. Informative References 191 [I-D.ietf-core-multipart-ct] 192 Fossati, T., Hartke, K., and C. Bormann, "Multipart 193 Content-Format for CoAP", draft-ietf-core-multipart-ct-03 194 (work in progress), March 2019. 196 4.3. URIs 198 [1] https://github.com/chrysn/accept-any 200 Appendix A. Open questions 202 o We could just as well make Accept repeatable with the same 203 semantics as Accept-Any. 205 o Is there any value in having an Accept-All option in parallel to 206 this option that asks for a multipart response that contains all 207 the representations? 209 Author's Address 211 Christian Amsuess 212 Hollandstr. 12/4 213 1020 214 Austria 216 Phone: +43-664-9790639 217 Email: christian@amsuess.com