Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 8075

Guidelines for Mapping Implementations: HTTP to the Constrained Application Protocol (CoAP)

Pages: 40
Proposed Standard
Part 1 of 2 – Pages 1 to 21
None   None   Next

Top   ToC   RFC8075 - Page 1
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
                                                                 E. Dijk
                                                        Philips Lighting
                                                           February 2017

                Guidelines for Mapping Implementations:
          HTTP to the Constrained Application Protocol (CoAP)


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
Top   ToC   RFC8075 - Page 2
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
   ( 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.
Top   ToC   RFC8075 - Page 3

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
Top   ToC   RFC8075 - Page 4

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;
Top   ToC   RFC8075 - Page 5
   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
Top   ToC   RFC8075 - Page 6
       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
Top   ToC   RFC8075 - Page 7
   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'.
Top   ToC   RFC8075 - Page 8
   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

   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.
Top   ToC   RFC8075 - Page 9

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 and a Target CoAP URI coap://, the resulting Hosting HTTP URI would be 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
Top   ToC   RFC8075 - Page 10
   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 (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.
Top   ToC   RFC8075 - Page 11
   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. Examples
All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use 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:// => whereas coaps:// => 2. Target CoAP URI in the path component of the Hosting HTTP URI: forward/{+tu} coap:// => whereas coaps:// =>
Top   ToC   RFC8075 - Page 12
   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:




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. Examples
All the following examples (given as a specific URI mapping template, a Target CoAP URI, and the produced Hosting HTTP URI) use as the HC Proxy URI. 1. Target CoAP URI components in path segments and optional query in query component: {+s}/{+hp}{+p}{+qq} coap:// =>
Top   ToC   RFC8075 - Page 13



   2.  Target CoAP URI components split in individual query arguments:







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.
Top   ToC   RFC8075 - Page 14

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="";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=""; 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: Res: HTTP/1.1 200 OK Content-Type: application/link-format Content-Length: 19 </hc/>;rt="core.hc"
Top   ToC   RFC8075 - Page 15
   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

       Res:  HTTP/1.1 200 OK
             Content-Type: application/link-format+json
             Content-Length: 32


6. Media Type Mapping

6.1. Overview

An HC Proxy needs to translate HTTP media types (Section of [RFC7231]) and content codings (Section 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
Top   ToC   RFC8075 - Page 16
   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

   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.
Top   ToC   RFC8075 - Page 17

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.
Top   ToC   RFC8075 - Page 18

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.
Top   ToC   RFC8075 - Page 19
 def mt2cf(media_type, encoding=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 2

6.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.
Top   ToC   RFC8075 - Page 20
   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

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
Top   ToC   RFC8075 - Page 21
   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)

Next Section