CORE G. Moritz, Ed. Internet-Draft University of Rostock Intended status: Informational January 24, 2012 Expires: July 27, 2012 CoAP Proxy Encode-To Option draft-moritz-core-proxy-encode-00 Abstract The scope of this document is to propose a new option to be used in conjunction with the CoAP proxy mechanisms. Several content types can be converted stateless into each other. The conversion may result in much more efficient representation of the resource. But currently no mechanism exists to indicate the proxy to perform the compression. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may not be modified, and derivative works of it may not be created, and it may not be published except as an Internet-Draft. 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 27, 2012. Copyright Notice Copyright (c) 2012 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 Moritz Expires July 27, 2012 [Page 1] Internet-Draft CoAP Proxy Encode-To Option January 2012 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 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 4. Encode-to Option . . . . . . . . . . . . . . . . . . . . . . . 4 5. Alternative . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Moritz Expires July 27, 2012 [Page 2] Internet-Draft CoAP Proxy Encode-To Option January 2012 1. Introduction The scope of this document is to propose a new option to be used in conjunction with the CoAP proxy mechanisms in coap-08 [I-D.ietf-core-coap]. Several content types can be converted stateless into each other. Reasonable examples are XML to JSON or XML to EXI (and vice versa). All these representation formats can carry exactly the same structured data and information, while the conversion is stateless and requires no external information. To realize scenarios/applications and reuse existing implementations as much as possible it might be required to use e.g. XML carried over HTTP in the backbone (i.e. unconstrained world) and e.g. EXI carried over CoAP in the LoWPAN (i.e. constrained world). To map/convert CoAP to HTTP and vice versa dedicated proxies are defined in CoAP. But currently exists no mechanism to indicate the proxy to map/convert also the payload. While starting with the 6LoWPAN/IPv6 optimizations and mappings at the addressing layer and ending up with the CoAP/HTTP optimizations and mappings at the application, optimize and map also the payload encoding to more efficient formats is the last step. 2. Requirements Language 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 [RFC2119]. 3. Problem Statement The only currently existing way to realize a mapping of the payload representation is to implement it statically in the proxy. Thereby, each message to a CoAP endpoint is converted from e.g. XML into EXI and to EXI to XML for messages to HTTP endpoints. But if the proxy should be used for different applications it is required to keep a state in the proxy, i.e. which conversion/mapping has to be performed for which pair of endpoints. In a deployment the knowledge about supported content types for a certain endpoint or resource might already be known by the requesting client. This knowledge was retrieved by the client e.g. through central registries (e.g. CoAP Resource Directory) during the Moritz Expires July 27, 2012 [Page 3] Internet-Draft CoAP Proxy Encode-To Option January 2012 discovery phase. For a request, the client then can use a proxy, but needs to indicate the proxy to convert the payload to the certain content type and vice versa for the response. Therefore a new CoAP option has to be defined. 4. Encode-to Option The typical scenario will be a HTTP client requesting a CoAP endpoint. If the HTTP client wants to indicate a required conversion of the payload it includes a Pragma HTTP header field in the request. The value of the Pragma header field is "encode-to=" followed by the content type the payload has to be converted to. Valid content types are derived from the existing media types for HTTP. If further parameters are required for the conversion, these parameters are added as parameters to the Pragma header field. The HTTP-CoAP Proxy MUST process the Pragma header if present in the request and it includes the "encode-to" option. If the required conversion cannot be performed by the proxy it MUST response with a 415 Unsupported Media Type status code. If the Proxy can perform the required conversion it replaces the existing message body for the CoAP request with the differently encoded one. To avoid keeping any state on the proxy, the origin content type is included in the CoAP request. Therefore the "encode-to" CoAP option (to be defined, format: string, length: 1-270 Byte, default:none) is used. The value of the CoAP "encode-to" option is the origin content type and if required including parameters for the conversion back. The value should re-use media type IDs as already defined for CoAP. The CoAP endpoint is not required to process the "encode-to" option, but MUST echo the option and the value in the response if it decides not to process the option. Nevertheless, the CoAP endpoint MAY decide to process the option and encode the response in the format expressed in the "encode-to" option. In this case the "encode-to" option MUST NOT be echoed in the CoAP response. The proxy receiving the CoAP respone message with the "encode-to" option MUST process this option and perform the required conversion before forwarding the message to the HTTP endpoint. In the HTTP response no further header field is required to be echoed back. If the proxy is not able to process the required conversion correctly it MAY forward the message body as it is to the HTTP endpoint (or SHOULD response with a 415 Unsupported Media Type status code?). Moritz Expires July 27, 2012 [Page 4] Internet-Draft CoAP Proxy Encode-To Option January 2012 5. Alternative In the coap-misc draft a user-defined option definition is described. An alternative approach would be to define an application specific Pragma option also for CoAP. This option could occur more than ones in a request/response and fulfill all the required user-defined mechanisms. This may include the "encode-to" feature described in this draft. 6. IANA Considerations No IANA issues have been identified in this draft. 7. Security Considerations No Security issues have been identified in this draft. 8. Normative References [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-08 (work in progress), October 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Author's Address Guido Moritz (editor) University of Rostock 18051 Rostock, Germany Phone: +49 381 498 7269 Email: guido.moritz@uni-rostock.de Moritz Expires July 27, 2012 [Page 5]