Internet DRAFT - draft-fossati-core-publish-option
draft-fossati-core-publish-option
Internet Engineering Task Force T. Fossati
Internet-Draft Alcatel-Lucent
Intended status: Standards Track P. Giacomin
Expires: July 10, 2014 Freelance
S. Loreto
Ericsson
January 06, 2014
Publish Option for CoAP
draft-fossati-core-publish-option-03
Abstract
This memo defines the Publish Option for the Constrained Application
Protocol (CoAP). The Publish Option is used by a CoAP Endpoint to
control the authority delegation of one of its resources to another
Endpoint. All the phases of the authority delegation process (setup,
renewal, cancellation) are controlled by a simple RESTful protocol.
This memo also introduces the 'proxies' Web Linking relation type, to
be used by a CoAP Proxy to explicitly advertise the resources that it
can serve - either from its cache, or by forwarding the Client's
request upstream.
The Publish Option and the 'proxies' relation provide the building
blocks for a comprehensive, in-protocol, solution to the sleepy/
intermittent Endpoint use case.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 10, 2014.
Copyright Notice
Fossati, et al. Expires July 10, 2014 [Page 1]
Internet-Draft Publish Option for CoAP January 2014
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language and Motivation . . . . . . . . . . 3
2. Publish Option . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Value Format . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Operations . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Publishing a Resource . . . . . . . . . . . . . . . . 4
2.2.2. Updating a Resource . . . . . . . . . . . . . . . . . 6
2.2.3. Unpublishing a Resource . . . . . . . . . . . . . . . 6
2.2.4. Checking for Change . . . . . . . . . . . . . . . . . 7
3. The 'proxies' Relation Type . . . . . . . . . . . . . . . . . 7
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Discover the Proxy for a Resource . . . . . . . . . . 8
3.1.2. Discover all the Resources that an Endpoint 'proxies' 8
3.2. Publish Link-Format Attributes . . . . . . . . . . . . . 9
3.2.1. Implicitly . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Explicitly . . . . . . . . . . . . . . . . . . . . . 9
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Securing the Delegation . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. A (fairly) Comprehensive Example . . . . . . . . . . 11
A.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 12
A.2. Resources . . . . . . . . . . . . . . . . . . . . . . . . 12
A.3. Application Flow . . . . . . . . . . . . . . . . . . . . 12
A.3.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . 12
A.3.2. Configuration and Reconfiguration . . . . . . . . . . 13
A.3.3. Updating Functional Output . . . . . . . . . . . . . 14
A.3.4. Retrieving Functional Output . . . . . . . . . . . . 14
A.3.5. SEP Reboot . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
Fossati, et al. Expires July 10, 2014 [Page 2]
Internet-Draft Publish Option for CoAP January 2014
1. Introduction
This memo defines the Publish Option for the Constrained Application
Protocol [I-D.ietf-core-coap]. The Publish Option is used by a
sleepy Endpoint (SEP) to temporarily delegate the authority of one of
its resources to another, always on, Endpoint. The delegated
Endpoint is typically a Proxy, though it could be an Endpoint with no
other special network role. The SEP is given a simple RESTful
messaging protocol that enables the setup, renewal and cancellation
of the authority transfer. The whole process is driven by the SEP,
which may actually never need to listen or to keep any state.
This memo also introduces the 'proxies' Web Linking [RFC5988]
relation type. This new relation, which complements the default
'hosts' relation defined in [RFC6690], can be used by a CoAP Proxy to
explicitly advertise the resources that it can serve, either from
cache or by forwarding the Client's request upstream.
The 'proxies' relation works in concert with the Publish Option to
enable SEP discovery even while SEP is off-line.
1.1. Requirements Language and Motivation
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 [RFC2119].
The terms Client, Proxy, Server, and Endpoint are to be interpreted
as described in [I-D.ietf-core-coap].
This memo reuses the terminology introduced in
[I-D.rahman-core-sleepy-problem-statement], and aims at meeting the
objectives stated in its Section 4 via an entirely in-protocol
solution.
2. Publish Option
The Publish Option enables a SEP to temporarily (i.e. for a specified
"lease" time) delegate the authority of one of its hosted resources
to another Endpoint.
+------+---+---+---+---+---------+--------+--------+---------+
| No. | C | U | N | R | Name | Format | Length | Default |
+------+---+---+---+---+---------+--------+--------+---------+
| 31 | x | x | x | - | Publish | uint | 1 | (none) |
+------+---+---+---+---+---------+--------+--------+---------+
Fossati, et al. Expires July 10, 2014 [Page 3]
Internet-Draft Publish Option for CoAP January 2014
The one-byte integer value carried by the Publish Option allows the
publishing node to specify the set of CoAP methods that are allowed
on the resource (see Section 2.1 for details).
The "lease" time of the Publish action is specified by an associated
(implicit or explicit) Max-Age Option value.
2.1. Value Format
The Publish Option consists of a single byte having the following
layout:
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|G P D 0 0 0 0 0|
+-+-+-+-+-+-+-+-+
Each of the higher 3 bits is a flag field indicating whether the
associated CoAP method (respectively: GET, PUT and DELETE) is allowed
on the published resource. The POST method has resource/application
specific semantics and can't therefore be safely delegated. The
lower 5 bits are reserved and MUST be set to 0.
The 0x00 value is used to explicitly revoke the delegation (see
Section 2.2.3.) and MUST NOT be used for any other purpose of the
Option.
If the delegated Proxy receives a request for the published resource
with a method that is not compatible with the mask supplied by the
SEP, it MUST respond with a 4.05 (Method Not Allowed) response code.
2.2. Operations
2.2.1. Publishing a Resource
The SEP publishes one of its hosted resources, specified by the
enclosed Proxy-URI, by making a PUT to the Proxy with a Publish
Option attached. The Publish Option value specifies the CoAP methods
that Clients are allowed to use on the resource (see Section 2.1).
The example below shows a delegation where the GET and PUT methods
are allowed, whereas DELETE is explicitly prohibited, meaning that a
Client can only read and update the resource.
P SEP
| PUT | Proxy-URI: coap://sep.example.org/res
|<--------+ Publish: 0xC0
Fossati, et al. Expires July 10, 2014 [Page 4]
Internet-Draft Publish Option for CoAP January 2014
| r | Content-Format: text/plain
| | Max-Age: 1200
| 2.01 |
+-------->| ETag: 0xabcd
| |
| |
The Proxy, which is voluntarily entrusted by the resource owner to
act as the delegated origin for the "lease" time specified by Max-
Age, replies with a 2.01 (Created) if the authority transfer
succeeds. An exact duplicate of the submitted representation is
created, and from now on it can be accessed via the delegated Proxy
using the original URI encoded in a Proxy-Uri Option. If the Publish
operation isn't successful (e.g. because the Proxy does not support
Publish), then the origin transfer fails, and an appropriate response
code is returned (e.g. 4.02 Bad Option).
If no Max-Age is given, a default of 3600 seconds MUST be assumed.
The Max-Age value, either implicit or explicit, determines the
lifetime of the origin delegation. When Max-Age is elapsed, the
Proxy MUST delete the published resource value (and any associated
link-format metadata) and fall back to its usual proxying function.
On successful delegation, the Proxy MUST generate a new ETag and
return it in the 2.01 response to the Client; if the published
resource can be UPDATE'd, then the Client SHOULD save the ETag value
(see Section 2.2.4).
The returned ETag value represents the state of the resource at the
time the Publish operation is performed. The Proxy MUST change its
value whenever the underlying resource representation changes, e.g.
if it gets UPDATE'd. The current ETag value SHOULD be included by
the Proxy in all responses involving the published representation.
The ETag can be used by SEP to make conditional requests to the Proxy
to check whether the representation has changed (see Section 2.2.4
for details).
The Publish Option is critical, and MUST NOT be present in a
response. If the Proxy does not recognize it, a 4.02 (Bad Option)
MUST be returned to the Client. If the Option value is not correctly
formatted (see Section 2.1), a 4.00 (Bad Request) MUST be returned to
the Client. The Publish Option is not Safe-to-Forward, and neither
is a Cache-Key.
Fossati, et al. Expires July 10, 2014 [Page 5]
Internet-Draft Publish Option for CoAP January 2014
Since the 2.01 is emitted, and for the duration of the delegation,
any Client wishing to access the resource can do so by making a
Proxy-URI request to the Proxy, which shall then serve the resource
from its own storage.
An interesting outcome of this communication strategy is that the SEP
may really never need to listen on its radio interface. However,
ignoring the response status code from Proxy, as well as the ETag
value in case of UPDATE-able resources, is not a safe practice and
SHOULD not be used unless the consequences are fully understood.
Upon publishing, the Proxy MUST save the identity (e.g. the IP
address) of the publishing SEP, and MUST use it to correctly
authorise "maintenance" operations such as renewal or cancellation of
the published resource. The SEP identity MUST be kept for the whole
duration of the delegation (including any associated renewal) and can
be forgotten as soon as the delegation vanishes, either implicitly or
explicitly.
2.2.2. Updating a Resource
In order to update the delegated resource state or to just extend the
lease period, the SEP sends basically the same request (except for
the possibly updated representation value) to the Proxy, which in
turn replies with a 2.04 Changed status code, and a new ETag value,
in case the update operation succeeds. If the operation fails, e.g.
because the request comes from an Endpoint different from the
publishing SEP, a suitable status code is returned (e.g. 4.01
Unauthorized).
P SEP
| PUT | Proxy-URI: coap://sep.example.org/res
|<--------+ Publish: 0xC0
| r | Content-Format: text/plain
| | Max-Age: 1200
| 2.04 |
+-------->| ETag: 0xdcba
| |
2.2.3. Unpublishing a Resource
The delegation of a given resource can be explicitly revoked by the
SEP at any time before the lease time expires, by issuing a DELETE
request to the Proxy hosting the resource duplicate with a Publish
Option with value 0x00.
Fossati, et al. Expires July 10, 2014 [Page 6]
Internet-Draft Publish Option for CoAP January 2014
On successful deletion of the delegation, a 2.02 Deleted response
code is returned by the Proxy. On error a suitable status code is
returned.
P SEP
| DELETE | Proxy-URI: coap://sep.example.org/res
|<---------+ Publish: 0x00
| |
| 2.02 |
+--------->|
| |
2.2.4. Checking for Change
In order to check whether an UPDATE-able resource has changed, SEP
issues a GET for the published resource with If-Match Option set to
the last seen ETag value.
The possible outcomes are:
o 4.04 (Not Found) if the resource has been deleted;
o 2.05 (Content) if it has been otherwise modified;
o 2.03 (Valid) if it has not changed.
In case a 2.05 is returned, SEP saves the updated ETag returned by
the Proxy, and uses it on subsequent If-Match GET's.
Note that, in exceptionally simple scenarios, an unconditional GET
followed by a memcmp against the previous representation value, MAY
constitute a viable alternative to the method described above.
3. The 'proxies' Relation Type
The new 'proxies' Web Linking [RFC5988] relation type is meant to
signify that the target resource carried by the link, which MUST be
identified by an absolute URI, is reachable through a Proxy-URI
request made to the anchored Origin (i.e. the Proxy).
(Note that we need to specify the Proxy through an explicit anchor,
thus increasing the verbosity of the link value, because of the way
the context URI override rules are defined in Section 2.1 of
[RFC6690]. In fact, absent an explicit anchor, rule (b) would set
the context to the SEP origin, which is definitely not what we want.)
3.1. Examples
Fossati, et al. Expires July 10, 2014 [Page 7]
Internet-Draft Publish Option for CoAP January 2014
3.1.1. Discover the Proxy for a Resource
C multicasts a query to the /.well-known/core interface and discovers
the P (associated to the coap://proxy.example.org authority)
"proxies" the resource queried via an explicit href:
M C
| GET | Uri-Path: .well-known
|<--------+ Uri-Path: core
| Uri-Query: href="coap://sep.example.org/res"
P 2.05 |
+-------->| <coap://sep.example.org/res>;
| | anchor="coap://proxy.example.org/";
| | rel="proxies"
3.1.2. Discover all the Resources that an Endpoint 'proxies'
C discovers all the resources that P "proxies":
P C
| GET | Uri-Path: .well-known
|<--------+ Uri-Path: core
| | Uri-Query: rel="proxies"
| 2.05 |
+-------->| <coap://sep.example.org/res>;
| | anchor="coap://proxy.example.org/";
| | rel="proxies",
| | <...
and can then GET one of the "proxied" resource from P:
P C
| GET |
|<--------+ Proxy-URI: coap://sep.example.org/res
| |
| 2.05 |
+-------->| "res" data...
| |
The 'proxies' relation is orthogonal to the Publish Option, so it's
up to P to decide whether to serve coap://sep.example.org/res from
its store/cache, or to forward the request to the origin at coap://
sep.example.org.
Fossati, et al. Expires July 10, 2014 [Page 8]
Internet-Draft Publish Option for CoAP January 2014
3.2. Publish Link-Format Attributes
3.2.1. Implicitly
The resource metadata are implicitly extracted from the published
representation. Basically, the Proxy works out the 'ct' and 'sz'
attributes by inspecting Content-Format and the request payload size.
The main advantage of this method is that it needs no further
transmission except that needed for the Publish operation. The
disadvantage is the very limited (and fixed) number of attributes
that can be derived, which makes it suitable only for the most basic
use cases.
3.2.2. Explicitly
The resource metadata are explicitly published to the same Proxy-URI
used for the sibling resource, either in a separate request/response
cycle:
P S
| PUT | Proxy-URI: coap://sep.example.org/res
|<--------+ Publish: 0x60
| <meta> | Content-Format: application/link-format
| |
| 2.01 |
+-------->|
| |
or atomically, within the same Publish operation, e.g. by using the
Multipart Content-Format to aggregate one (or even more than one)
representation(s) together with the application/link-format entry:
P S
| PUT | Proxy-URI: coap://sep.example.org/res
|<--------+ Publish: 0x60
| [mp] | Content-Format: application/multipart+publish
| | Max-Age: 1200
| 2.01 |
+-------->|
| |
Note that the former is non-atomic, and limited to only one
representation of the resource; the latter is atomic and supports
multiple Content-Format's for the published resource.
Fossati, et al. Expires July 10, 2014 [Page 9]
Internet-Draft Publish Option for CoAP January 2014
4. Acknowledgements
Thanks to Bruce Nordman, Matthieu Vial, Akbar Rahman, and Esko Dijk
for comments and discussions that have helped shaping this document.
5. IANA Considerations
The following entry is added to the CoAP Option Numbers registry:
.------------------------------.
| Number | Name | Reference |
:--------:---------:-----------:
| 31 | Publish | This memo |
`------------------------------'
This memo registers the new "proxies" Web Linking relation type as
per [RFC5988].
Relation Name: proxies
Description: the target is the absolute URI of a resource proxied
by the Origin stated in the anchor.
Reference: this memo
Notes: This relation is used in CoRE where links are retrieved as
a "/.well-known/core" resource representation.
Application Data: None
6. Security Considerations
This section identifies Threats (T) and related countermeasures (C).
o T: cache poisoning.
o C: use strong auth to identify SEP.
o T: unauthorized update or de-registration
o C: strong auth to identify SEP.
o T: Proxy resources' exhaustion.
o C: use strong auth to identify SEP + quota limit.
o T: Inject fake copies of the resource by a 3rd party.
o C: use delegation scheme that bundles the identities of the SEP
and the Proxy, together with the resource being delegated. A
third party must be able to verify SEP and Proxy identities, maybe
offline, and check the resource fingerprint.
6.1. Securing the Delegation
Fossati, et al. Expires July 10, 2014 [Page 10]
Internet-Draft Publish Option for CoAP January 2014
[[The following is just a sketch which needs further elaboration]]
SEP signs the identity of the delegated Proxy and a fingerprint of
the resource (both data and meta), and bundles it up with the
resource itself, maybe in a MultiPart envelope (TBD define signed
Content-Format). Client verifies the resource is indeed from the SEP
by checking the signature, and it has been served by the intended
origin, within the validity frame of the delegation. There seems to
be an issue with hierarchical caching: the resource can't be served
from a downstream Proxy which is different from the one that was
originally delegated unless each Proxy in the delivery chain wraps
the received message with its own credentials?
7. References
7.1. Normative References
[I-D.ietf-core-coap]
Shelby, Z., Hartke, K., and C. Bormann, "Constrained
Application Protocol (CoAP)", draft-ietf-core-coap-18
(work in progress), June 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, August 2012.
7.2. Informative References
[I-D.rahman-core-sleepy-problem-statement]
Rahman, A., Fossati, T., Loreto, S., and M. Vial, "Sleepy
Devices in CoAP - Problem Statement", draft-rahman-core-
sleepy-problem-statement-01 (work in progress), October
2012.
Appendix A. A (fairly) Comprehensive Example
The following section details the whole life-cycle of an hypothetical
Sleepy/Intermittent node that uses Publish to exchange data (both
reading and writing) with other agents in a CoAP network.
Fossati, et al. Expires July 10, 2014 [Page 11]
Internet-Draft Publish Option for CoAP January 2014
A.1. Actors
SEP Sleeping/Intermittent endpoint implementing two functions: F1,
and F2. Each function exposes one configurable parameter, and
provides one output.
P Proxy with Publish support.
W Controller application which can configure function parameters
on SEP.
R Consumer application which reads values from SEP.
A.2. Resources
The following resources model the two functions (F1 and F2)
implemented by SEP in terms of their input and output parameters:
coap://sep1/i1 Configurable parameter for F1.
coap://sep1/i2 Configurable parameter for F2.
coap://sep1/o1 Output of F1.
coap://sep1/o2 Output of F2.
If the number of configuration parameters is not trivially small,
then it might be handy to create an aux resource which can be polled
by the SEP to track the parameters that have been reconfigured:
coap://sep1/im Update parameter mask. Conceptually a n-bit mask
(one bit per configurable parameter) used by W to
mark the updated parameters, and by SEP to clear
them once the corresponding configuration has been
applied.
A.3. Application Flow
A.3.1. Bootstrap
SEP publishes all the application resources to P.
Configurable parameter for F1:
SEP -> P : PUT Proxy-URI=coap://sep1/i1, Publish="G,U", Payload="1"
P -> SEP : 2.01 (Created), ETag=0x01
Configurable parameter for F2:
Fossati, et al. Expires July 10, 2014 [Page 12]
Internet-Draft Publish Option for CoAP January 2014
SEP -> P : PUT Proxy-URI=coap://sep1/i2, Publish="G,U", Payload="2"
P -> SEP : 2.01 (Created), ETag=0x01
Output of F1:
SEP -> P : PUT Proxy-URI=coap://sep1/o1, Publish="G", Payload=""
P -> SEP : 2.01 (Created), ETag=0x01
Output of F2:
SEP -> P : PUT Proxy-URI=coap://sep1/o2, Publish="G", Payload=""
P -> SEP : 2.01 (Created), ETag=0x01
This assumes that SEP has pre-canned values "1" and "2" for its
configurable parameters i1 and i2 respectively.
Optionally:
SEP -> P : PUT Proxy-URI=coap://sep1/im, Publish="G,U",
Payload="update_mask_cleared"
P -> SEP : 2.01 (Created), ETag=0x01
A.3.2. Configuration and Reconfiguration
W sets a new value, e.g. 5, for i2:
W -> P : PUT Proxy-URI=coap://sep1/i2, Payload="5"
P -> W : 2.04 (Changed), ETag=0x02
P updates the value of i2 accordingly, and sets a new ETag on it,
e.g. 0x02.
When SEP wakes up, it polls its configuration variables via a
conditional GET that uses the ETags returned by P at publishing time.
Since i1 has not changed, and is still associated with the original
ETag, a 2.03 status code is returned:
SEP -> P : GET Proxy-URI=coap://sep1/i1, If-Match=0x01
P -> SEP : 2.03 (Valid)
Since i2 has changed, a 2.05 status code is returned and the payload
carries the new value. Also, the new ETag associated with i2 is
returned and is updated locally by the SEP:
SEP -> P : GET Proxy-URI=coap://sep1/i2, If-Match=0x01
P -> SEP : 2.05 (Content), ETag=0x02, Payload="5"
Fossati, et al. Expires July 10, 2014 [Page 13]
Internet-Draft Publish Option for CoAP January 2014
The SEP reconfigures its F1 based on the new configuration setting,
and continues its operations.
A.3.3. Updating Functional Output
SEP wakes up and commits the newly computed values, e.g. 6 and 8, to
P:
SEP -> P : PUT Proxy-URI=coap://sep1/o1, Publish="G", Payload="6"
P -> SEP : 2.04 (Changed), ETag=0x02
SEP -> P : PUT Proxy-URI=coap://sep1/o2, Publish="G", Payload="8"
P -> SEP : 2.04 (Changed), ETag=0x02
P sets the new values, assigns a new ETag, and gives it back to P
together with a 2.04 status code.
A.3.4. Retrieving Functional Output
R needs to retrieve the latest values for the functions computed by
SEP; thus, it asks P to retrieve the associated resources:
R -> P : GET Proxy-URI=coap://sep1/o1
P -> R : 2.05 (Content), ETag=0x02, Payload="6"
R -> P : GET Proxy-URI=coap://sep1/o2
P -> R : 2.05 (Content), ETag=0x02, Payload="8"
Note that the exchange above applies to the very first poll.
Subsequent polls can be done conditionally on the "last-seen" ETag.
Also note that the above assumes SEP has been able to update its
values at least once. R must be prepared to retrieve empty
representations, if SEP has not yet updated their value since boot-
strap.
A.3.5. SEP Reboot
The idempotence of all the involved methods guarantees a clean
recovery in face of a reboot of the SEP. In fact, if at a given time
SEP reboots and loose soft state, including the configuration
parameters: SEP has to go again through the bootstrap phase in which
the application resources are published:
SEP -> P : PUT Proxy-URI=coap://sep1/i1, Publish="G,U", Payload="1"
P -> SEP : 2.04 (Changed), ETag=0x03
SEP -> P : PUT Proxy-URI=coap://sep1/i2, Publish="G,U", Payload="2"
Fossati, et al. Expires July 10, 2014 [Page 14]
Internet-Draft Publish Option for CoAP January 2014
P -> SEP : 2.04 (Changed), ETag=0x03
SEP -> P : PUT Proxy-URI=coap://sep1/o1, Publish="G", Payload=""
P -> SEP : 2.04 (Changed), ETag=0x03
SEP -> P : PUT Proxy-URI=coap://sep1/o2, Publish="G", Payload=""
P -> SEP : 2.04 (Changed), ETag=0x03
The ETag's value (0x03) needs to be not recently used (not within the
Max-Age period for the resource).
From now on everything can proceed as described in Appendix A.3.2,
Appendix A.3.3, and Appendix A.3.4
Authors' Addresses
Thomas Fossati
Alcatel-Lucent
3 Ely Road
Milton, Cambridge CB24 6DD
UK
Email: thomas.fossati@alcatel-lucent.com
Pierpaolo Giacomin
Freelance
Email: yrz@anche.no
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Fossati, et al. Expires July 10, 2014 [Page 15]
