One document matched: draft-ietf-core-observe-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<rfc ipr="trust200902" docName="draft-ietf-core-observe-00"
category="std" >
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes" ?>
<front>
<title abbrev="CoAP-observe">
Observing Resources in CoAP
</title>
<author initials="K" surname="Hartke" fullname="Klaus Hartke" role="editor">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63905</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>hartke@tzi.org</email>
</address>
</author>
<author initials="Z" surname="Shelby" fullname="Zach Shelby">
<organization>
Sensinode
</organization>
<address>
<postal>
<street>Kidekuja 2</street>
<city>Vuokatti</city>
<code>88600</code>
<country>FINLAND</country>
</postal>
<phone>+358407796297</phone>
<email>zach@sensinode.com</email>
</address>
</author>
<!--
<author initials="C" surname="Bormann" fullname="Carsten Bormann">
<organization>Universität Bremen TZI</organization>
<address>
<postal>
<street>Postfach 330440</street>
<city>Bremen</city>
<code>D-28359</code>
<country>Germany</country>
</postal>
<phone>+49-421-218-63921</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>cabo@tzi.org</email>
</address>
</author>
-->
<date year="2010"/>
<area>General</area>
<workgroup>CoRE Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
The state of a resource can change over time. We want to give clients of
the CoRE WG CoAP protocol the ability to observe this change.
This short I-D provides a design for such an addition to CoAP.
</t>
</abstract>
</front>
<middle>
<section anchor="introduction" title="Introduction">
<t>The state of a resource can change over time. We want to give CoAP
<xref target="I-D.ietf-core-coap"/> clients the ability to observe this change.</t>
<t>This short I-D describes an architecture and a protocol design that
realizes the well-known subject/observer design pattern within the
REST-based <xref target="REST"/> environment of CoAP.</t>
<t>In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”,
“SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL”
are to be interpreted as described in BCP 14 <xref target="RFC2119"/> and indicate
requirement levels for compliant CoAP implementations.</t>
</section>
<section anchor="architecture" title="Architecture">
<t>The architecture is based on the well-known subject/observer design
pattern. In this pattern, an object, called the subject, maintains
a list of interested parties, called observers, and notifies them
automatically when a predefined condition occurs.</t>
<t>In the context of CoAP, the subjects are resources. A subscription
to a resource causes the CoAP server to continuously supply an CoAP
client with the state of the resource: once upon subscription and
then whenever the state of the resource changes.</t>
<t>As with the existing REST methods, this architecture is about
exchanging representations of resources, not about the messages
(or method calls).</t>
<section anchor="subscriptions" title="Subscriptions">
<t>A client subscribes to a resource by performing a GET request that
includes the Subscription-lifetime Option (<xref target="option"/>). A subscription request MAY include a Token Option, which will then be included in all subsequent notifications. For robustness, a subscription has to be maintained through periodic
refreshing. If a subscription is not refreshed, it MUST end after the
duration that is negotiated using the Subscription-lifetime Option.
A client refreshes a subscription by repeating the original GET request
before the subscription lifetime expired.</t>
</section>
<section anchor="notifications" title="Notifications">
<t>Upon subscription, an observer MUST be supplied with the current state
of the resource. For efficiency, this initial notification MAY be sent
within the same message that acknowledges the subscription request.</t>
<t>The client is notified of resource state changes by additional responses
sent from the server to the client. Each such notification response MUST
include either the request URI or Token Option, and the remaining subscription lifetime.</t>
<t>It is not necessary that a subscribed client receives every single
notification response, or that the server sends a notification response
for every single state change. However, the state observed by an observer
SHOULD eventually become consistent with the actual state of the observed
resource.</t>
<t>The representation format (i.e. the media type) used during the lifetime
of a subscription MUST NOT change. If the server is unable to continue
sending notification responses to a client in the requested representation
format, it MUST send a response with code 406 (Not Acceptable) and end
the subscription.</t>
<t>A server MUST NOT send any further notification responses after sending a
response with code 4xx or 5xx, i.e. the subscription MUST end.
(Note: a client must be prepared to receive additional notification
responses after receiving such a response. In this case, it MUST handle
them like a subscription notification that it cannot relate to a
subscription.)</t>
<t>For resources that change in a somewhat predictable or regular fashion.
it is RECOMMENDED that a notification message is non-confirmable. For
robustness, a server MAY instead request the acknowledgment of a notification
response from a client by marking it as confirmable. (For example, in
order to check if the client is still there, or to make sure that an
observer observes a particular resource state.) If a
confirmable notification requires a retransmission, it is RECOMMENDED
to send the state that is current at the instant of the
retransmission; it is NOT RECOMMENDED to have multiple such
confirmable notification transactions active for one resource/client
pair at any one instant.</t>
<t>If a client cannot relate a confirmable notification response to a
subscription, it MUST reject the message with a RST (in which case the
server MUST end the subscription). Otherwise, it MUST acknowledge the
message with an ACK.</t>
</section>
</section>
<section anchor="option" title="Subscription-lifetime Option">
<texttable>
<ttcol align='right'>Type</ttcol>
<ttcol align='left'>C/E</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Data type</ttcol>
<ttcol align='left'>Length</ttcol>
<ttcol align='left'>Default</ttcol>
<c>10</c>
<c>E</c>
<c>Subscription-lifetime</c>
<c>Variable-length unsigned integer (<xref target="integer"/>)</c>
<c>0-4 B</c>
<c>0</c>
</texttable>
<t>The Subscription-lifetime Option, when present, modifies the GET method
so it does not only retrieve a representation of the current state
of the resource identified by the request URI once, but also lets the
server notify the client of changes to the resource state for the duration
specified in the option.</t>
<t>(Note: since the Subscription-lifetime Option is elective, the GET request
that includes the Subscription-lifetime Option will automatically fall back
to a simple GET request if the server does not support subscriptions.)</t>
<t>In a response, the Subscription-lifetime Option indicates a
lower bound (e.g., by rounding down) for the remaining subscription lifetime.
(Note that the server can always choose to cut short the subscription
lifetime before it echoes this lifetime back in an ACK or a
confirmable response.)</t>
<section anchor="example" title="Example">
<figure anchor="client-server-con-tid47-get-foo-lifetime60s-ack-tid47-200-foo-the-uri-is-actually-elided-temp-as-it-is-implied-by-the-tid-time-passes-non-tid153-here-the-server-decides-200-foo-it-will-send-updates-often-temp-enough-that-a-non-confirmable-message-is-sufficient-time-passes-con-tid783-here-the-server-decides-200-foo-to-send-a-confirmable-message-temp-as-the-time-to-the-next-update-is-not-certain-yet-ack-tid783-and-so-on"><artwork><![CDATA[
Client Server
| |
| CON tid=47 |
| GET /foo |
| lifetime=60s |
+---------------->|
| |
| ACK tid=47 |
| 200 /foo | (The URI is actually elided
| "<temp... | as it is implied by the TID.)
|<----------------+
| |
... Time Passes ...
| |
| NON tid=153 | Here, the server decides
| 200 /foo | it will send updates often
| "<temp... | enough that a non-confirmable
|<----------------+ message is sufficient.
| |
... Time Passes ...
| |
| CON tid=783 | Here, the server decides
| 200 /foo | to send a confirmable message
| "<temp... | as the time to the next update
|<----------------+ is not certain yet.
| |
| ACK tid=783 |
+---------------->|
| | ... and so on...
]]></artwork></figure>
</section>
</section>
<section anchor="open-issues" title="Open issues">
<t>Add discussion of messages that get reordered.</t>
<t>Add discussion of how to handle the influence of datagram latency on
subscription lifetimes.</t>
<t>Describe how subscriptions interact with other CoAP features (e.g., the
Block Option, caching, etc.).</t>
<t>Describe how to map subscriptions to HTTP long-polls, WebSockets, and other
asynchronous forms of HTTP.</t>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>Carsten Bormann was an original author of this draft and is acknowledged for significant contribution to this document. This work was partially funded by the Klaus Tschira Foundation.</t>
</section>
</middle>
<back>
<references title='Normative References'>
<reference anchor='RFC2119'>
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1997' month='March' />
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<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
RFC 2119.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
<format type='HTML' octets='17491' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
</reference>
<reference anchor='I-D.ietf-core-coap'>
<front>
<title>Constrained Application Protocol (CoAP)</title>
<author initials='Z' surname='Shelby' fullname='Zach Shelby'>
<organization />
</author>
<author initials='B' surname='Frank' fullname='Brian Frank'>
<organization />
</author>
<author initials='D' surname='Sturek' fullname='Don Sturek'>
<organization />
</author>
<date month='September' day='27' year='2010' />
<abstract><t>This document specifies the Constrained Application Protocol (CoAP), a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications such as smart energy and building automation. These constrained nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while networks such as 6LoWPAN often have high packet error rates and a typical throughput of 10s of kbit/s. CoAP provides a method/response interaction model between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and content-types. CoAP easily translates to 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='Internet-Draft' value='draft-ietf-core-coap-02' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-02.txt' />
</reference>
</references>
<references title='Informative References'>
<reference anchor="REST" target="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">
<front>
<title>Architectural Styles and the Design of Network-based Software Architectures</title>
<author initials="R" surname="Fielding" fullname="Roy Fielding">
<organization>University of California, Irvine</organization>
</author>
<date year="2000" />
</front>
<annotation>(Seminal dissertation introducing the REST architectural style.)</annotation>
</reference>
</references>
<section anchor="datatypes" title="Data types">
<section anchor="integer" title="Variable-length unsigned integer">
<t>A <spanx style='verb'>Variable-length unsigned integer</spanx> is a non-negative integer that is
represented in network byte order and uses a variable number of bytes
as shown in <xref target="vlui"/>.</t>
<figure title="Variable length unsigned integer value format" anchor="vlui"><artwork><![CDATA[
Len = 0 (implies value of 0)
0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
Len = 1 | 0-255 |
+-+-+-+-+-+-+-+-+
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 2 | 0-65535 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Len = 3 is 24 bits, Len = 4 is 32 bits etc.
]]></artwork></figure>
</section>
</section>
</back>
</rfc>
<!-- LocalWords: CoAP BCP confirmable RST tid ACK Etags Etag wmf IANA Tschira
-->
<!-- LocalWords: datagram multicasting unsubscribe deduplicate unsubscribes
-->
<!-- LocalWords: workflow Unsubscribing metadata resubscription unicast CoRE
-->
<!-- LocalWords: WebSockets
-->
| PAFTECH AB 2003-2026 | 2026-04-23 09:01:15 |