RFC 8075
Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)
Pages: 40
Proposed Standard
Proposed Standard
Part 1 of 2 – Pages 1 to 21
Internet Engineering Task Force (IETF) A. Castellani Request for Comments: 8075 University of Padova Category: Standards Track S. Loreto ISSN: 2070-1721 Ericsson A. Rahman InterDigital Communications, LLC T. Fossati Nokia E. Dijk Philips Lighting February 2017 Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)Abstract
This document provides reference information for implementing a cross-protocol network proxy that performs translation from the HTTP protocol to the Constrained Application Protocol (CoAP). This will enable an HTTP client to access resources on a CoAP server through the proxy. This document describes how an HTTP request is mapped to a CoAP request and how a CoAP response is mapped back to an HTTP response. This includes guidelines for status code, URI, and media type mappings, as well as additional interworking advice. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8075.
Copyright Notice Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. HTTP-to-CoAP Proxy . . . . . . . . . . . . . . . . . . . . . 6 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. URI Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. URI Terminology . . . . . . . . . . . . . . . . . . . . . 8 5.2. Null Mapping . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Default Mapping . . . . . . . . . . . . . . . . . . . . . 9 5.3.1. Optional Scheme Omission . . . . . . . . . . . . . . 9 5.3.2. Encoding Caveats . . . . . . . . . . . . . . . . . . 10 5.4. URI Mapping Template . . . . . . . . . . . . . . . . . . 10 5.4.1. Simple Form . . . . . . . . . . . . . . . . . . . . . 10 5.4.2. Enhanced Form . . . . . . . . . . . . . . . . . . . . 12 5.5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 5.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . 14 6. Media Type Mapping . . . . . . . . . . . . . . . . . . . . . 15 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. 'application/coap-payload' Media Type . . . . . . . . . . 16 6.3. Loose Media Type Mapping . . . . . . . . . . . . . . . . 17 6.4. Media Type to Content-Format Mapping Algorithm . . . . . 18 6.5. Content Transcoding . . . . . . . . . . . . . . . . . . . 19 6.5.1. General . . . . . . . . . . . . . . . . . . . . . . . 19 6.5.2. CoRE Link Format . . . . . . . . . . . . . . . . . . 20 6.6. Diagnostic Payloads . . . . . . . . . . . . . . . . . . . 20 7. Response Code Mapping . . . . . . . . . . . . . . . . . . . . 21 8. Additional Mapping Guidelines . . . . . . . . . . . . . . . . 23 8.1. Caching and Congestion Control . . . . . . . . . . . . . 23 8.2. Cache Refresh via Observe . . . . . . . . . . . . . . . . 24 8.3. Use of CoAP Block-Wise Transfer . . . . . . . . . . . . . 24 8.4. CoAP Multicast . . . . . . . . . . . . . . . . . . . . . 25 8.5. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9.1. New 'core.hc' Resource Type . . . . . . . . . . . . . . . 26 9.2. New 'coap-payload' Internet Media Type . . . . . . . . . 26 10. Security Considerations . . . . . . . . . . . . . . . . . . . 28 10.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Traffic Overflow . . . . . . . . . . . . . . . . . . . . 29 10.3. Handling Secured Exchanges . . . . . . . . . . . . . . . 30 10.4. URI Mapping . . . . . . . . . . . . . . . . . . . . . . 30 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1. Normative References . . . . . . . . . . . . . . . . . . 31 11.2. Informative References . . . . . . . . . . . . . . . . . 32 Appendix A. Media Type Mapping Source Code . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] has been designed with a twofold aim: it's an application protocol specialized for constrained environments and it's easily used in architectures based on Representational State Transfer (REST) [Fielding], such as the web. The latter goal has led to defining CoAP to easily interoperate with HTTP [RFC7230] through an intermediary proxy that performs cross-protocol conversion. Section 10 of [RFC7252] describes the fundamentals of the CoAP-to-HTTP and the HTTP-to-CoAP cross-protocol mapping process. However, [RFC7252] focuses on the basic mapping of request methods and simple response code mapping between HTTP and CoAP, while leaving many details of the cross-protocol proxy for future definition. Therefore, a primary goal of this document is to define a consistent set of guidelines that an HTTP-to-CoAP proxy implementation should adhere to. The key benefit to adhering to such guidelines is to reduce variation between proxy implementations, thereby increasing interoperability between an HTTP client and a CoAP server independent of the proxy that implements the cross-protocol mapping. (For example, a proxy conforming to these guidelines made by vendor A can be easily replaced by a proxy from vendor B that also conforms to the guidelines without breaking API semantics.) This document describes HTTP mappings that apply to protocol elements defined in the base CoAP specification [RFC7252] and in the CoAP block-wise transfer specification [RFC7959]. It is up to CoAP protocol extensions (new methods, response codes, options, content- formats) to describe their own HTTP mappings, if applicable. The rest of this document is organized as follows: o Section 2 defines proxy terminology; o Section 3 introduces the HTTP-to-CoAP proxy; o Section 4 lists use cases in which HTTP clients need to contact CoAP servers; o Section 5 introduces a null, default, and advanced HTTP-to-CoAP URI mapping syntax; o Section 6 describes how to map HTTP media types to CoAP content- formats, and vice versa; o Section 7 describes how to map CoAP responses to HTTP responses;
o Section 8 describes additional mapping guidelines related to caching, congestion, multicast, timeouts, etc.; and o Section 10 discusses the possible security impact of HTTP-to-CoAP protocol mapping.2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. This specification requires readers to be familiar with the vocabulary and concepts discussed in [RFC7228], in particular, the terms "constrained nodes" and "constrained networks". Readers must also be familiar with all of the terminology of the normative references listed in this document, in particular [RFC7252] (CoAP) and [RFC7230] (HTTP). In addition, this specification makes use of the following terms: HC Proxy A proxy performing a cross-protocol mapping, in the context of this document an HTTP-to-CoAP (HC) mapping. Specifically, the HC Proxy acts as an HTTP server and a CoAP client. The HC Proxy can take on the role of a forward, reverse, or interception Proxy. Application Level Gateway (ALG) An application-specific translation agent that allows an application on a host in one address realm to connect to its counterpart running on a host in a different realm transparently. See Section 2.9 of [RFC2663]. forward-proxy A message-forwarding agent that is selected by the HTTP client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and to attempt to satisfy those requests via translation to the protocol indicated by the absolute URI. The user agent decides (is willing) to use the proxy as the forwarding/dereferencing agent for a predefined subset of the URI space. In [RFC7230], this is called a "proxy". [RFC7252] defines forward-proxy similarly. reverse-proxy As in [RFC7230], a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying server's protocol. A reverse-proxy behaves as an origin (HTTP) server on its connection from the HTTP client. The
HTTP client uses the "origin-form" (Section 5.3.1 of [RFC7230])
as a request-target URI. (Note that a reverse-proxy appears to
an HTTP client as an origin server while a forward-proxy does
not. So, when communicating with a reverse-proxy, a client may
be unaware it is communicating with a proxy at all.)
interception proxy
As in [RFC3040], a proxy that receives inbound HTTP traffic flows
through the process of traffic redirection, transparent to the
HTTP client.
3. HTTP-to-CoAP Proxy
An HC Proxy is accessed by an HTTP client that needs to fetch a
resource on a CoAP server. The HC Proxy handles the HTTP request by
mapping it to the equivalent CoAP request, which is then forwarded to
the appropriate CoAP server. The received CoAP response is then
mapped to an appropriate HTTP response and finally sent back to the
originating HTTP client.
Section 10.2 of [RFC7252] defines basic normative requirements on
HTTP-to-CoAP mapping. This document provides additional details and
guidelines for the implementation of an HC Proxy.
Constrained Network
.-------------------.
/ .------. \
/ | CoAP | \
/ |server| \
|| '------' ||
|| ||
.--------. HTTP Request .------------. CoAP Req .------. ||
| HTTP |---------------->|HTTP-to-CoAP|----------->| CoAP | ||
| Client |<----------------| Proxy |<-----------|server| ||
'--------' HTTP Response '------------' CoAP Resp '------' ||
|| ||
|| .------. ||
|| | CoAP | ||
\ |server| .------. /
\ '------' | CoAP | /
\ |server| /
\ '------' /
'-----------------'
Figure 1: HTTP-To-CoAP Proxy Deployment Scenario
Figure 1 illustrates an example deployment scenario. There, an HC Proxy is located at the boundary of the constrained network domain and acts as an ALG that allows only a very specific type of traffic (i.e., authorized inbound HTTP requests and their associated outbound CoAP responses) to pass through. All other kinds of traffic are segregated within the respective network segments.4. Use Cases
To illustrate a few situations in which HTTP-to-CoAP protocol translation may be used, three use cases are described below. 1. Legacy building control application without CoAP: A building control application that uses HTTP but not CoAP can check the status of CoAP sensors and/or control actuators via an HC Proxy. 2. Making sensor data available to third parties on the web: For demonstration or public interest purposes, an HC Proxy may be configured to expose the contents of a CoAP sensor to the world via the web (HTTP and/or HTTPS). Some sensors may only accept secure 'coaps' requests; therefore, the proxy is configured to translate requests to those devices accordingly. The HC Proxy is furthermore configured to only pass through GET requests in order to protect the constrained network. 3. Smartphone and home sensor: A smartphone can access directly a CoAP home sensor using a mutually authenticated 'https' request, provided its home router runs an HC Proxy and is configured with the appropriate certificate. An HTML5 [W3C.REC-html5-20141028] application on the smartphone can provide a friendly UI using the standard (HTTP) networking functions of HTML5. A key point in the above use cases is the expected nature of the URI to be used by the HTTP client initiating the HTTP request to the HC Proxy. Specifically, in use case #1, there will be no information related to 'coap' or 'coaps' embedded in the HTTP URI as it is a legacy HTTP client sending the request. Use case #2 is also expected to be similar. In contrast, in use case #3, it is likely that the HTTP client will specifically embed information related to 'coap' or 'coaps' in the HTTP URI of the HTTP request to the HC Proxy.5. URI Mapping
Though, in principle, a CoAP URI could be directly used by an HTTP client to dereference a CoAP resource through an HC Proxy; the reality is that all major web browsers, networking libraries, and command-line tools do not allow making HTTP requests using URIs with a scheme 'coap' or 'coaps'.
Thus, there is a need for web applications to embed or "pack" a CoAP
URI into an HTTP URI so that it can be (non-destructively)
transported from the HTTP client to the HC Proxy. The HC Proxy can
then "unpack" the CoAP URI and finally dereference it via a CoAP
request to the target server.
URI mapping is the term used in this document to describe the process
through which the URI of a CoAP resource is transformed into an HTTP
URI so that:
o The requesting HTTP client can handle it; and
o The receiving HC Proxy can extract the intended CoAP URI
unambiguously.
To this end, the remainder of this section will identify:
o The default mechanism to map a CoAP URI into an HTTP URI;
o The URI Template format to express a class of CoAP-HTTP URI
mapping functions; and
o The discovery mechanism based on "Constrained RESTful Environments
(CoRE) Link Format" [RFC6690] through which clients of an HC Proxy
can dynamically learn about the supported URI mapping template(s),
as well as the URI where the HC Proxy function is anchored.
5.1. URI Terminology
In the remainder of this section, the following terms will be used
with a distinctive meaning:
HC Proxy URI:
URI that refers to the HC Proxy function. It conforms to
syntax defined in Section 2.7 of [RFC7230].
Target CoAP URI:
URI that refers to the (final) CoAP resource that has to be
dereferenced. It conforms to syntax defined in Section 6 of
[RFC7252]. Specifically, its scheme is either 'coap' or
'coaps'.
Hosting HTTP URI:
URI that conforms to syntax in Section 2.7 of [RFC7230]. Its
authority component refers to an HC Proxy, whereas a path
and/or query component(s) embed the information used by an HC
Proxy to extract the Target CoAP URI.
5.2. Null Mapping
The null mapping is the case where there is no Target CoAP URI appended to the HC Proxy URI. In other words, it is a "pure" HTTP URI that is sent to the HC Proxy. This would typically occur in situations like use case #1 described in Section 4, and the proxy would typically be a reverse-proxy. In this scenario, the HC Proxy will determine through its own private algorithms what the Target CoAP URI should be.5.3. Default Mapping
The default mapping is for the Target CoAP URI to be appended as is (with the only caveat discussed in Section 5.3.2) to the HC Proxy URI, to form the Hosting HTTP URI. This is the effective request URI (see Section 5.5 of [RFC7230]) that will then be sent by the HTTP client in the HTTP request to the HC Proxy. For example: given an HC Proxy URI https://p.example.com/hc/ and a Target CoAP URI coap://s.example.com/light, the resulting Hosting HTTP URI would be https://p.example.com/hc/coap://s.example.com/ light. Provided a correct Target CoAP URI, the Hosting HTTP URI resulting from the default mapping will be a syntactically valid HTTP URI. Furthermore, the Target CoAP URI can always be extracted unambiguously from the Hosting HTTP URI. There is no default for the HC Proxy URI. Therefore, it is either known in advance, e.g., as a configuration preset, or dynamically discovered using the mechanism described in Section 5.5. The default URI mapping function SHOULD be implemented and SHOULD be activated by default in an HC Proxy, unless there are valid reasons (e.g., application specific) to use a different mapping function.5.3.1. Optional Scheme Omission
When constructing a Hosting HTTP URI by embedding a Target CoAP URI, the scheme (i.e., 'coap' or 'coaps'), the scheme component delimiter (":"), and the double slash ("//") preceding the authority MAY be omitted if a local default -- not defined by this document -- applies. If no prior mutual agreement exists between the client and the HC Proxy, then a Target CoAP URI without the scheme component is syntactically incorrect, and therefore: o It MUST NOT be emitted by clients; and
o It MUST elicit a suitable client error status (i.e., 4xx) by the
HC Proxy.
5.3.2. Encoding Caveats
When the authority of the Target CoAP URI is given as an IPv6address,
then the surrounding square brackets must be percent-encoded in the
Hosting HTTP URI, in order to comply with the syntax defined in
Section 3.3. of [RFC3986] for a URI path segment. For example:
coap://[2001:db8::1]/light?on becomes
https://p.example.com/hc/coap://%5B2001:db8::1%5D/light?on. (Note
that the percent-encoded square brackets shall be reverted to their
non-percent-encoded form when the HC Proxy unpacks the Target CoAP
URI.)
Everything else can be safely copied verbatim from the Target CoAP
URI to the Hosting HTTP URI.
5.4. URI Mapping Template
This section defines a format for the URI Template [RFC6570] used by
an HC Proxy to inform its clients about the expected syntax for the
Hosting HTTP URI. This can then be used by the HTTP client to
construct the effective request URI to be sent in the HTTP request to
the HC Proxy.
When instantiated, a URI mapping template is always concatenated to
an HC Proxy URI provided by the HC Proxy via discovery (see
Section 5.5), or by other means.
A simple form (Section 5.4.1) and an enhanced form (Section 5.4.2)
are provided to fit different users' requirements.
Both forms are expressed as Level 2 URI Templates [RFC6570] to take
care of the expansion of values that are allowed to include reserved
URI characters. The syntax of all URI formats is specified in this
section in Augmented Backus-Naur Form (ABNF) [RFC5234].
5.4.1. Simple Form
The simple form MUST be used for mappings where the Target CoAP URI
is going to be copied (using rules of Section 5.3.2) at some fixed
position into the Hosting HTTP URI.
The "tu" template variable is defined below using the ABNF rules from [RFC3986], Sections 3.2.2, 3.2.3, 3.3, and 3.4. It is intended to be used in a template definition to represent a Target CoAP URI: tu = [ ( "coap:" / "coaps:" ) "//" ] host [ ":" port ] path-abempty [ "?" query ] Note that the same considerations as in Section 5.3.1 apply, in that the CoAP scheme may be omitted from the Hosting HTTP URI.5.4.1.1. Examples
All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use https://p.example.com/hc/ as the HC Proxy URI. Note that these examples all define mapping templates that deviate from the default template of Section 5.3 in order to illustrate the use of the above template variables. 1. Target CoAP URI is a query argument of the Hosting HTTP URI: ?target_uri={+tu} coap://s.example.com/light => https://p.example.com/hc/?target_uri=coap://s.example.com/light whereas coaps://s.example.com/light => https://p.example.com/hc/?target_uri=coaps://s.example.com/light 2. Target CoAP URI in the path component of the Hosting HTTP URI: forward/{+tu} coap://s.example.com/light => https://p.example.com/hc/forward/coap://s.example.com/light whereas coaps://s.example.com/light => https://p.example.com/hc/forward/coaps://s.example.com/light
3. Target CoAP URI is a query argument of the Hosting HTTP URI;
client decides to omit the scheme because a default is agreed
beforehand between client and proxy:
?coap_uri={+tu}
coap://s.example.com/light
=> https://p.example.com/hc/?coap_uri=s.example.com/light
5.4.2. Enhanced Form
The enhanced form can be used to express more sophisticated mappings
of the Target CoAP URI into the Hosting HTTP URI, i.e., mappings that
do not fit into the simple form.
There MUST be at most one instance of each of the following template
variables in a URI mapping template definition:
s = "coap" / "coaps" ; from [RFC7252], Sections 6.1 and 6.2
hp = host [":" port] ; from [RFC3986], Sections 3.2.2 and 3.2.3
p = path-abempty ; from [RFC3986], Section 3.3
q = query ; from [RFC3986], Section 3.4
qq = [ "?" query ] ; qq is empty if and only if 'query' is empty
The qq form is used when the path and the (optional) query components
are to be copied verbatim from the Target CoAP URI into the Hosting
HTTP URI, i.e., as "{+p}{+qq}". Instead, the q form is used when the
query and path are mapped as separate entities, e.g., as in
"coap_path={+p}&coap_query={+q}". So q and qq MUST be used in mutual
exclusion in a template definition.
5.4.2.1. Examples
All the following examples (given as a specific URI mapping template,
a Target CoAP URI, and the produced Hosting HTTP URI) use
https://p.example.com/hc/ as the HC Proxy URI.
1. Target CoAP URI components in path segments and optional query in
query component:
{+s}/{+hp}{+p}{+qq}
coap://s.example.com/light
=> https://p.example.com/hc/coap/s.example.com/light
whereas
coap://s.example.com/light?on
=> https://p.example.com/hc/coap/s.example.com/light?on
2. Target CoAP URI components split in individual query arguments:
?s={+s}&hp={+hp}&p={+p}&q={+q}
coap://s.example.com/light
=> https://p.example.com/hc/?s=coap&hp=s.example.com&p=/light&q=
whereas
coaps://s.example.com/light?on
=> https://p.example.com/hc/?s=coaps&hp=s.example.com&p=/light&q=on
5.5. Discovery
In order to accommodate site-specific needs while allowing third
parties to discover the proxy function, the HC Proxy SHOULD publish
information related to the location and syntax of the HC Proxy
function using the CoRE Link Format [RFC6690] interface.
To this aim, a new Resource Type, "core.hc", is defined in this
document. It can be used as the value for the "rt" attribute in a
query to the "/.well-known/core" resource in order to locate the URI
where the HC Proxy function is anchored, i.e., the HC Proxy URI.
Along with it, the new target attribute "hct" is defined in this
document. This attribute MAY be returned in a "core.hc" link to
provide the URI mapping template associated with the mapping
resource. The default template given in Section 5.3, i.e., {+tu},
MUST be assumed if no "hct" attribute is found in a returned link.
If a "hct" attribute is present in a returned link, the client MUST
use it to create a Hosting HTTP URI.
The URI mapping SHOULD be discoverable (as specified in [RFC6690]) on
both the HTTP and the CoAP side of the HC Proxy, with one important
difference: on the CoAP side, the link associated with the "core.hc"
resource always needs an explicit anchor parameter referring to the
HTTP origin [RFC6454], while on the HTTP interface, the context URI
of the link may be equal to the HTTP origin of the discovery request:
in that case, the anchor parameter is not needed.
5.5.1. Examples
o The first example exercises the CoAP interface and assumes that the default template, {+tu}, is used. For example, a smartphone may discover the public HC Proxy before leaving the home network. Then, when outside the home network, the smartphone will be able to query the appropriate home sensor. Req: GET coap://[ff02::fd]/.well-known/core?rt=core.hc Res: 2.05 Content </hc/>;anchor="https://p.example.com";rt="core.hc" o The second example -- also on the CoAP side of the HC Proxy -- uses a custom template, i.e., one where the CoAP URI is carried inside the query component, thus the returned link carries the URI Template to be used in an explicit "hct" attribute: Req: GET coap://[ff02::fd]/.well-known/core?rt=core.hc Res: 2.05 Content </hc/>;anchor="https://p.example.com"; rt="core.hc";hct="?uri={+tu}" On the HTTP side, link information can be serialized in more than one way: o using the 'application/link-format' content type: Req: GET /.well-known/core?rt=core.hc HTTP/1.1 Host: p.example.com Res: HTTP/1.1 200 OK Content-Type: application/link-format Content-Length: 19 </hc/>;rt="core.hc"
o using the 'application/link-format+json' content type as defined
in [CoRE-JSON-CBOR]:
Req: GET /.well-known/core?rt=core.hc HTTP/1.1
Host: p.example.com
Res: HTTP/1.1 200 OK
Content-Type: application/link-format+json
Content-Length: 32
[{"href":"/hc/","rt":"core.hc"}]
6. Media Type Mapping
6.1. Overview
An HC Proxy needs to translate HTTP media types (Section 3.1.1.1 of
[RFC7231]) and content codings (Section 3.1.2.2 of [RFC7231]) into
CoAP content-formats (Section 12.3 of [RFC7252]), and vice versa.
Media type translation can happen in GET, PUT, or POST requests going
from HTTP to CoAP, in 2.xx (i.e., successful) responses going from
CoAP to HTTP, and in 4.xx/5.xx error responses with a diagnostic
payload. Specifically, PUT and POST need to map both the Content-
Type and Content-Encoding HTTP headers into a single CoAP Content-
Format option, whereas GET needs to map Accept and Accept-Encoding
HTTP headers into a single CoAP Accept option. To generate the HTTP
response, the CoAP Content-Format option is mapped back to a suitable
HTTP Content-Type and Content-Encoding combination.
An HTTP request carrying a Content-Type and Content-Encoding
combination that the HC Proxy is unable to map to an equivalent CoAP
Content-Format SHALL elicit a 415 (Unsupported Media Type) response
by the HC Proxy.
On the content negotiation side, failure to map Accept and Accept-*
headers SHOULD be silently ignored: the HC Proxy SHOULD therefore
forward as a CoAP request with no Accept option. The HC Proxy thus
disregards the Accept/Accept-* header fields by treating the response
as if it is not subject to content negotiation, as mentioned in
Section 5.3 of [RFC7231]. However, an HC Proxy implementation is
free to attempt mapping a single Accept header in a GET request to
multiple CoAP GET requests, each with a single Accept option, which
are then tried in sequence until one succeeds. Note that an HTTP
Accept */* MUST be mapped to a CoAP request without an Accept option.
While the CoAP-to-HTTP direction always has a well-defined mapping
(with the exception examined in Section 6.2), the HTTP-to-CoAP
direction is more problematic because the source set, i.e., potentially 1000+ IANA-registered media types, is much bigger than the destination set, i.e., the mere six values initially defined in Section 12.3 of [RFC7252]. Depending on the tight/loose coupling with the application(s) for which it proxies, the HC Proxy could implement different media type mappings. When tightly coupled, the HC Proxy knows exactly which content- formats are supported by the applications and can be strict when enforcing its forwarding policies in general, and the media type mapping in particular. On the other hand, when the HC Proxy is a general purpose ALG, being too strict could significantly reduce the amount of traffic that it would be able to successfully forward. In this case, the "loose" media type mapping detailed in Section 6.3 MAY be implemented. The latter grants more evolution of the surrounding ecosystem, at the cost of allowing more attack surface. In fact, as a result of such strategy, payloads would be forwarded more liberally across the unconstrained/constrained network boundary of the communication path.6.2. 'application/coap-payload' Media Type
If the HC Proxy receives a CoAP response with a Content-Format that it does not recognize (e.g., because the value has been registered after the proxy has been deployed, or the CoAP server uses an experimental value that is not registered), then the HC Proxy SHALL return a generic "application/coap-payload" media type with numeric parameter "cf" as defined in Section 9.2. For example, the CoAP content-format '60' ("application/cbor") would be represented by "application/coap-payload;cf=60", if the HC Proxy doesn't recognize the content-format '60'. An HTTP client may use the media type "application/coap-payload" as a means to send a specific content-format to a CoAP server via an HC Proxy if the client has determined that the HC Proxy does not directly support the type mapping it needs. This case may happen when dealing, for example, with newly registered, yet to be registered, or experimental CoAP content-formats. However, unless explicitly configured to allow pass-through of unknown content- formats, the HC Proxy SHOULD NOT forward requests carrying a Content- Type or Accept header with an "application/coap-payload", and return an appropriate client error instead.
6.3. Loose Media Type Mapping
By structuring the type information in a super-class (e.g., "text") followed by a finer-grained sub-class (e.g., "html"), and optional parameters (e.g., "charset=utf-8"), Internet media types provide a rich and scalable framework for encoding the type of any given entity. This approach is not applicable to CoAP, where content-formats conflate an Internet media type (potentially with specific parameters) and a content coding into one small integer value. To remedy this loss of flexibility, we introduce the concept of a "loose" media type mapping, where media types that are specializations of a more generic media type can be aliased to their super-class and then mapped (if possible) to one of the CoAP content- formats. For example, "application/soap+xml" can be aliased to "application/xml", which has a known conversion to CoAP. In the context of this "loose" media type mapping, "application/ octet-stream" can be used as a fallback when no better alias is found for a specific media type. Table 1 defines the default lookup table for the "loose" media type mapping. It is expected that an implementation can refine it because either application-specific knowledge is given or new Content-Formats are defined. Given an input media type, the table returns its best generalized media type using the most specific match, i.e., the table entries are compared to the input in top to bottom order until an entry matches. +-----------------------------+--------------------------+ | Internet media type pattern | Generalized media type | +-----------------------------+--------------------------+ | application/*+xml | application/xml | | application/*+json | application/json | | application/*+cbor | application/cbor | | text/xml | application/xml | | text/* | text/plain | | */* | application/octet-stream | +-----------------------------+--------------------------+ Table 1: Media Type Generalization Lookup Table The "loose" media type mapping is an OPTIONAL feature. Implementations supporting this kind of mapping should provide a flexible way to define the set of media type generalizations allowed.
6.4. Media Type to Content-Format Mapping Algorithm
This section defines the algorithm used to map an HTTP Internet media type to its correspondent CoAP content-format; it can be used as a building block for translating HTTP Content-Type and Accept headers into CoAP Content-Format and Accept Options. The algorithm uses an IANA-maintained table, "CoAP Content-Formats", as established by Section 12.3 of [RFC7252] plus, possibly, any locally defined extension of it. Optionally, the table and lookup mechanism described in Section 6.3 can be used if the implementation chooses so. Note that the algorithm assumes an "identity" Content-Encoding and expects the resource body has been already successfully content decoded or transcoded to the desired format. In the following (Figure 2): o media_type is the media type to translate; o coap_cf_registry is a lookup table matching the "CoAP Content- Formats" registry; and o loose_mapper is an optional lookup table describing the loose media type mappings (e.g., the one defined in Table 1). The full source code is provided in Appendix A.
def mt2cf(media_type, encoding=None, coap_cf_registry=CoAPContentFormatRegistry(), loose_mapper=None): """Return a CoAP Content-Format given an Internet media type and its optional encoding. The current (as of 2016/10/24) "CoAP Content-Formats" registry is supplied by default. An optional 'loose-mapping' implementation can be supplied by the caller.""" assert media_type is not None assert coap_cf_registry is not None # Lookup the "CoAP Content-Formats" registry content_format = coap_cf_registry.lookup(media_type, encoding) # If an exact match is not found and a loose mapper has been # supplied, try to use it to get a media type with which to # retry the "CoAP Content-Formats" registry lookup. if content_format is None and loose_mapper is not None: content_format = coap_cf_registry.lookup( loose_mapper.lookup(media_type), encoding) return content_format Figure 26.5. Content Transcoding
6.5.1. General
Payload content transcoding is an OPTIONAL feature. Implementations supporting this feature should provide a flexible way to define the set of transcodings allowed. The HC Proxy might decide to transcode the received representation to a different (compatible) format when an optimized version of a specific format exists. For example, an XML-encoded resource could be transcoded to Efficient XML Interchange (EXI) format, or a JSON- encoded resource into Concise Binary Object Representation (CBOR) [RFC7049], effectively achieving compression without losing any information. However, there are a few important factors to keep in mind when enabling a transcoding function: 1. Maliciously crafted inputs coming from the HTTP side might inflate in size (see, for example, Section 4.2 of [RFC7049]), therefore creating a security threat for both the HC Proxy and the target resource.
2. Transcoding can lose information in non-obvious ways. For
example, encoding an XML document using schema-informed EXI
encoding leads to a loss of information when the destination does
not know the exact schema version used by the encoder. That
means that whenever the HC Proxy transcodes "application/xml" to
"application/exi", in-band metadata could be lost.
3. When the Content-Type is mapped, there is a risk that the content
with the destination type would have malware not active in the
source type.
It is crucial that these risks are well understood and carefully
weighed against the actual benefits before deploying the transcoding
function.
6.5.2. CoRE Link Format
The CoRE Link Format [RFC6690] is a set of links (i.e., URIs and
their formal relationships) that is carried as content payload in a
CoAP response. These links usually include CoAP URIs that might be
translated by the HC Proxy to the correspondent HTTP URIs using the
implemented URI mapping function (see Section 5). Such a translation
process would inspect the forwarded traffic and attempt to rewrite
the body of resources with an application/link-format media type,
mapping the embedded CoAP URIs to their HTTP counterparts. Some
potential issues with this approach are:
1. The client may be interested in retrieving original (unaltered)
CoAP payloads through the HC Proxy, not modified versions.
2. Tampering with payloads is incompatible with resources that are
integrity protected (although this is a problem with transcoding
in general).
3. The HC Proxy needs to fully understand syntax and semantics
defined in [RFC6690], otherwise there is an inherent risk to
corrupt the payloads.
Therefore, CoRE Link Format payload should only be transcoded at the
risk and discretion of the proxy implementer.
6.6. Diagnostic Payloads
CoAP responses may, in certain error cases, contain a diagnostic
message in the payload explaining the error situation, as described
in Section 5.5.2 of [RFC7252]. If present, the CoAP diagnostic
payload SHOULD be copied into the HTTP response body with the media
type of the response set to "text/plain;charset=utf-8". The CoAP
diagnostic payload MUST NOT be copied into the HTTP reason-phrase, since it potentially contains CR-LF characters that are incompatible with HTTP reason-phrase syntax.
(page 21 continued on part 2)