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 | +-------->| ; | | 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 | +-------->| ; | | 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 | | 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]