One document matched: draft-hartke-coap-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-hartke-coap-observe-00"
category="info" >
<?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">
<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-63908</phone>
<facsimile>+49-421-218-7000</facsimile>
<email>hartke@tzi.org</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" month="June" day="21"/>
<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 an example design for such an addition
to CoAP, in order to be able to discuss the design
alternatives in specific terms.
</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 provides an example design for such an addition
to CoAP, in order to be able to discuss the design
alternatives in specific terms.</t>
<section anchor="design-pattern" title="Design Pattern">
<t>Many designs are possible for the observe capability of CoAP.
So that we don’t end up with a random, arbitrary design, we base our
considerations 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
of any state changes.</t>
<t>There are a number of variants of that design pattern.
We like one that explicitly considers the way the
evolution of the resource state might end <xref target="DUAL"/>.
In detail, this variant of the design pattern consists of the following elements:</t>
<t><list style='symbols'>
<t>A <spanx style='emph'>subject</spanx>, which sends notifications to observers. It
has a single method, SUBSCRIBE, which is called by observers that wish to
receive notifications from the subject.</t>
<t>An <spanx style='emph'>observer</spanx>, which receives notifications from a subject.
It has three methods: YIELD, which supplies the observer with new or current
information; THROW, which informs the observer that the subject experienced
an error condition; and BREAK, which indicates that the subject has finished
sending notifications. The grammar of notifications to be expected over time
therefore is:</t>
</list></t>
<t><list style='empty'>
<t>YIELD* ( BREAK | THROW )?</t>
</list></t>
<t><list style='symbols'>
<t>A <spanx style='emph'>subscription</spanx>, which represents the interest of an
observer in a subject. It has a single method, UNSUBSCRIBE, which enables
the subject to unsubscribe observers when notification has finished.
Observers receive a reference to the subscription from the SUBSCRIBE method,
so they can also call the UNSUBSCRIBE method to unsubscribe before the
subject has finished sending notifications.</t>
</list></t>
<t>In this document, we describe an architecture and a protocol design
that realizes a meaningful rendition of this design pattern within the
REST-based <xref target="REST"/> environment of CoAP.</t>
</section>
<section anchor="architecture" title="Architecture">
<t>We interpret resources as the <spanx style='emph'>subjects</spanx> of the subject/observer
pattern. The <spanx style='emph'>subscription</spanx> causes the subject to continuously supply
an <spanx style='emph'>observer</spanx> with the state of the resource: once upon subscription
and then whenever the state of the resource changes. We call a CoAP node
offering a resource <spanx style='emph'>server</spanx>, and a CoAP node subscribing an observer to a
resource <spanx style='emph'>client</spanx>. As with the existing REST methods, this
architecture is about exchanging representations of resources, not
about the messages (or method calls).</t>
<t>The design is REST-based, as it maintains REST’s uniform interface and
its four interface constraints (<xref target="REST"/>, section 5.1.5):</t>
<t><list style='symbols'>
<t>Identification of resources by the uniform mechanism of URIs <xref target="RFC3986"/>;</t>
<t>Resource manipulation through the exchange of resource state representations;</t>
<t>Self-describing messages (potentially with multiple representation formats);</t>
<t>Hypermedia as the engine of application state: A server premediates
application state transitions by providing links in resources.;</t>
</list></t>
<t>While this is not a necessary implication of the design described
here, the assumption is that the subscription itself is modeled on the
level of conversation state, not as a resource by itself. (This, of
course, does not imply that there can’t be resources that help nodes
decide whether to create subscriptions, but these are
application-specific and outside the scope of CoAP.)</t>
</section>
</section>
<section anchor="requirements" title="Requirements">
<t>The requirements for implementing the subject/observer design pattern over
UDP stem largely from the the fact that UDP is an unreliable,
connectionless transport. This means that method calls must be expressed as
messages, that preparation must be taken for the case that messages arrive
out of order, appear duplicated, or go missing without notice, and that the
transport keeps no state between messages that can be utilized.</t>
<t>The detailed requirements that follow from this are:</t>
<t><list style='symbols'>
<t>An invocation of the SUBSCRIBE method on an observable resource is
implemented by sending a message (a subscription request) from the
subscribing client to the server that offers the resource. <vspace blankLines='1'/>
The client must be able to determine if a subscription request was received
by the server, and, if not, must be able to retransmit the request. <vspace blankLines='1'/>
The server must acknowledge the subscription request, and must be prepared
to receive duplicated subscription requests. <vspace blankLines='1'/>
Since subscribing can be made idempotent (<xref target="identify"/>), the
server need not be able to detect a duplicated subscription request as such. <vspace blankLines='1'/>
The client must be able to relate the acknowledgement to the subscription
request.</t>
<t>The usual considerations for retrieving the representation of a
resource in a REST-based protocol apply, e.g.: <vspace blankLines='1'/>
A subscribing client must be able to influence the representation format in
which the server supplies the resource state to the client.</t>
<t>Upon subscription, an observer must be supplied with the current state of
the resource in the requested format. <vspace blankLines='1'/>
If the observer cannot be supplied with the current state (for example,
because the resource does not exist, the state cannot be represented in
the requested format, the client lacks authorization, or a general error
condition occurred), the server must inform the client of the error
condition. <vspace blankLines='1'/>
For efficiency, this initial notification may be sent within the same
datagram that acknowledges the subscription request. <vspace blankLines='1'/>
The initial notification might not include the actual representation
(e.g., take the form of a “304 not modified”) if the client already
has a valid representation of the resource. The client should be
able to supply information (e.g., Etags or a modification date)
to enable the server to make this determination.</t>
<t>To take advantage of the multicast capabilities of the transport, it should
be possible to subscribe a UDP multicast group to a resource. In contrast to
subscribing multiple clients individually to the resource, the server in this
case must treat the multicast group as a single observer.</t>
<t>For robustness, a subscription has to be maintained through periodic
refreshing. If a subscription is not refreshed, its lifetime must end after
a certain duration that is negotiated as part of the message exchange that
implements the SUBSCRIBE method call. <vspace blankLines='1'/>
So a subscribing client must be able to specify a subscription lifetime
duration in a subscription request. A server must be able to return the
negotiated subscription lifetime duration back to the client. <vspace blankLines='1'/>
Since the client is responsible for taking care of the subscription, refreshing a
subscription must be implemented by sending a message (a subscription
refresh request) from the subscribed client to the server. <vspace blankLines='1'/>
The client must be able to determine if a subscription refresh request
was received by the server, and, if not, must be able to retransmit the request. <vspace blankLines='1'/>
The server must acknowledge the request. It must be prepared to receive
duplicated requests. It must be able to relate a refresh request to a
subscription. <vspace blankLines='1'/>
The client must be able to relate the acknowledgement to the subscription
refresh request. <vspace blankLines='1'/>
The server must be prepared for a refresh request to arrive after the
subscription expired. In this case, the subscription refresh request is
treated the same as a subscription request, since the client expressed the
desire to continue being subscribed to the resource.</t>
<t>For notifications, the equivalent of an invocation of the YIELD,
BREAK or THROW method on an
observer must be implemented by sending a notification message from the
server offering the resource to the subscribed client. <vspace blankLines='1'/>
The subscribed client must be able to relate a notification message to a
subscription and/or to a resource (see also <xref target="identify"/>). <vspace blankLines='1'/>
It is not a requirement that a subscribed client receives every single notification
messages sent by a server, or that the server sends a notification message
for every single state change. However, the state observed by an observer must
eventually become consistent with the actual state of the observed resource.</t>
<t>The representation format used during the lifetime of a subscription must
not change. If the server is unable to continue notifying a client in the
requested representation format, it must invoke the THROW method on the
observer.</t>
<t>A server must not send any further notification messages after sending a
notification message that denotes a BREAK or THROW. <vspace blankLines='1'/>
However, a client must be prepared to receive notification messages after
receiving such a notification message. (In this case, it discards
the excessive notification messages.)</t>
<t>For robustness, a server can request the acknowledgement of a notification
message from a client. (For example, in order to check if the client is
still there, or to make sure that an observer observes a particular resource
state.) Such a notification is called a <spanx style='emph'>confirmable</spanx> notification message. <vspace blankLines='1'/>
A server must be able to determine if a confirmable notification message was
received by the client, and, if not, must retransmit the message. <vspace blankLines='1'/>
If the client cannot relate the confirmable notification message to a
subscription, it must reject the message. Otherwise, it must acknowledge
the message. <vspace blankLines='1'/>
The server must be able to relate the acknowledgement or rejection to the
confirmable notification message. <vspace blankLines='1'/>
There is no support for multicasting confirmable notification messages.</t>
<t>To end a subscription before the lifetime of the subscription
expires (UNSUSBCRIBE method), a message (an ‘unsubscribe’ request)
can be sent from the subscribed client to the server that maintains
the subscription. <vspace blankLines='1'/>
The client must be able to determine if an ‘unsubscribe’ request was
indeed received by the server, and, if not, must be able to
retransmit the request. <vspace blankLines='1'/>
The server must acknowledge the ‘unsubscribe’ request, and must be prepared
to receive duplicated requests (which also need to be acknowledged). <vspace blankLines='1'/>
The client must be able to relate the acknowledgement to the request.</t>
</list></t>
<t>Note that, in a REST-based environment, all these message exchanges
should also work correctly through proxies.</t>
</section>
<section anchor="the-design" title="The Design">
<section anchor="state" title="State">
<t>The state required on nodes as indicated by the requirements, can be summarized
as follows:</t>
<t><list style='symbols'>
<t>Nodes that send requests must keep track of pending requests.
(For non-idempotent requests, the node that receives the request
also must retain state to deduplicate requests.)</t>
<t>A server offering a resource must keep track of the observers of the
resource. Similarly, a proxy must keep track of the observers that
observe a resource through that proxy.</t>
<t>Due to the initial notification of an observer upon subscription, the server
must also keep track the resource state itself. (It cannot just notify all
observers when the state changes and then immediately forget the state.)</t>
<t>A client subscribed to a resource may have to keep track of the
subscriptions to the resource in order to be able to relate
notifications to the subscription and in order to be able to refresh
the subscription before the subscription lifetime ends (<xref target="identify"/>).</t>
<t>A client (or a proxy) may optionally keep a cache of resource states.</t>
</list></t>
</section>
<section anchor="subscription-lifetime" title="Subscription Lifetime">
<t>To summarize, the lifetime of a subscription begins with a subscription
request, and it ends when</t>
<t><list style='symbols'>
<t>the subscription lifetime expires (as defined by the subscription duration
option in the subscription request),</t>
<t>the client unsubscribes from the resource,</t>
<t>the client rejects a request related to a subscription,</t>
<t>an error condition related to a subscription occurred, or</t>
<t>the observed resource has finished sending notifications.</t>
</list></t>
<t>A client can extend the lifetime of a subscription before its end by sending
a subscription refresh request.</t>
</section>
<section anchor="messages" title="Messages">
<t>The following message types and elements can be gathered from the requirements.</t>
<section anchor="requests" title="Requests">
<t>Requests are messages that need to be acknowledged by the
recipient. As with other request in CoAP, they are retransmitted by
the sender using an exponential back-off delay until the
acknowledgment is received.</t>
<t>The request message types as indicated by the requirements can be summarized
as follows:</t>
<t><list style='symbols'>
<t>A SUBSCRIBE request creates a new subscription or refreshes an existing
subscription.</t>
<t>An UNSUBSCRIBE request ends an existing subscription.</t>
</list></t>
<t>To put this into perspective, the existing GET, PUT, POST and DELETE messages
have request semantics as well.</t>
<t><list style='symbols'>
<t>A GET request retrieves a representation of the current resource state.</t>
<t>A PUT request provides a new resource state in some representation format.</t>
<t>A POST request creates or extends a resource.</t>
<t>A DELETE request deletes a resource.</t>
</list></t>
<t>A request message includes a <spanx style='emph'>transaction identifier</spanx> which allows the
recipient to detect duplicated requests and, by inclusion of the transaction
identifier in the acknowledgement to the request, enables the sender to
relate the acknowledgement to the request.</t>
</section>
<section anchor="replies" title="Replies">
<t>Replies are messages that are sent in reply to a request. They carry the
aforementioned transaction identifier.</t>
<t>The reply messages types as indicated by the requirements can be summarized
as follows:</t>
<t><list style='symbols'>
<t>An ACK reply indicates an acknowledgement of a request.</t>
<t>A RST reply indicates the rejection of a request.</t>
</list></t>
<t>(Responses in CoAP are replies that may carry a resource representation.)</t>
</section>
<section anchor="notifications" title="Notifications">
<t>Matching the methods of an observer, the notification message types can be
summarized as follows:</t>
<t><list style='symbols'>
<t>A YIELD notification supplies the subscribed client with the state
of a resource in some representation.</t>
<t>A BREAK notification indicates that the observed resource has
finished sending notifications.</t>
<t>A THROW notification informs the subscribed client of an error condition.</t>
</list></t>
<t>Each of these notification messages can be sent as a message that does not
require acknowledgement, as a confirmable message that does require
acknowledgement (which makes it a request), or (in case of an initial
notification) piggy-backed with the ACK message that is sent in reply to the
subscription request.</t>
</section>
</section>
</section>
<section anchor="message-exchanges" title="Message Exchanges">
<t>The following message exchanges can be derived from the requirements.</t>
<section anchor="subscribing-to-a-resource" title="Subscribing to a resource">
<figure anchor="client-server-client-server-subscribe-subscribe-ackyield-ack-or-time-passes-yield-c-ack-if-c-"><artwork><![CDATA[
Client Server Client Server
| | | |
| SUBSCRIBE | | SUBSCRIBE |
+---------------->| +---------------->|
| | | |
| ACK+YIELD | | ACK |
|<----------------+ or |<----------------+
| | | |
... Time Passes ...
| |
| YIELD [c?] |
|<----------------+
| |
| ACK (if c) |
+---------------->|
| |
]]></artwork></figure>
<t>The workflow for subscribing an observer to an observable resource or
refreshing a subscription is as follows:</t>
<t><list style='numbers'>
<t>The subscribing client sends a SUBSCRIBE request to the server that
is offering the observable resource. The subscription request includes
the identifier of a representation format in which the notifications
have to be sent, specifies a subscription lifetime duration and
optionally indicates states cached by the client (by Etag or Date) and
other information that might be relayed in a GET request.</t>
<t>The server creates a new subscription if no subscription exists
(<xref target="identify"/>), and changes the lifetime duration of the subscription
to the duration specified in the subscription request, or any shorter
duration if it so desires. The server then acknowledges the request
and indicates the actual lifetime
with a ACK reply (or with a ACK+THROW, ACK+BREAK or ACK+YIELD reply as
described in the next step).</t>
<t>The server performs one of the following actions: <list style='symbols'>
<t>If an error occurred, the server sends a THROW notification (either as
THROW request or as ACK+THROW reply to the SUBSCRIBE request).</t>
<t>If the resource has finished sending notifications, the server
sends a BREAK notification
(either as BREAK request or as ACK+BREAK reply to the SUBSCRIBE request).</t>
<t>Otherwise, the server supplies the observer with the current resource
state in the requested representation format, or indicates that the cached
state is the current state (either as YIELD request or as ACK+YIELD
reply to the SUBSCRIBE request).</t>
</list>
If the server sends a THROW, BREAK or YIELD request, the request is treated
like any other notification (i.e. the client must acknowledge it if
the message is marked as confirmable, etc.).</t>
<t>If the client does not receive the ACK, ACK+THROW, ACK+BREAK or ACK+YIELD
reply within a certain time frame (because the request or the reply went
missing), the client retransmits the SUBSCRIBE request using the same
request identifier.</t>
</list></t>
</section>
<section anchor="notifying-of-state-changes" title="Notifying of state changes">
<figure anchor="client-server-client-server-yield-yield-c-or-ack-"><artwork><![CDATA[
Client Server Client Server
| | | |
| YIELD | | YIELD [c] |
|<----------------+ or |<----------------+
| | | |
| ACK |
+---------------->|
| |
]]></artwork></figure>
<t>The workflow for notifying an observer of a state change is as follows:</t>
<t><list style='numbers'>
<t>The server performs one of the following actions: <list style='symbols'>
<t>If the resource experienced an error condition, the server sends a THROW
request to the client.</t>
<t>If the resource has finished sending notifications, the server
sends a BREAK request to the client.</t>
<t>If the state of the resource changed, the server sends a YIELD request
with the current resource state in the requested representation format.</t>
</list>
The server may or may not mark the request sent as confirmable (<spanx style='verb'>[c]</spanx>). The server
marks a request as confirmable because it wants to check if the
observer is still alive, or because there might not be another
notification in the near future and the confirmation process is
therefore needed to ensure eventual consistency.</t>
<t>If the request is marked as confirmable, the subscribed client performs one of
the following actions: <list style='symbols'>
<t>If the notification cannot be related to a subscription, the client sends
a RST reply.</t>
<t>Otherwise, the client sends an ACK reply.</t>
</list></t>
<t>If the request is marked as confirmable and the server does not receive the ACK
reply or the RST reply within a given time frame, the server retransmits
the request using the same transaction identifier.</t>
</list></t>
<t>(Note that it is entirely the decision of the server whether to
request an acknowledgement by marking the request as confirmable – it
might want to employ different strategies to determine this,
e.g. based on frequency of change, management of state etc.)</t>
</section>
<section anchor="unsubscribing-from-a-resource" title="Unsubscribing from a resource">
<figure anchor="client-server-unsubscribe-ack-"><artwork><![CDATA[
Client Server
| |
| UNSUBSCRIBE |
+---------------->|
| |
| ACK |
|<----------------+
| |
]]></artwork></figure>
<t>The workflow for unsubscribing an observer from an observed resource is as
follows:</t>
<t><list style='numbers'>
<t>The subscribed client sends an UNSUBSCRIBE request to the server offering
the observed resource.</t>
<t>The server changes the lifetime duration of the subscription to zero,
which immediately expires the subscription. The server then acknowledges
the request with a ACK reply.</t>
<t>If the client does not receive the ACK reply within a certain time frame,
the client retransmits the UNSUBSCRIBE request using the same request
identifier.</t>
</list></t>
<t>Note that an subscribed client can also unsubscribe by “forgetting”
the subscription and subsequently replying with a RST to the next
notification. (In order to allow sending that RST even for messages
that are not marked as confirmable, an otherwise redundant transaction
identifier is sent in all messages.)</t>
<t>(An UNSUBSCRIBE message might be implemented as a SUBSCRIBE message
with a lifetime duration of 0, but this has some unintended
consequences. See <xref target="identify"/>.)</t>
</section>
<section anchor="retrieving-resource-state" title="Retrieving resource state">
<t>Note that a GET request matches closely the first steps of subscribing, except that the
GET request does not create or update an subscription. (A GET request is likely
to mark the yield as confirmable.)</t>
<t>The second form in <xref target="GET"/> solves the long-poll case.</t>
<figure anchor="GET"><artwork><![CDATA[
Client Server Client Server
| | | |
| GET | | GET |
+---------------->| +---------------->|
| | | |
| ACK+YIELD | | ACK |
|<----------------+ or |<----------------+
| | | |
... Time Passes ...
| |
| YIELD [c] |
|<----------------+
| |
| ACK |
+---------------->|
| |
]]></artwork></figure>
</section>
<section anchor="changing-resource-state" title="Changing resource state">
<figure anchor="PUT"><artwork><![CDATA[
Client Server Client Server
| | | |
| PUT | | PUT |
+---------------->| +---------------->|
| | | |
| ACK+BREAK | | ACK |
|<----------------+ or |<----------------+
| | | |
... Time Passes ...
| |
| BREAK [c] |
|<----------------+
| |
| ACK |
+---------------->|
| |
]]></artwork></figure>
<t>(The motivation for the BREAK component of the response is: PUT, like
GET, can experience some error condition, so we need a place in the
state machine to put the THROW response; therefore we also need a
BREAK response. The second case in <xref target="PUT"/> is motivated by: PUT, like
GET, can take some time to be processed, so we must be able to send an
ACK immediately and the THROW or BREAK response later.)</t>
<t>Obviously, changing the state of this resource
leads to notification of any observers of new state.
PUT is idempotent,
but if we add notifications it may be a bit surprising that a
duplicated or retransmitted PUT might send notifications
twice. To prevent that, the resource might check whether it is being
changed to the same state it had before and not send notifications in
that case.</t>
</section>
<section anchor="deleting-a-resource" title="Deleting a resource">
<t>A DELETE request is the same as a PUT request, except that the resource is
not created or its state changed, but deleted.</t>
<figure anchor="client-server-delete-ackbreak-"><artwork><![CDATA[
Client Server
| |
| DELETE |
+---------------->|
| |
| ACK+BREAK |
|<----------------+
| |
]]></artwork></figure>
<t>If a resource is observed, deleting the resource leads to an error condition
of which the observers are notified with a THROW notification or THROW request.</t>
</section>
</section>
<section anchor="cache" title="Caching">
<t>An observer may cache part or all of a resource’s state changes. This allows
clients to make conditional requests: If a subscribing client has cached a
particular resource state, the server offering the resource does not need to
send a full notification.</t>
<t><list style='symbols'>
<t>A client informs the server of its cached resource states by
including Etags of cached resource states in the subscription request.
This can be multiple Etags, as this enables the server to just send
a “304 not modified” for a different Etag instead of a different
representation if the resource switches around between multiple states.
(Note that this list might be updated by a subscription refresh.)</t>
<t>A server notifies a client of a change to a cached state by omitting the
representation of the resource state in the notification and including a
flag (“304 not modified”) that indicates that the state changed to a cached state.</t>
</list></t>
<t>Another approach to caching multiple values for a resource is to
express each possible value of the resource’s representation by a
reference to another (unchanging) resource. This lets a resource
change states between a set of such references that then provide the
actual state information. A subscribed client fetches the individual
resources on demand and caches the results for future use.</t>
</section>
<section anchor="identify" title="Identifying notifications and subscriptions">
<t>There are two ways that a notification could be related to the resource that it is about:</t>
<t><list style='numbers'>
<t>The notification could name the resource (its URI).</t>
<t>The notification could name a target that relates to a
subscription, which in turn relates back to the resource.</t>
</list></t>
<t>One or both ways could be implemented in CoAP, there are not</t>
<t>For way 1, each notification would contain the URI of the resource.
This is particularly useful for multicast messages, but could be relatively wasteful.
Also, it is not entirely clear that all servers will be aware of their own authority.
Apart from cached states (<xref target="cache"/>) and other information that could
be part of a GET,
a subscription would simply be the triple</t>
<t><list style='empty'>
<t>[URI, observer transport address, lifetime]</t>
</list></t>
<t>Resubscribing (or a duplicate subscription request) for the same
[URI, observer transport address] pair simply updates the lifetime;
thus, the subscription operation is idempotent.
Similarly, resubscribing with a lifetime of 0 will serve to delete the
subscription (however, a SUBSCRIBE message will be replied to with the
current state of the resource; a SUBSCRIBE with lifetime 0 is thus
equivalent to a GET with the side effect of deleting the subscription).</t>
<t>The notification then needs to contain the URI (and might occasionally
contain a remaining lifetime):</t>
<t><list style='empty'>
<t>[resource representation, resource metadata, URI, lifetime?]</t>
</list></t>
<t>For way 2, the subscription request would also contain a target
identifier that is to be used in every notification, identifying the
specific observer object that is to receive the notification.
Again apart from cached states (<xref target="cache"/>) and other information that could
be part of a GET,
the subscription would be the quadruple:</t>
<t><list style='empty'>
<t>[URI, observer transport address, target, lifetime]</t>
</list></t>
<t>(Note that the combination of the observer transport address and the
target could be expressed as another URI, with the transport address
as the authority and the target as the path. Alternatively, the
target could be a short byte string. By varying the transport
address, i.e. the port number, the target could also made to be always
empty.)</t>
<t>Resubscribing (or a duplicate subscription request) for the same [URI,
observer transport address, target] triple simply updates the lifetime,
thus, the subscription operation again is idempotent. (The same
comment as with way 1 applies to SUBSCRIBE with lifetime 0.)</t>
<t>As the notification already implicitly contains the transport address,
it would just list the target (and might occasionally contain a
remaining lifetime):</t>
<t><list style='empty'>
<t>[resource representation, resource metadata, target, lifetime?]</t>
</list></t>
<t>In both cases, it would be beneficial if rebooting nodes could obtain
the same transport address they had before, because a resubscription
after the reboot does not create additional state.</t>
<t>Multicast works nicely in way 1 (except that the URI may be large).
In way 2, we can give each observer in a multicast group the same
target name, so multicast works.</t>
<t>For normal subscriptions, the observer transport address can be
implied from the source address of the subscription request. For
multicast, there needs to be a way to explicitly indicate that
transport address. (This may be beneficial for unicast, too.)</t>
</section>
<section anchor="open-issues" title="Open issues">
<t>Add discussion of messages that get reordered.</t>
<t>Add detailed message and option formats, once the semantics are agreed.</t>
<t>Describe how to map this to HTTP long-polls, WebSockets, and other
asynchronous forms of HTTP.</t>
<!-- EOF -->
</section>
</middle>
<back>
<references title='Normative References'>
<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='June' day='7' year='2010' />
<abstract><t>This document specifies the Constrained Application Protocol (CoAP), a specialized 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 typical throughput of 10s of kbit/s. CoAP provides request/reply and subscribe/notify interaction models between application end-points, supports built-in resource discovery, and includes key web concepts such as URIs and RESTful methods. 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-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-core-coap-00.txt' />
</reference>
<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='RFC2616'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
</t>
<t>
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='http://www.rfc-editor.org/rfc/rfc2616.txt' />
<format type='PS' octets='5529857' target='http://www.rfc-editor.org/rfc/rfc2616.ps' />
<format type='PDF' octets='550558' target='http://www.rfc-editor.org/rfc/rfc2616.pdf' />
<format type='HTML' octets='636125' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</reference>
<reference anchor='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='213584' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</reference>
</references>
<references title='Informative References'>
<reference anchor="REST">
<front>
<title>Architectural Styles and the Design of Network-based Software Architectures</title>
<author fullname="Roy Fielding" initials="R" surname="Fielding">
<organization>University of California, Irvine</organization>
</author>
<date year="2000" />
</front>
</reference>
<reference anchor="DUAL">
<front>
<title>Subject/Observer is Dual to Iterator</title>
<author fullname="Erik Meijer" initials="E" surname="Meijer">
<organization>Microsoft, PLDI 2010</organization>
</author>
<date day="8" month="June" year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 09:11:00 |