Internet DRAFT - draft-moritz-core-proxy-encode
draft-moritz-core-proxy-encode
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]
