<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version  -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>


<rfc docName="draft-amsuess-core-accept-any-00" category="std" updates="7641">

  <front>
    <title>Accept-Any option for CoAP</title>

    <author initials="C." surname="Amsüss" fullname="Christian Amsüss">
      <organization></organization>
      <address>
        <postal>
          <street>Hollandstr. 12/4</street>
          <code>1020</code>
          <country>Austria</country>
        </postal>
        <phone>+43-664-9790639</phone>
        <email>christian@amsuess.com</email>
      </address>
    </author>

    <date year="2019" month="March" day="25"/>

    
    <workgroup>CoRE</workgroup>
    <keyword>CoAP, observe</keyword>

    <abstract>


<t>This memoy defines the Accept-Any option,
which provides a more flexible content negotiation than the one originally specified
for the Constrained Application Protocol (CoAP) in <xref target="RFC7252"/>.
As this is particularly useful with but ruled out in CoAP observation (<xref target="RFC7641"/>),
that is updated to allow it.</t>



    </abstract>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>[ This document is being developed in git at <eref target="https://github.com/chrysn/accept-any">https://github.com/chrysn/accept-any</eref>. ]</t>

<t>When CoAP content format defined in <xref target="RFC7252"/>,
the choice was made to have the initial content negotiation allow the client to only pick zero or one content format.
This is a good choice for many situations
and ensures that proxies can cache as much as possible without added complexity.
A client that does not know a usable content format would either leave the request field absent,
indicating it would accept any response,
or try several acceptble values in a series of requests.</t>

<t>In line with that choice,
observation (<xref target="RFC7641"/>) required notification responses
to carry the same content format in the notification as in the original response.</t>

<t>For applications that expect a representation to change its representability to change during an observation’s lifetime,
<xref target="I-D.ietf-core-multipart-ct"/> introduces a way of wrapping responses in an application/multipart-core response.
That approach is convenient for bags of representations,
but lacks actual content negotiation
and produces representations that are not directly usable
but need to be processed from inside the multipart representation.</t>

<t>This document introduces an additional way for the client to indicate its set of acceptable content formats,
and removes the same-content-format limitation during observation.</t>

</section>
<section anchor="the-accept-any-option" title="The Accept-Any option">

<t>A new option Accept-Any is defined. It is critical [ I don’t fully see
why but follow Accept here ], safe-to-foward and part of the cache key.
Its format is uint up to 2 long (indicating content types), it is Class
E in OSCORE, usable in requests only, and repeatable</t>

<t>Repeatability is the only aspect in which it differs from Accept in
terms of option properties.</t>

<t>Its values indicate a list of acceptable representations in order of
decreasing preference. A server MUST answer with the first format it can
represent the requested state in, or 4.06 (Not Acceptable) if it could
answer successfully but the response would not match any of the option
values.</t>

<t>The Accept-Any option MUST NOT be used exactly once;
that request’s meaning would be identical to that of a single Accept option.
Instead, a single Accept option is used.</t>

<section anchor="proxy-behavior" title="Proxy behavior">

<t>A proxy MAY ignore this option per its properties
(and serve a cached response if the cache key matches),
but can implement additional behavior to enhance its cache.</t>

<t>A proxy is allowed to serve a cached representation to a request with a different
sequence of Accept-Any options, provided the second request has an
Accept value of the cached representation, or all the content formats
that precede the available content format in the second request’s
Accept-Any options also preceded the available representation in any
earlier (fresh) request’s list.</t>

<t>When a request that carries Accept-Any is answered 4.06 (or with any
but the first format requested by Accept-Any in its Content-Format), a proxy SHOULD [ we
can’t have a MUST here w/o making it non-safe-to-forward, but I think
it’s sufficient ] invalidate all known representations in any of the
requested formats (or the formats preceeding the returned one,
respectively).</t>

</section>
</section>
<section anchor="update-to-rfc7641" title="Update to RFC7641">

<section anchor="changed-behavior" title="Changed behavior">

<t>The requirement that subsequent notifications carry the same
Content-Format option as the original response (<xref target="RFC7641"/> Section 3.2) is lifted.</t>

</section>
<section anchor="rationale" title="Rationale">

<t>Observing resources whose available representations changed is a key featuer of Accept-Any,
and necessary to implement pub-sub topics that have no initial value
(but a “null” representation with a dedicated content format)
without losing content negotiation and direct usability of the response.</t>

<t>The requirement was introduced initially before such content negotiation was thought of,
and is not a necessary part to the remainder of the observation document.</t>

<t>As long as the limitation is in place,
the origin server has no clear action guidance
when its resource changes the available content formats
(see below).</t>

</section>
<section anchor="impact" title="Impact">

<t>Changes to the returned media type can either happen when</t>

<t><list style="symbols">
  <t>Accept-Any was sent in the request – in which case both server and
client know the updated rules, or</t>
  <t>no Accept header was sent – in which case the server whose
representation changes to require a new content format has no clear
way of indicating that under <xref target="RFC7641"/> (ending with 4.06 Not Acceptable
would be close but isn’t the expected response to a repeated request);
if the server changes the content format in a notification to an
unaware client, the client would catch it as a bad response (probably
similar to a response with a Content-Format not matching the sent
Accept). The client might regard the observation as being aborted while the
server does not, and will terminate the observation with a RST on the
next notification (or close the connection in TCP).  <vspace blankLines='1'/>
Applications are still free to require constant content formats;
clients would treat what could previously be treated as a protocol error
would now treat it as an application error.</t>
</list></t>

<t>Impact on proxies: A proxy that enforces the previous rule on
Content-Format staying constant would close observations (probably with
something like 5.02 Bad Gateway), and the client would need to
re-establish. No proxy implementations are known that implement that
behavior.</t>

</section>
</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC7252" target='https://www.rfc-editor.org/info/rfc7252'>
<front>
<title>The Constrained Application Protocol (CoAP)</title>
<author initials='Z.' surname='Shelby' fullname='Z. Shelby'><organization /></author>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<author initials='C.' surname='Bormann' fullname='C. Bormann'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks.  The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s.  The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation.</t><t>CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.  CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments.</t></abstract>
</front>
<seriesInfo name='RFC' value='7252'/>
<seriesInfo name='DOI' value='10.17487/RFC7252'/>
</reference>



<reference  anchor="RFC7641" target='https://www.rfc-editor.org/info/rfc7641'>
<front>
<title>Observing Resources in the Constrained Application Protocol (CoAP)</title>
<author initials='K.' surname='Hartke' fullname='K. Hartke'><organization /></author>
<date year='2015' month='September' />
<abstract><t>The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks.  The state of a resource on a CoAP server can change over time.  This document specifies a simple protocol extension for CoAP that enables CoAP clients to &quot;observe&quot; resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time.  The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server.</t></abstract>
</front>
<seriesInfo name='RFC' value='7641'/>
<seriesInfo name='DOI' value='10.17487/RFC7641'/>
</reference>




    </references>

    <references title='Informative References'>





<reference anchor="I-D.ietf-core-multipart-ct">
<front>
<title>Multipart Content-Format for CoAP</title>

<author initials='T' surname='Fossati' fullname='Thomas Fossati'>
    <organization />
</author>

<author initials='K' surname='Hartke' fullname='Klaus Hartke'>
    <organization />
</author>

<author initials='C' surname='Bormann' fullname='Carsten Bormann'>
    <organization />
</author>

<date month='March' day='8' year='2019' />

<abstract><t>This memo defines application/multipart-core, an application- independent media-type that can be used to combine representations of zero or more different media types into a single message, such as a CoAP request or response body, with minimal framing overhead, each along with a CoAP Content-Format identifier.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-core-multipart-ct-03' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-core-multipart-ct-03.txt' />
</reference>




    </references>


<section anchor="open-questions" title="Open questions">

<t><list style="symbols">
  <t>We could just as well make Accept repeatable with the same semantics as Accept-Any.</t>
  <t>Is there any value in having an Accept-All option in parallel to this option
that asks for a multipart response that contains all the representations?</t>
</list></t>

</section>


  </back>

<!-- ##markdown-source:
H4sIAKnXmFwAA31YXW8buRV9569g0wfbrUZ2nGyCOG23rjfpGuiuA8fBougu
CmqGkrieIackx7Ia+J/1rX+s516S0ki2awSIx8O5vB/nnnvIqqpENLHVZ/K8
rnUfq3O7lq6Pxlk5d15euPNPonG1VR3WNF7NY6W6MOgQqtp5Xan0mbLr6uRE
hKhs80/VOovV0Q9a1CqeyRAbsVqcwdr1BzH0jYo6nMm3b16/FLerM95kIt0s
aH+nhRri0vkzUUljsepiKs+78N//hCCkTG5cLL0J0Sg7ehOi1xpbfe/aFj7g
cSpfnh6/xqvaNfjo4OXJ6ckBPw42+jUiHrDKKPypX7LDL37/+lX15s3r6t3b
dydvXr17gVe6U6Y9k3XZ8s85+mntOmGd71Q0d/pMGDvfPoiqqqSawbyqoxA3
SxNkpzu3lo2eG6uDjEv9OOMTsVqaeil77+5Mg1VKdsixnLf63sxaDddt1DZK
qxcOznCV4lJZNocQpPNmYaxq27UMva7N3OhGUB1pwYWz5BH2b+R537emThY+
eRdd7Vp5SIU4Qtrl16+/uf548fb0m9OHh6k4J38RAv71ykdTD63y2GIIej60
cmXiUs6GKP3QwrTDbzBBtnJN0zaH2Siq/vBwNBFwPJLJhIdGRifhuFtJE6cp
g51pmlYL8Vt5iYq5ZqjJkBA//0NySoHLoaN84PeZNnaB9N7p1vWwBg8WJkps
8YdljH04Oz7G83KYUeGOUc51sMdb8P5pKn/+RYifljp7XlKdqprr1uznhqJA
WZbO1FquFKqsGk2RLNWd5qQba1Cp9snSpXDZQmvoJT50FontTX0r/609Hj3X
ddebaUKUIYAsnGuKA1ToDsHIYOLAWwSBXpDahsEz6BAJwHVv8FADNrWqsTm5
PQB2+L93ITDSqKZUSNU0iBop6wmDcQ0wbJwla42DKeuivLUIRQESagzUnL2V
G1q4AZvay1aX3Hj9L7QSVhmN1+gXfDJBJzWMTJTTlE9ToSTFhkB6BKYngmDt
ESxq7pHhtIZ2v1Mt7FKtFN56itbNy24B4Lq0skU5E3I5jpRB2HwWsPy98cgG
wkVj5eYp7gSB4tXKwyEKLYCo9rNgUp/ufK5C+XNp3Y1F+PkRIaptp+YK6nu0
NpKBlT0WY4fMBHAAZLAA6GIYvZyZFpUbvW4GT9kFAEbhHgTkZK6j6ZCGr1+/
vay+mxod54nmu6GNhpq/quPDA3xO/cgctVJryu/Kw1Wyu0kJV8COIzge2SFm
28Z6Q5FhpXfAJEEbybvT1uT8yZla5CqOYw4TQcTTqvoWntRA/ZOdxl3QF4/3
TKSkKs+VkQ1KXEcmN0Iym7c60dNMkxGYCHiee9fRhDJNAvMmsj3708z/W7Ia
5c5SgxlaBscpj4Wrt4SQ2yEVNehISUhQf6LTkA8K1WPW3OUpQ0is8qoqI7E1
ncmgyVgYAQEOw+MnxpP44zM/AqRg9arohtGHFHdizqm8ZJ6uPcKtES1I/BJJ
sQfwfeCBpTXm35onydwxNSZLEqyhQc8TxDLXVXQIY6U8WIGqShlHSjhpTGe3
Gix1iWSVtsOIQc4xZyidpxLiZCEPRyxTUhjXvQ5HE2IdfHPRKgiLD4Thq88X
V9cfJoXcjN1wCdP1RKac91pxTYS4zr+nxjMhz2cEqQL3LkykUW8IcfO59iEB
KkdsrIjad4z4nFUgr9cYvpoJDFtvWC7jQ6GsYR8e+1jHxs43YGE3F42uvVaB
UoBF8EHbWkNtSdZhXv7w5fMNQgsr/J6ZEjPG+LBltEhjRGw2GbM6WgRqkHBr
JzTGXk9P3sjDH9Fi5xv3oDXmbIRIXuStwlBTiyVQEBiS0UQUeR5Qp8IBGlp2
XcqfUZryMn0GxCmqH69uqJsHamR9r7jhHaJ/n1RJDuGAVJuylKC0LT5Bu9sE
YICJF1PCJWWxLdvlrYBCCC6tmskzCxiacAG+QoPdI1oN3WCcJ/Uz+qH+6nnB
D+d/l2ZhiTpZkRVsIG1ED1uMiEPCJBcSm3NjNNskmr1+Sbkk8DPfkTQwNPGZ
r0YMVfyj2LXFMKkTLbGh6dZNUibUwIk2H3mxP7XURgkwzFRuCSwRgV7QNsjy
o1qGSZHKTaI6jVZuNsaWihhW5JQzLHaYYt8Vhin8Tit2eVVk7aRrnfle3eFg
8JTYyfN815mDIB67j82CK0abPat7aeJRuhYawtug2odzvFwejZBKzT/NCnab
0CRuIEtIBO0Sc2o37Js60+Ump11K1+00+7avZ+sdU5YxcJFHzEdefUSYT2D4
/P3Vl799R3y/ouMgET6rY5Vakcl9deyAwdus+ayz1ZbqPXH9hJngklBvb4Wh
gMMwh4ziMfnzL/ACBTYNEyFKSHLUPsV+W74Q24BykTkJHHd+5tLohtxKJBQH
T6cASPKJoG4Cl+PA166PaGh+4YMMATqrxscDU4gLlmDNc61OzX6TSRRKpNsI
7TDMUi/EHQEZ9jSn2C1DIQgVntaYuxpXftZ8wpKvpqdHBBEIwsj0dK0SA2gx
8vOKNUNWfG7wpGhWSxeeR3HICrRJZxdinjkG5cDzaISppGKspjmgPEvXLR/1
w6xCNvBHHJOyemNAWbc5bXGzi0PCjJIvLEbJi/2GKlSj0/hs9tr4SJQjUOvC
WCXsHODgZRKMrA3SuM8UM5Lx+wVdserPKrApTtO003Oi9kCnsaf2W3Ed3bBY
0thJWTLp/KVG6WJNxOOJ9u1w4k8TP2FgdMIpmpSoOyRhlJEyUoiG+6aHxtbp
uJtQVFQCsSwyX+NY50mC0yeLAZ0I1oae0zafRhJCMgDC/6VQTC+IQWQDI4Q6
67Lr6R6l4O6imHC7XdmhlIpVHE+wfNxc4lChSW5pK8TvxsRF2QxJke8cR6tq
q89qBTjPHKCSw0XK6Q4pyXM+9NKn5Q6DbkACzRHshKRs9KuiAmz2e7RBmhds
nxsIO+yhtd7GnJHEFV/tD59xNWAlH81GYpfbZWBA7LT+obbMc9wWPBF2pRoZ
KxqobqnJqblMIDon99OhdCwy8mAnJaw3c/DoPQxl+ZEjHiPi8ShVu+dlMmph
YrBqRUe2VIjJ+MyU3KxZHdINEDHNTI0cO8RcmiGmNV0bAuet8sXZIjITN+xx
6UZ0lnlA5YGNlKSjqbzZOtEZ6lGvF3RO2W87Va6r1Mx5Sg6g0DIKyKOUlXKx
kg4XK0OyBCcCsHfUjwxmf68xTvlGkOxYfb87Kni6pdLlVNtM90jzzcUn6jQ5
vhgMfCgOkfaG3NBj8NV0l6hs3O/c95vmCLkQEWcMFIV1CP8BuMbgGwLzXXqN
FHCZ+nITqb13fgM57jI2k+u5c6eQFm9oQqazEt1xnckiSNO9CV3R1hlpxQtu
WXyzPzgR3TrTfgo0w4rzN8p92MKJyyCC63RkiLTmVstvpien8i+A318RJtrx
KBX0EV7zHQNURYU2gTkTllP0YFHUZfyNKpM0TrpG3UxHehRFXOR71Jmqb+kW
9YqIkNuQrwbBUT/pXJRfh8CpXWkUG0psc1LZHmu3Z0C+3AoYLHQSCvTZllWn
ZPaSc0wcBZpNwhsYI5/StVNZjr3KScjS1MIQ1PlgtTncAAXpgibc8pGeLsVH
Vy2FbBK+kB/DurrNjL6jPr4V/wMXGO6q8BgAAA==

-->

</rfc>

