One document matched: draft-li-core-coap-patience-option-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC7252 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.7252.xml'>
]>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc
category="std"
ipr="trust200902"
docName="draft-li-core-coap-patience-option-05">
<front>
<title abbrev="CoAP Patience Option">
CoAP Option Extension: Patience
</title>
<author initials="K." surname="Li" fullname="Kepeng Li">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<email>likepeng@huawei.com</email>
</address>
</author>
<author initials="B." surname="Greevenbosch" fullname="Bert Greevenbosch">
<organization abbrev="Huawei Technologies">Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Base, Bantian, Longgang District</street>
<city>Shenzhen</city>
<region>Guangdong</region>
<code>518129</code>
<country>P. R. China</country>
</postal>
<email>bert.greevenbosch@huawei.com</email>
</address>
</author>
<author initials="E." surname="Dijk" fullname="Esko Dijk">
<organization abbrev="Philips Research">Philips Research</organization>
<address>
<postal>
<street>High Tech Campus 34</street>
<city>Eindhoven</city>
<country>The Netherlands</country>
</postal>
<email>esko.dijk@philips.com</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization abbrev="Ericsson">Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<city>Jorvas 02420</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<date year="2014" />
<area>Applications</area>
<workgroup>core</workgroup>
<abstract>
<t>
CoAP is a RESTful application protocol for constrained nodes and
networks. This specification provides a simple extension for
CoAP, the Patience option. This option is used by a CoAP client to indicate
the maximum time a client is prepared to wait for a response.
The CoAP server should try to return
the response within the specified time frame.
</t>
</abstract>
<note title="Note">
<t>
Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.
</t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
This specification adds a new Patience option to CoAP <xref target='RFC7252' />.
The main purpose is for the client to inform the server of the preferred time frame for a
response. It is used in a request to indicate the client patience in waiting for
a response. It then indicates "a response is most
useful within the specified time frame".
</t>
<section anchor="just" title="Justification">
<t>
It can be useful for the client to indicate that
the response is required to be returned within a certain amount of time.
For example, the client could require a response within 2 seconds,
otherwise the response is not of interest anymore.
With this indication of the patience for a response,
the client knows how long it should wait for the response, and it
needs to keep the state of the request only for the indicated
time. After this period, the request will be given up. It can avoid that
the server wastes resources by sending a
response which already exceeds the set patience timeout of the client.
</t>
<t>
If the Patience option is combined with Observe option in a request,
it indicates the maximum time an observer is prepared to wait for an
initial notification.
</t>
</section>
<section anchor="terms" title="Terminology">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in <xref target='RFC2119' />.
</t>
</section>
</section>
<section anchor="Patience" title="Patience Option Extension">
<section anchor="Definition" title="Patience Option Definition">
<texttable>
<ttcol align="left">No.</ttcol>
<ttcol align="left">C</ttcol>
<ttcol align="left">U</ttcol>
<ttcol align="left">N</ttcol>
<ttcol align="left">R</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Format</ttcol>
<ttcol align="left">Length</ttcol>
<ttcol align="left">Default</ttcol>
<c>28</c>
<c></c>
<c></c>
<c>x</c>
<c></c>
<c>Patience</c>
<c>integer</c>
<c>1-2 B</c>
<c>none</c>
</texttable>
<t>
The value of the Patience option is measured in seconds.
The range is from 1 second to 2^16 seconds, that is, 65535 seconds, around 18 hours.
There is no default value for the Patience option.
</t>
<t>
The Patience option is "elective". It MUST NOT occur more than once.
</t>
</section>
<section anchor="Usage" title="Using the Patience Option">
<t>
In the unicast case, this option is used by a CoAP client to indicate
the maximum time a client is prepared to wait for a response.
</t>
<t>
The client adds the Patience option to any request
for which it is prepared to wait for a response.
The client sets the option to the maximum time that it is
prepared to wait.
</t>
<t>The Patience option applies to both a piggy-backed response
and a separate response. For a separate response, the patience
applies to the actual response, not to the ACK. The ACK should
be sent immediately upon receipt of the CON message.
</t>
<t>
TBD: In case a client retransmits a request, the Patience Option value
MAY be decreased by an amount of time equivalent to the time since the
previous transmission attempt. In case a client did not receive
an ACK to a confirmable request and a time interval of at least the
interval indicated in the Patience Option of the request has passed,
the client SHOULD give up the request.
</t>
<t>
The server interprets this option as the maximum time between receipt
of the complete request and the time that it begins
sending the response.
The client will observe a longer time interval
between request and response, as network transit and processing by
proxies add delays.
If timing is critical,
the client SHOULD consider the possible delays and choose the value
for the option accordingly.
</t>
<t>
The server MAY apply a lower value to the patience timeout based on
local policy. A server MAY choose to take longer to produce
a response, at the risk that the client is no longer able to use the
response.
</t>
<t>
In case that the CoAP message is transmitted through a proxy,
the Proxy MAY reduce the value of a Patience option
based on a local policy (e.g. to consider the maximum time that
an idle connection is kept open by a local NAT or Firewall).
A Proxy MAY add a Patience
option if none is present. The value in the Patience option
MUST NOT be increased or removed.
</t>
<t>
If the client does not receive a response
within the indicated response time, the client SHOULD consider the
request as failed.
If the server can't provide a response within the required time, the
server SHOULD discard the request.
</t>
</section>
</section>
<section anchor="example" title="Example">
<t>
This section gives a short example with a message flow that
illustrates the use of the Patience option in a GET request.
</t>
<t>
This example (<xref target="PatienceExample"/>) shows that the
client wants to get a response within 60 seconds.
</t>
<figure title="Patience Option in a unicast request" anchor="PatienceExample">
<artwork> <![CDATA[
client server
| |
| |
+-------->| Header: GET (T=CON, Code=1, MID=0x7d38)
| GET | Token: 0x53
| | Patience: 60
| | Uri-Path: "temperature"
| |
|<--------+ Header: 2.05 Content (T=ACK, Code=69, MID=0x7d38)
| 2.05 | Token: 0x53
| | Payload: "22.3 C"
| |
]]>
</artwork>
</figure>
</section>
<section anchor="security" title="Security Considerations">
<t>
This presents no security considerations beyond those in
section 10 of the base CoAP specification
<xref target='RFC7252' />.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
The IANA is requested to add the following "CoAP Option Numbers" entry
as per Section 12.2 of <xref target='RFC7252'/>.
</t>
<texttable>
<ttcol align="left">No.</ttcol>
<ttcol align="left">C</ttcol>
<ttcol align="left">U</ttcol>
<ttcol align="left">N</ttcol>
<ttcol align="left">R</ttcol>
<ttcol align="left">Name</ttcol>
<ttcol align="left">Format</ttcol>
<ttcol align="left">Length</ttcol>
<ttcol align="left">Default</ttcol>
<c>28</c>
<c></c>
<c></c>
<c>x</c>
<c></c>
<c>Patience</c>
<c>(ref to this document)</c>
<c>1-2 B</c>
<c>(none)</c>
</texttable>
</section>
<section anchor="acknowledgement" title="Acknowledgements">
<t>
The authors of this draft would like to thank the participants of the
email discussion on this issue.
Thanks to Carsten Bormann, Peter Bigot, Barry Leiba, Linyi Tian, Gengyu Wei for
the reviews and discussions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC7252;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 20:48:55 |