tech-invite   World Map     

3GPP     Specs     Glossaries     Architecture     IMS     UICC       IETF     RFCs     Groups     SIP     ABNFs       Search

RFC 8075

Proposed STD
Pages: 40
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: CORE

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

Part 1 of 2, p. 1 to 21
None       Next Section

 


Top       ToC       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
                                                                   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.

Top      ToC       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
   (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.

Top       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       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       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       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       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       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
      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.

Top      ToC       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 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

Top      ToC       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
   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.

Top      ToC       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.

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

Top      ToC       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:

   ?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

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

Top      ToC       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="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"

Top      ToC       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
             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

Top      ToC       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
   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.

Top      ToC       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       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       Page 19 
 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 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       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
   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

Top      ToC       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