idnits 2.17.1 draft-moritz-core-proxy-encode-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2012) is 4447 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-08 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE G. Moritz, Ed. 3 Internet-Draft University of Rostock 4 Intended status: Informational January 24, 2012 5 Expires: July 27, 2012 7 CoAP Proxy Encode-To Option 8 draft-moritz-core-proxy-encode-00 10 Abstract 12 The scope of this document is to propose a new option to be used in 13 conjunction with the CoAP proxy mechanisms. Several content types 14 can be converted stateless into each other. The conversion may 15 result in much more efficient representation of the resource. But 16 currently no mechanism exists to indicate the proxy to perform the 17 compression. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, and it may not be 24 published except as an Internet-Draft. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 27, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 57 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Encode-to Option . . . . . . . . . . . . . . . . . . . . . . . 4 59 5. Alternative . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 62 8. Normative References . . . . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 The scope of this document is to propose a new option to be used in 68 conjunction with the CoAP proxy mechanisms in coap-08 69 [I-D.ietf-core-coap]. Several content types can be converted 70 stateless into each other. 72 Reasonable examples are XML to JSON or XML to EXI (and vice versa). 73 All these representation formats can carry exactly the same 74 structured data and information, while the conversion is stateless 75 and requires no external information. 77 To realize scenarios/applications and reuse existing implementations 78 as much as possible it might be required to use e.g. XML carried 79 over HTTP in the backbone (i.e. unconstrained world) and e.g. EXI 80 carried over CoAP in the LoWPAN (i.e. constrained world). 82 To map/convert CoAP to HTTP and vice versa dedicated proxies are 83 defined in CoAP. But currently exists no mechanism to indicate the 84 proxy to map/convert also the payload. 86 While starting with the 6LoWPAN/IPv6 optimizations and mappings at 87 the addressing layer and ending up with the CoAP/HTTP optimizations 88 and mappings at the application, optimize and map also the payload 89 encoding to more efficient formats is the last step. 91 2. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in RFC 2119 [RFC2119]. 97 3. Problem Statement 99 The only currently existing way to realize a mapping of the payload 100 representation is to implement it statically in the proxy. Thereby, 101 each message to a CoAP endpoint is converted from e.g. XML into EXI 102 and to EXI to XML for messages to HTTP endpoints. But if the proxy 103 should be used for different applications it is required to keep a 104 state in the proxy, i.e. which conversion/mapping has to be performed 105 for which pair of endpoints. 107 In a deployment the knowledge about supported content types for a 108 certain endpoint or resource might already be known by the requesting 109 client. This knowledge was retrieved by the client e.g. through 110 central registries (e.g. CoAP Resource Directory) during the 111 discovery phase. For a request, the client then can use a proxy, but 112 needs to indicate the proxy to convert the payload to the certain 113 content type and vice versa for the response. Therefore a new CoAP 114 option has to be defined. 116 4. Encode-to Option 118 The typical scenario will be a HTTP client requesting a CoAP 119 endpoint. If the HTTP client wants to indicate a required conversion 120 of the payload it includes a Pragma HTTP header field in the request. 121 The value of the Pragma header field is "encode-to=" followed by the 122 content type the payload has to be converted to. Valid content types 123 are derived from the existing media types for HTTP. If further 124 parameters are required for the conversion, these parameters are 125 added as parameters to the Pragma header field. 127 The HTTP-CoAP Proxy MUST process the Pragma header if present in the 128 request and it includes the "encode-to" option. If the required 129 conversion cannot be performed by the proxy it MUST response with a 130 415 Unsupported Media Type status code. 132 If the Proxy can perform the required conversion it replaces the 133 existing message body for the CoAP request with the differently 134 encoded one. To avoid keeping any state on the proxy, the origin 135 content type is included in the CoAP request. Therefore the 136 "encode-to" CoAP option (to be defined, format: string, length: 1-270 137 Byte, default:none) is used. The value of the CoAP "encode-to" 138 option is the origin content type and if required including 139 parameters for the conversion back. The value should re-use media 140 type IDs as already defined for CoAP. 142 The CoAP endpoint is not required to process the "encode-to" option, 143 but MUST echo the option and the value in the response if it decides 144 not to process the option. Nevertheless, the CoAP endpoint MAY 145 decide to process the option and encode the response in the format 146 expressed in the "encode-to" option. In this case the "encode-to" 147 option MUST NOT be echoed in the CoAP response. 149 The proxy receiving the CoAP respone message with the "encode-to" 150 option MUST process this option and perform the required conversion 151 before forwarding the message to the HTTP endpoint. In the HTTP 152 response no further header field is required to be echoed back. If 153 the proxy is not able to process the required conversion correctly it 154 MAY forward the message body as it is to the HTTP endpoint (or SHOULD 155 response with a 415 Unsupported Media Type status code?). 157 5. Alternative 159 In the coap-misc draft a user-defined option definition is described. 160 An alternative approach would be to define an application specific 161 Pragma option also for CoAP. This option could occur more than ones 162 in a request/response and fulfill all the required user-defined 163 mechanisms. This may include the "encode-to" feature described in 164 this draft. 166 6. IANA Considerations 168 No IANA issues have been identified in this draft. 170 7. Security Considerations 172 No Security issues have been identified in this draft. 174 8. Normative References 176 [I-D.ietf-core-coap] 177 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 178 "Constrained Application Protocol (CoAP)", 179 draft-ietf-core-coap-08 (work in progress), October 2011. 181 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, March 1997. 184 Author's Address 186 Guido Moritz (editor) 187 University of Rostock 188 18051 Rostock, 189 Germany 191 Phone: +49 381 498 7269 192 Email: guido.moritz@uni-rostock.de