One document matched: draft-castellani-core-advanced-http-mapping-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2046 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2046.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC3040 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3040.xml">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml">
<!ENTITY RFC4732 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4732.xml">
<!ENTITY RFC5988 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5988.xml">
<!ENTITY RFC6202 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6202.xml">
<!ENTITY RFC4287 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml">
<!ENTITY I-D.ietf-core-coap SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-coap-18.xml">
<!ENTITY I-D.ietf-core-observe SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-observe-08.xml">
<!ENTITY I-D.ietf-core-block SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-block-12.xml">
<!ENTITY I-D.ietf-core-groupcomm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-groupcomm-09.xml">
<!ENTITY I-D.bormann-core-simple-server-discovery SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-bormann-core-simple-server-discovery-01.xml">
<!ENTITY I-D.vanderstok-core-bc SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-vanderstok-core-bc-05.xml">
<!ENTITY I-D.ietf-httpbis-p1-messaging SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-httpbis-p1-messaging-22.xml">
<!ENTITY I-D.ietf-httpbis-p2-semantics SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-httpbis-p2-semantics-22.xml">
<!ENTITY I-D.thomson-hybi-http-timeout SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-thomson-hybi-http-timeout-03.xml">
<!ENTITY I-D.ietf-core-resource-directory SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-resource-directory-00.xml">
<!ENTITY I-D.snell-http-prefer SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-snell-http-prefer-18.xml">
<!ENTITY I-D.ietf-core-http-mapping SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-core-http-mapping-00.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc ipr="trust200902"
docName="draft-castellani-core-advanced-http-mapping-03" category='info'>
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ************************* Front Matter ************************ -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="HTTP-CoAP Mapping">
Guidelines for HTTP-CoAP Mapping Implementations
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author initials="A.P." surname="Castellani" fullname="Angelo P. Castellani">
<organization>University of Padova</organization>
<address>
<postal>
<street>Via Gradenigo 6/B</street>
<code>35131</code>
<city>Padova</city>
<country>Italy</country>
</postal>
<email>angelo@castellani.net</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>salvatore.loreto@ericsson.com</email>
</address>
</author>
<author initials="A." surname="Rahman" fullname="Akbar Rahman">
<organization>InterDigital Communications, LLC</organization>
<address>
<postal>
<street>1000 Sherbrooke Street West</street>
<city>Montreal</city>
<code>H3A 3G4</code>
<country>Canada</country>
</postal>
<phone>+1 514 585 0761</phone>
<email>Akbar.Rahman@InterDigital.com</email>
</address>
</author>
<author initials="T." surname="Fossati" fullname="Thomas Fossati">
<organization>KoanLogic</organization>
<address>
<postal>
<street>Via di Sabbiuno 11/5</street>
<city>Bologna</city>
<code>40136</code>
<country>Italy</country>
</postal>
<phone>+39 051 644 82 68</phone>
<email>tho@koanlogic.com</email>
</address>
</author>
<author initials="E." surname="Dijk" fullname="Esko Dijk">
<organization>Philips Research</organization>
<address>
<email>esko.dijk@philips.com</email>
</address>
</author>
<!-- Meta-data Declarations -->
<date year="2013" />
<area>APP</area>
<workgroup>CoRE Working Group</workgroup>
<keyword>CoAP</keyword>
<keyword>HTTP-CoAP mapping</keyword>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<abstract>
<t>This draft describes advanced features for HTTP-CoAP proxy implementors.
It details deployment options, discusses possible approaches for URI mapping,
and provides useful considerations related to protocol translation.</t>
</abstract>
</front>
<!-- ************************** Main Body ************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<middle>
<section title="Terminology and Conventions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in
<xref target="RFC2119">RFC 2119</xref>.</t>
<t>This document assumes readers are familiar with the terms
and concepts that are used in <xref target="I-D.ietf-core-coap"/> .
In addition, this document defines the following terminology: </t>
<t>A device providing cross-protocol HTTP-CoAP mapping is called an HTTP-CoAP
cross-protocol proxy (HC proxy).</t>
<!--
<t>Regular HTTP proxies are usually same-protocol proxies, because they can map from HTTP to HTTP.
CoAP same-protocol proxies are intermediaries for CoAP to CoAP exchanges.
However the discussion about these entities is out-of-scope of this document.</t>
-->
<t>At least two different kinds of HC proxies exist:
<list style="symbols">
<t>One-way cross-protocol proxy (1-way proxy):
This proxy translates from a client of a protocol to a server of another protocol but not vice-versa.</t>
<t>Two-way (or bidirectional) cross-protocol proxy (2-way proxy):
This proxy translates from a client of both protocols to a server supporting one protocol.</t>
</list>
</t>
</section>
<section title="Introduction">
<t>RESTful protocols, such as HTTP <xref target="RFC2616"/> and CoAP <xref target="I-D.ietf-core-coap"/>,
can interoperate through an intermediary proxy which performs cross-protocol mapping.</t>
<t>A base reference for the mapping process is provided in <xref target="I-D.ietf-core-coap"/>.
However, depending on the involved application, deployment scenario, or network topology,
such mapping can be realized using a wide range of intermediaries.</t>
<t>Moreover, the process of implementing such a proxy can be complex,
and details regarding its internal procedures and design choices
deserve further discussion, which is provided in this document.</t>
<t>This draft itself is an evolution of the mapping features covered in <xref target="I-D.ietf-core-http-mapping"/>.</t>
</section>
<section title="Use Case: HTTP/IPv4-CoAP/IPv6 Proxy" anchor="hc-v4v6">
<t>This section covers the expected common use case regarding an HTTP/IPv4 client accessing a CoAP/IPv6 resource.</t>
<t>While HTTP and IPv4 are today widely adopted communication protocols in the Internet,
a pervasive deployment of constrained nodes exploiting the IPv6 address space is expected:
enabling direct interoperability of such technologies is a valuable goal.</t>
<t>An HC proxy supporting IPv4/IPv6 mapping is said to be a v4/v6 proxy.</t>
<t>An HC v4/v6 proxy SHOULD always try to resolve the URI authority,
and SHOULD prefer using the IPv6 resolution if available.
The authority part of the URI is used internally by the HC proxy
and SHOULD NOT be mapped to CoAP.</t>
<t><xref target="fig-simple-http-coap"/> shows an HTTP client on IPv4 (C) accessing a CoAP server on IPv6 (S) through an HC proxy on IPv4/IPv6 (P). The DNS has an A record for "node.coap.something.net" resolving to the IPv4 address of the HC proxy, and an AAAA record with the IPv6 address of the CoAP server.</t>
<figure title="HTTP/IPv4 to CoAP/IPv6 Mapping" anchor="fig-simple-http-coap"><artwork>
<![CDATA[
C P S
| | |
| | | Source: IPv4 of C
| | | Destination: IPv4 of P
+---->| | GET /foo HTTP/1.1
| | | Host: node.coap.something.net
| | | ..other HTTP headers ..
| | |
| | | Source: IPv6 of P
| | | Destination: IPv6 of S
| +---->| CON GET
| | | URI-Path: foo
| | |
| | | Source: IPv6 of S
| | | Destination: IPv6 of P
| |<----+ ACK
| | |
| | | ... Time passes ...
| | |
| | | Source: IPv6 of S
| | | Destination: IPv6 of P
| |<----+ CON 2.00
| | | "bar"
| | |
| | | Source: IPv6 of P
| | | Destination: IPv6 of S
| +---->| ACK
| | |
| | | Source: IPv4 of P
| | | Destination: IPv4 of C
|<----+ | HTTP/1.1 200 OK
| | | .. other HTTP headers ..
| | |
| | | bar
| | |
]]>
</artwork></figure>
<t>The proposed example shows the HC proxy operating also the mapping between IPv4
to IPv6 using the authority information available in any HTTP 1.1 request.
This way, IPv6 connectivity is not required at the HTTP client
when accessing a CoAP server over IPv6 only, which is a typical expected use case.</t>
<t>When P is an interception HC proxy, the CoAP request SHOULD have the IPv6 address of C as source
(IPv4 can always be mapped into IPv6).</t>
<t>The described solution takes into account only the HTTP/IPv4 clients accessing CoAP/IPv6 servers;
this solution does not provide a full fledged mapping from HTTP to CoAP.</t>
<t>In order to obtain a working deployment for HTTP/IPv6 clients,
a different HC proxy access method may be required,
or Internet AAAA records should not point to the node anymore
(the HC proxy should use a different DNS database pointing to the node).</t>
<t>When an HC interception proxy deployment is used
this solution is fully working even with HTTP/IPv6 clients.</t>
</section>
<section title="Multiple Message Exchanges Mapping">
<t>This section discusses the mapping of the multicast and observe features of CoAP,
which have no corresponding primitive in HTTP, and as such are not immediately translatable.</t>
<t>The mapping, which must be considered in both the arrow directions (H->C, C->H)
may involve multi-part responses, as in the multicast use case, asynchronous delivery through HTTP bidirectional techniques,
and HTTP Web Linking in order to reduce the semantics lost in the translation.</t>
<section title="Relevant Features of Existing Standards">
<t>Various features provided by existing standards are useful to efficiently represent sessions involving multiple messages.</t>
<section title="Multipart Messages" anchor="hc-multipart">
<t>In particular, the "multipart/*" media type, defined in Section 5.1 of <xref target="RFC2046"/>,
is a suitable solution to deliver multiple CoAP responses within a single HTTP payload.
Each part of a multipart entity SHOULD be represented using "message/http" media type
containing the full mapping of a single CoAP response as previously described.</t>
</section>
<section title="Immediate Message Delivery">
<t>An HC proxy may prefer to transfer each CoAP response immediately after its reception.
This is possible thanks to the HTTP Transfer-Encoding "chunked",
that enables transferring single responses without any further delay.</t>
<t>A detailed discussion on the use of chunked Transfer-Encoding to stream data
over HTTP can be found in <xref target="RFC6202"/>.
Large delays between chunks can lead the HTTP session to timeout,
more details on this issue can be found in <xref target="I-D.thomson-hybi-http-timeout"/>.</t>
<t>An HC proxy MAY prefer (e.g. to avoid buffering) to transfer each response related to a multicast request as soon as it comes in from the server.
One possible way to achieve this result is using the "chunked" Transfer-Encoding in the HTTP response,
to push individual responses until some trigger is fired (timeout, max number of messages, etc.).</t>
<t>An example showing immediate delivery of CoAP responses using HTTP chunks will be provided in <xref target="hc-subscription"/>,
while describing its application to an observe session.</t>
</section>
<section title="Detailing Source Information">
<t>Under some circumstances, responses may come from different sources (i.e. responses to a multicast request);
in this case details about the actual source of each CoAP response MAY be provided to the client.
Source information can be represented using HTTP Web Linking as defined in <xref target="RFC5988"/>,
by adding the actual source URI into each response using Link option with "via" relation type.</t>
</section>
</section> <!-- standard features section -->
<section title="Multicast Mapping" anchor="hc-multicast">
<t>In order to establish a multicast communication such a feature should be offered either
by the network (i.e. IP multicast, link-layer multicast, etc.) or by a gateway (i.e. the HC proxy).
Rationale on the methods available to obtain such a feature is out-of-scope of this document, and
extensive discussion of group communication techniques is available in
<xref target="I-D.ietf-core-groupcomm"/>.</t>
<t>Additional considerations related to handling multicast requests mapping are detailed in the
following sections.</t>
<section title="URI Identification and Mapping">
<t>In order to successfully handle a multicast request, the HC proxy MUST successfully perform the
following tasks on the URI:
<list style="hanging">
<t hangText="Identification:">The HC proxy MUST understand whether the requested URI identifies a group of nodes.</t>
<t hangText="Mapping:">The HC proxy MUST know how to distribute the multicast request to involved servers;
this process is specific of the group communication technology used.</t>
</list></t>
<t>When using IPv6 multicast paired with DNS,
the mapping to IPv6 multicast is simply done using DNS resolution.
If the group management is performed at the proxy,
the URI or part of it (i.e. the authority) can be mapped using some static or
dynamic table available at the HC proxy.
In Section 3.5 of <xref target="I-D.ietf-core-groupcomm"/> discusses a method to build
and maintain a local table of multicast authorities.</t>
</section>
<section title="Request Handling">
<t>When the HC proxy receives a request to a URI
that has been successfully identified and mapped to a group of nodes,
it SHOULD start a multicast proxying operation, if supported by the proxy.</t>
<t>Multicast request handling consists of the following steps:
<list style="hanging">
<t hangText="Multicast TX:">The HC proxy sends out the request on the CoAP side
by using the methods offered by the specific group communication technology used in the constrained network;</t>
<t hangText="Collecting RXs:">The HC proxy collects every response related to the request;</t>
<t hangText="Timeout:">The HC proxy has to pay special attention in multicast timing,
detailed discussion about timing depends upon the particular group communication technology used;</t>
<t hangText="Distributing RXs to the client:">The HC proxy can distribute the responses in two different ways:
batch delivering them at the end of the process or on timeout,
or immediately delivering them as they are available.
Batch requires more caching and introduces delays but may lead to lower TCP overhead and simpler processing.
Immediate delivery is the converse.
A trade-off solution of partial batch delivery may also be feasible and efficient in some circumstances.</t>
</list></t>
</section>
<section title="Examples">
<t><xref target="fig-multicast-http-coap"/> shows an HTTP client (C) requesting the resource "/foo"
to a group of CoAP servers (S1/S2/S3) through an HC proxy (P) which uses IP multicast to send the
corresponding CoAP request.</t>
<figure title="Unicast HTTP to Multicast CoAP Mapping" anchor="fig-multicast-http-coap"><artwork>
<![CDATA[
C P S1 S2 S3
| | | | |
+---->| | | | GET /foo HTTP/1.1
| | | | | Host: group-of-nodes.coap.something.net
| | | | | .. other HTTP headers ..
| | | | |
| +---->|---->|---->| NON GET
| | | | | URI-Path: foo
| | | | |
| |<----------+ | NON 2.00
| | | | | "S2"
| | | | |
| | X---------------+ NON 2.00
| | | | | "S3"
| | | | |
| |<----+ | | NON 2.00
| | | | | "S1"
| | | | |
| | | | | ... Timeout ...
| | | | |
|<----+ | | | HTTP/1.1 200 OK
| | | | | Content-Type: multipart/mixed;
| | | | | boundary="response"
| | | | | .. other HTTP headers ..
| | | | |
| | | | | --response
| | | | | Content-Type: message/http
| | | | |
| | | | | HTTP/1.1 200 OK
| | | | | Link: <http://node2.coap.something.net/foo>;
| | | | | rel=via
| | | | |
| | | | | S2
| | | | |
| | | | | --response
| | | | | Content-Type: message/http
| | | | |
| | | | | HTTP/1.1 200 OK
| | | | | Link: <http://node1.coap.something.net/foo>;
| | | | | rel=via
| | | | |
| | | | | S1
| | | | |
| | | | | --response--
| | | | |
]]>
</artwork></figure>
<t>The example proposed in the above diagram does not make any assumption
on which underlying group communication technology is available in the constrained network.
Some detailed discussion is provided about it along the following lines.</t>
<t>C makes a GET request to group-of-nodes.coap.something.net.
This domain name MAY either resolve to the address of P,
or to the IPv6 multicast address of the nodes (if IP multicast is supported and P is an interception proxy),
or the proxy P is specifically known by the client that sends this request to it.</t>
<t>To successfully start multicast proxying operation,
the HC proxy MUST know that the destination URI involves a group of CoAP servers,
e.g. the authority group-of-nodes.coap.something.net is known to identify a group of nodes
either by using an internal lookup table, using DNS paired with IPv6 multicast, or by using some
other special technique.</t>
<t>A specific implementation option is proposed to further explain the proposed example.
Assume that DNS is configured such that all subdomain queries to coap.something.net,
such as group-of-nodes.coap.something.net, resolve to the address of P.
P performs the HC URI mapping by removing the 'coap' subdomain from the authority and by switching
the scheme from 'http' to 'coap'
(result: "coap://group-of-node.something.net/foo");
"group-of-nodes.something.net" is resolved to an IPv6 multicast address to which S1, S2 and S3 belong.
The proxy handles this request as multicast and sends the request "GET /foo" to the multicast group .</t>
</section>
</section> <!-- multicast section -->
<section title="Multicast Response Caching" anchor="mcast-caching">
<t>We call perfect caching when the proxy uses only the cached representations to provide a response to the HTTP client.
In the case of a multicast CoAP request, perfect caching is not adequate. This section
updates the general caching and congestion control guidelines of with specific
guidelines for the multicast use case.</t>
<t>Due to the inherent unreliable nature of the NON messages involved
and since nodes may have dynamic membership in multicast groups,
responding only with previously cached responses
without issuing a new multicast request is not recommended.
This perfect caching behaviour leads to miss responses of nodes that later joined the multicast group,
and/or to repeatedly serve partial representations due to message losses.
Therefore a multicast CoAP request SHOULD be sent by a HC proxy for each incoming request
addressed to a multicast group.</t>
<t>Caching of multicast responses is still a valuable goal to pursue reduce network congestion, battery consumption and response latency.
Some considerations to be performed when adopting a multicast caching behaviour are outlined in the following paragraph.</t>
<t>Caching of multicast GET responses MAY be implemented by adopting some technique that takes into account
either knowledge about dynamic characteristics of group membership (occurrence or frequency of group changes)
or even better its full knowledge (list of nodes currently part of the group).</t>
<t>When using a technique exploiting this knowledge, valid cached responses SHOULD be served from cache.</t>
<!--
<t>As a caching strategy, CoAP-observe MAY be used for multicast request caching
[TBD: multicast operation is not defined explicitly in CoAP-observe but it should work?].
ETag MUST NOT be used by a HC proxy in a CoAP multicast request because an ETag value is only valid
in context of a single CoAP server, not for a group of servers.
</t>
<t>[TBD] What about serving a cached valid response from server A,
while later in time an updated response comes in from server A with other payload?
Should HC proxy always wait for new responses first? Or cache the new response and
not serve this to the client? Or serve updated responses asynchronously over HTTP?
</t>
-->
</section> <!-- multicast caching section -->
<section title="Observe Mapping" anchor="hc-subscription">
<t>By design, and certainly not without a good rationale, HTTP lacks a publish-subscriber facility. This implies that the mapping of the CoAP observe semantics has to be created ad hoc, perhaps by making use of one of the well-known HTTP techniques currently employed to establish an HTTP bidirectional connection with the target resource - as documented in <xref target="RFC6202"/>.</t>
<t>In the following sections we will describe some of the approaches that can be used to identify an observable resource and to create the communication bridging needed to set up an end to end HTTP-CoAP observation.</t>
<section title="Identification" anchor="hc-sub-identification">
<t>In order to appropriately process an observe request, the HC proxy needs to know whether a given request is intended to establish an observation on the target resource, instead of triggering a regular request-response exchange.</t>
<t>At least two different approaches to identify such special requests exist, as discussed below.</t>
<section title="Observable URI Mapping">
<t>An URI is said to be observable whenever every request to it implicitly requires the establishment of an HTTP bidirectional connection to the resource.</t>
<t>Such subscription to the resource is always paired, if possible, to a CoAP observe session to the actual resource being observed. In general, multiple connections that are active with a single observable resource at the same time, are multiplexed to the single observe session opened by the intermediary. Its notifications are then de-multiplexed by the HC proxy to every HTTP subscriber.</t>
<t>An intermediary MAY pair a couple of distinct HTTP URIs to a single CoAP observable resource: one providing the usual request-response mediated access to the resource, and the other that always triggers a CoAP observe session.</t>
<section title="Discovery" anchor="hc-obs-resources">
<t>As shown in <xref target="OPTIONSLink" />, in order to know whether an URI is observable, an HTTP UA MAY do a pre-flight request to the target resource using the HTTP OPTIONS method (see section 6.2 of <xref target="I-D.ietf-httpbis-p2-semantics" />) to discover the communication options available for that resource.</t>
<t>If the resource supports observation, the proxy adds a Link Header <xref target="RFC5988" /> with the "obs" attribute as link-param (see Section 7 of <xref target="I-D.ietf-core-observe" />).</t>
<figure title="Discover Observability with HTTP OPTIONS" anchor="OPTIONSLink">
<artwork>
<![CDATA[
C P S
| | | OPTIONS /kitchen/temp HTTP/1.1
+------>| | Host: node.coap.something.net
| | |
| +------>| CON GET
| | | Uri-Path: /.well-known/core?anchor=/kitchen/temp
| | |
| |<------+ ACK 2.05
| | | Payload: </kitchen/temp>;obs
| | |
|<------+ | HTTP/1.1 200 OK
| | | Link: </kitchen/temp>; obs;
| | | type="application/atom+xml"
| | | Allow: GET, OPTIONS
]]>
</artwork>
</figure>
<!-- <t>TODO: how do we fill the Allow field?</t> -->
</section>
</section>
<section title="Differentiation Using HTTP Header">
<t>Discerning an observation request through in-protocol means, e.g. via the presence and values of some HTTP metadata, avoids introducing static "observable" URIs in the HC proxy namespace. Though ideally the former should be preferred, there seems to be no standard way to use one of the established HTTP headers to convey the observe semantics.</t>
<t>Standardizing such methods is out-of-scope of this document, so we just point out some possible approaches that in the future may be used to differentiate observation requests from regular requests.</t>
<section title="Expect Header">
<t>The first method involves the use of the Expect header as defined in Section 9.3 of <xref target="I-D.ietf-httpbis-p2-semantics" />. Whenever an HC proxy receives a request with a "206-partial-content" expectation, the proxy MUST fulfill this expectation by pairing this request to either a new or existing observe session to the resource.</t>
<t>If the proxy is unable to observe the resource, or if the observation establishment fails, the proxy MUST reply to the client with "417 Expectation Failed" status code.</t>
<t>Given that the Expect header is processed hop-by-hop, this method will fail immediately in case a proxy not supporting this expectation is traversed. For this reason, at present, the said approach can't be used in the public Internet.</t>
</section>
<section title="Prefer Header">
<t>A second, very similar, approach involves the use of the Prefer header, defined in <xref target="I-D.snell-http-prefer"/>. The HTTP user agent expresses the preference to establish an observation with the target resource by including a "streaming" preference to request an HTTP Streaming session, or a "long-polling" preference to signal to the proxy its intended polling behaviour (see <xref target="RFC6202"/>).</t>
<!-- XXX Is it necessary to signal the "long-polling" option: isn't it transparent to the server/proxy ? -->
<t>A compliant HC proxy will try to fulfill the preference, and manifest observation establishment success by responding with a status code of "206 Partial Content". The observation request fails, falling back to a single response, whenever the status code is different from 206.</t>
<t>This approach will never fail immediately, differently from the previous one, even across a chain of unaware proxies; however, as documented in <xref target="RFC6202"/>, caching intermediaries may interfere, delay or block the HTTP bidirectional connection, making this approach unacceptable when no weak consistency of the resource can be tolerated by the requesting UA.</t>
</section>
</section>
</section>
<section title="Notification(s) Mapping" anchor="hc-sub-mapping">
<t>Multiplexing notifications using a single HTTP bidirectional session needs some further considerations about the selection of the media type that best fits this specific use case.</t>
<t>The usage of two different content-types that are suitable for carrying multiple notifications in a single session, is discussed in the following sections.</t>
<section title="Multipart Messaging" anchor="hc-multipart-obs">
<t>As already discussed in <xref target="hc-multipart"/> for multicasting, the "multipart/*" media type is a suitable solution to deliver multiple CoAP notifications within a single HTTP payload.</t>
<t>As in the multicast case, each part of the multipart entity MAY be represented using a "message/http" media type, containing the full mapping of the single CoAP notification mapped, so that CoAP envelope information are preserved (e.g. the response code).</t>
<t>A more sophisticated mapping could use multipart/mixed with native or translated media type.</t>
</section>
<section title="Using ATOM Feeds">
<t>Popular observable resources with refresh rates higher than a couple of seconds may be treated as Atom feeds <xref target="RFC4287" />, especially with delay tolerant user agents and where persistence is required.</t>
<t><xref target="OPTIONSLink" /> shows a resource supporting 'application/atom+xml' media-type. In such case clients can listen to update notification by regularly polling the resource via opportunely spaced GETs, i.e. driven by the advertised max-age value.</t>
</section>
</section>
<section title="Examples" anchor="hc-sub-example">
<t><xref target="fig-streaming2observe"/> shows the interaction between an HTTP client (C),
an HC proxy (P), and a CoAP server (S) for the observation of the resource "temperature" (T)
available on S.</t>
<t>C manifests its intention to observe T by including the Expect Header in the request;
if P or S do not support this interaction, the request MUST fail with "417 Expectation Failed" return code.
In the presented example, both P and C support this interaction, and the subscription is successful,
as stated by the "206 Partial Content" return code.</t>
<t>At every notification corresponds the emission of a HTTP chunk containing a single part,
which contains a "message/http" payload containing the full mapping of the notification.
When the observation is dropped by the CoAP server, the HTTP streaming session is closed.</t>
<figure title="HTTP Streaming to CoAP Observe" anchor="fig-streaming2observe"><artwork>
<![CDATA[
C P S
| | |
+---->| | GET /temperature HTTP/1.1
| | | Host: node.coap.something.net
| | | Expect: 206-partial-content
| | | Accept: multipart/mixed
| | |
| +---->| CON GET
| | | Uri-Path: temperature
| | | Observe: 0
| | |
| |<----+ ACK 2.05
| | | Observe: 3482
| | | "22.1 C"
| | |
|<----+ | HTTP/1.1 206 Partial Content
| | | Content-Type: multipart/mixed; boundary=notification
| | |
| | | XX
| | | --notification
| | | Content-Type: message/http
| | |
| | | HTTP/1.1 200 OK
| | |
| | | 22.1 C
| | |
| | | ... about 60 seconds have passed ...
| | |
| |<----+ NON 2.05
| | | Observe: 3542
| | | "21.6 C"
| | |
|<----+ | YY
| | | --notification
| | | Content-Type: message/http
| | |
| | | HTTP/1.1 200 OK
| | |
| | | 21.6 C
| | |
| | | ... if the server drops the relationship ...
| | |
| |<----+ NON 2.05
| | | "21.8 C"
| | |
|<----+ | ZZ
| | | --notification
| | | Content-Type: message/http
| | |
| | | HTTP/1.1 200 OK
| | |
| | | 21.8 C
| | |
| | | --notification--
| | |
| | | 0
]]>
</artwork></figure>
<t><xref target="fig-longpolling2observe"/> shows the interaction between an HTTP client (C),
an HC proxy (P), and a CoAP server (S) for the observation of the resource "temperature" (T)
available on S.</t>
<t>C manifests its intention to observe T by including the Prefer Header in the request;
if P or S do not support this interaction, the request silently fails if a status code "200 OK" is returned,
which means that no further notification is expected on that session.</t>
<t>In the presented example, both P and C support this interaction, and the subscription is successful,
as stated by the "206 Partial Content" status code.
At every notification a new response is sent to the pending client,
always containing the "206 Partial Content" status code,
to indicate that the observe session is still active,
so that C can issue a new long-polling request immediately after this notification.</t>
<t>If the observation relationship is dropped by S,
P notifies the last received content using the "200 OK" status code,
indicating that no further notification is expected on this observe session.</t>
<figure title="HTTP Long Polling to CoAP Observe" anchor="fig-longpolling2observe"><artwork>
<![CDATA[
C P S
| | |
+---->| | GET /temperature HTTP/1.1
| | | Host: node.coap.something.net
| | | Prefer: long-polling
| | |
| +---->| CON GET
| | | Uri-Path: temperature
| | | Observe: 0
| | |
| |<----+ ACK 2.05
| | | Observe: 3482
| | | "22.1 C"
| | |
|<----+ | HTTP/1.1 206 Partial Content
| | |
| | | 22.1 C
| | |
+---->| | GET /temperature HTTP/1.1
| | | Host: node.coap.something.net
| | | Prefer: long-polling
| | |
| | | ... about 60 seconds have passed ...
| | |
| |<----+ NON 2.05
| | | Observe: 3542
| | | "21.6 C"
| | |
|<----+ | HTTP/1.1 206 Partial Content
| | |
| | | 21.6 C
| | |
+---->| | GET /temperature HTTP/1.1
| | | Host: node.coap.something.net
| | | Prefer: long-polling
| | |
| | | ... if the server drops the relationship ...
| | |
| |<----+ NON 2.05
| | | "21.8 C"
| | |
|<----+ | HTTP/1.1 200 OK
| | |
| | | 21.8 C
]]>
</artwork></figure>
<t><xref target="fig-atom2observe"/> shows the interaction between an HTTP client (C), an HC proxy (P), and a CoAP server (S) for the observation of the resource "kitchen/temp" (T) available on S.</t>
<t>It is assumed that the HC proxy knows that the requested resource is observable (since perhaps being asked beforehand to discover its properties as described in <xref target="OPTIONSLink" />.) When asked by the HTTP client to retrieve the resource, it requests an observation - in case it weren't already in place - and then sends the collected data to the client as an Atom feed. The data coming through in the constrained network is stored locally on the proxy, and forwarded when further requests are received on the HTTP side. As already said, using the Atom format has two main advantages: first, there is always a "current" feed, but there may also be a complete log made available to HTTP clients; secondly, the HTTP intermediaries can play a substantial role in absorbing a fair amount of the load on the HC proxy. The latter is a very important property when the requested resource is or becomes very popular.</t>
<figure title="Observation via Atom feeds" anchor="fig-atom2observe">
<artwork>
<![CDATA[
C P S
| | | GET /kitchen/temp HTTP/1.1
+------>| | Host: node.coap.something.net
| | |
| +------>| CON GET
| | | Uri-Path: kitchen/temp
| | | Observe: 0
| | |
| |<------+ ACK 2.05
| | | Observe: 1000
| | | Max-Age: 10
| | | "22.3 C"
| | |
|<------+ | HTTP/1.1 200 OK
| | | Cache-Control: max-age=10
| | | ETag: "0x5555"
| | | Content-Type: application/atom+xml
| | |
| | | <feed xmlns="http://www.w3.org/2005/Atom">
| | | <entry>
| | | <id>urn:uuid:
| | | bf08203a-fbbf-49e8-bf11-3c4cff708525</id>
| | | <updated>2012-03-07T11:14:30</updated>
| | | <content type="text/plain">
| | | 22.3 C
| | | </content>
| | | <entry>
| | | </feed>
| | |
| | |
| |<------+ NON 2.05
| | | Observe: 1010
| | | Max-Age: 10
| | | "22.4 C"
| | |
+------>| | GET /kitchen/temp HTTP/1.1
| | | Host: node.coap.something.net
| | |
| | | [...]
| | |
]]>
</artwork>
</figure>
</section>
</section> <!-- subscription section -->
</section>
<section title="HTML5 Scheme Handler Registration" anchor="HTML5-mapping">
<t>The draft HTML5 standard offers a mechanism that allows an HTTP user agent
to register a custom scheme handler through an HTML5 web page.
This feature permits to an HC proxy to be registered as "handler" for URIs with the 'web+coap' or 'web+coaps' schemes
using an HTML5 web page which embeds the custom scheme handler registration call registerProtocolHandler()
described in Section 6.5.1.2 of <xref target="W3C.HTML5" />.</t>
<t>Example: the HTML5 homepage of a HC proxy at h2c.example.org could include the method call:</t>
<figure><artwork align="center"><![CDATA[
registerProtocolHandler('web+coap','proxy?url=%s','example HC proxy')
]]></artwork></figure>
<t>This registration call will prompt the HTTP user agent to ask for the user's permission
to register the HC proxy as a handler for all 'web+coap' URIs.
If the user accepts, whenever a 'web+coap' link is requested,
the request will be fulfilled through the HC proxy:
URI "web+coap://foo.org/a" will be transformed into
URI "http://h2c.example.org/proxy?url=web+coap://foo.org/a".
</t>
</section>
<section anchor="CoAP_Placement_Deployment" title="Placement and Deployment">
<t>In typical scenarios, for communication from a CoAP client to an HTTP origin server,
the HC proxy is expected to be located on the client-side (CS). Specifically, the
HC proxy is expected to be deployed at the edge of the constrained network as shown
in <xref target="fig-coap-http-deployment"/>.</t>
<t>The arguments supporting CS placement are as follows:
<list style="hanging">
<t hangText="Client/Proxy/Network configuration overhead:">CoAP clients require
either static proxy configuration or proxy discovery support. This overhead is
simplified if the proxy is placed on the same network domain of the client.</t>
<t hangText="TCP/UDP:">Translation between CoAP and HTTP requires also UDP to TCP mapping;
UDP performance over the unconstrained Internet may not be adequate.
In order to minimize the number of required retransmissions on the constrained part of the network and the overall reliability,
TCP/UDP conversion SHOULD be performed as soon as possible in the network path.</t>
<t hangText="Caching:">Efficient caching requires that all the CoAP traffic is intercepted by the same proxy,
thus a CS placement, collecting all the traffic, is strategic for this need.</t>
</list></t>
<figure title="Client-side HC Proxy Deployment Scenario" anchor="fig-coap-http-deployment"><artwork>
<![CDATA[
+------+
| |
| DNS |
| |
+------+
--------------------
// \\
/ /-----\ /---\ \
/ CoAP CoAP \
|| client client ||
+----------+ \-----/ \-----/ ||
| HTTP/CoAP| /-----\ ||
| Proxy | CoAP ||
|(HC Proxy)| client ||
+------+ +----------+ \-----/ ||
|HTTP | || /-----\ ||
|Origin| || CoAP ||
|Server| \ client /-----\ /
+------+ \ \-----/ CoAP /
\ client /
\\ \-----/ //
------------------
]]>
</artwork></figure>
</section>
<section title="Examples">
<t><xref target="fig-basic-coap-http"/> shows an example implementation of a basic CoAP GET
request with an HTTP URI as the value of a Proxy-URI option. The proxy
retrieves a representation of the target resource from the HTTP origin
server. It converts the payload to a UTF-8 charset, calculates the
Max-Age Option from the Expires header field, and derives an entity-tag
from the ETag header field.</t>
<figure title="A Basic CoAP-HTTP GET Request" anchor="fig-basic-coap-http"><artwork>
<![CDATA[
C P S
| | |
+---------->| | CoAP Header: GET (T=CON, Code=1, MID=0x1633)
| CoAP | | Token: 0x5a
| Get | | Proxy-URI: http://www.example.com/foo/bar
| | |
| | |
| +---------->| HTTP/1.1 GET /foo/bar
| | HTTP | Host: www.example.com
| | GET |
| | |
| | |
|<----------+ | CoAP Header: (T=ACK, Code=0, MID=0x1633)
| | |
| | |
| |<----------+ HTTP/1.1 200 OK
| | HTTP | Date: Friday, 14 Oct 2011 15:00:00 GMT
| | 200 OK | Content-Type: text/plain; charset=iso-8859-1
| | | Content-Length: 11
| | | Expires: Friday, 14 Oct 2011 16:00:00 GMT
| | | ETag: "xyzzy"
| | | Connection: close
| | |
| | | Hello World
| | |
| | |
|<----------+ | CoAP Header: 2.00 OK
| | | (T=CON, Code=64, MID=0xAAFO)
| CoAP | | Token: 0x5a
| 2.00 OK | | C-Type: text/plain; charset=utf-8
| | | Max-Age: 3600
| | | ETag: 0x78797A7A79
| | | Payload: "Hello World"
| | |
+---------->| | CoAP Header: (T=ACK, Code=0, MID=0xAAF0)
]]>
</artwork></figure>
<t>The example in <xref target="fig-complex-coap-http"/> builds on the previous
example and shows an implementation of a GET request that includes a
previously returned ETag Option. The proxy makes a Conditional Request
to the HTTP origin server by including an If-None-Match header field
in the HTTP GET Request. The CoAP response indicates that the response
stored by the client is fresh. It includes a Max-Age Option calculated
from the HTTP response's Expires header field.</t>
<figure title="A CoAP-HTTP GET Request with an ETag Option" anchor="fig-complex-coap-http"><artwork>
<![CDATA[
C P S
| | |
+---------->| | CoAP Header: GET (T=CON, Code=1, MID=0x1CBO)
| CoAP | | Token: 0x7b
| Get | | Proxy-URI: http://www.example.com/foo/bar
| | | ETag: 0x78797A7A79
| | |
| | |
| +---------->| HTTP/1.1 GET /foo/bar
| | HTTP | Host: www.example.com
| | GET | If-None-Match: "xyzzy"
| | |
| | |
|<----------+ | CoAP Header: (T=ACK, Code=0, MID=0x1CBO)
| | |
| | |
| |<----------+ HTTP/1.1 304 Not Modified
| | HTTP | Date: Friday, 14 Oct 2011 17:00:00 GMT
| | 304 | Expires: Friday, 14 Oct 2011 18:00:00 GMT
| | | ETag: "xyzzy"
| | | Connection: close
| | |
| | |
|<----------+ | CoAP Header: 2.03 Valid
| | | (T=CON, Code=67, MID=0xAAFF)
| CoAP | | Token: 0x7b
| 2.03 | | Max-Age: 3600
| | | ETag: 0x78797A7A79
| | |
| | |
+---------->| | CoAP Header: (T=ACK, Code=0, MID=0xAAFF)
]]>
</artwork></figure>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>TBD.</t>
</section>
<!-- Possibly a 'Contributors' section ... -->
<section anchor="IANA" title="IANA Considerations">
<t>This memo includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<section anchor="sec_mapping" title="Cross-protocol Security Policy Mapping">
<t>At the moment of this writing, CoAP and HTTP are missing any cross-protocol security policy mapping.</t>
<t>The HC proxy SHOULD flexibly support security policies between the two protocols,
possibly as part of the HC URI mapping function,
in order to statically map HTTP and CoAP security policies at the proxy
(see <xref target="appendix_secpol_map" /> for an example.)</t>
</section>
<section title="Subscription">
<!-- TODO ask Klaus about observe + intermediaries and loops (Sec 7. of draft-ietf-core-observe-02). -->
<t>As noted in Section 7 of <xref target="I-D.ietf-core-observe" />,
when using the observe pattern, an attacker could easily impose resource exhaustion on a naive server
who's indiscriminately accepting observer relationships establishment from clients.
The converse of this problem is also present, a malicious client may also target the HC proxy itself,
by trying to exhaust the HTTP connection limit of the proxy by opening multiple subscriptions to some CoAP resource.</t>
<t>Effective strategies to reduce success of such a DoS on the HTTP side
(by forcing prior identification of the HTTP client via usual web authentication mechanisms),
must always be weighted against an acceptable level of usability of the exposed CoAP resources.</t>
</section>
</section>
</middle>
<!-- ************************** Back Matter ************************ -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<!-- **************************************************************** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
&RFC2046;
&RFC2119;
&RFC2616;
&RFC3986;
&RFC5988;
&RFC4287;
&I-D.ietf-core-coap;
&I-D.ietf-core-observe;
&I-D.ietf-core-block;
&I-D.ietf-core-groupcomm;
&I-D.ietf-httpbis-p1-messaging;
&I-D.ietf-httpbis-p2-semantics;
&I-D.thomson-hybi-http-timeout;
&I-D.ietf-core-http-mapping;
</references>
<references title="Informative References">
&RFC3040;
&RFC4732;
&RFC6202;
&I-D.snell-http-prefer;
&I-D.vanderstok-core-bc;
&I-D.bormann-core-simple-server-discovery;
&I-D.ietf-core-resource-directory;
<reference anchor="W3C.HTML5" target="http://dev.w3.org/html5/spec/">
<front><title>HTML5</title><author initials="I." surname="Hickson" fullname="Ian Hickson"><organization/></author><date month="October" day="18" year="2011"/></front><seriesInfo name="World Wide Web Consortium WD (work in progress)" value="WD-html5-20111018"/><format type="HTML" target="http://dev.w3.org/html5/spec/Overview.html"/>
</reference>
</references>
<section title="Internal Mapping Functions (from an Implementer's Perspective)">
<t>At least three mapping functions have been identified,
which take place at different stages of the HC proxy processing chain,
involving the URL, Content-Type and Security Policy translation.</t>
<t>All these maps are required to have at least URL granularity so that, in principle,
each and every requested URL may be treated as an independent mapping source.</t>
<t>In the following, the said map functions are characterized via their expected input and output,
and a simple, yet sufficiently rich, configuration syntax is suggested.</t>
<t>In the spirit of a document providing implementation guidance,
the specification of a map grammar aims at putting the basis for a reusable software component (e.g. a stand-alone C library)
that many different proxy implementations can link to, and benefit from.</t>
<section title="URL Map Algorithm">
<t>In case the HC proxy is a reverse proxy, i.e. it acts as the origin server in face of the served network,
the URL of the resource requested by its clients (perhaps having an 'http' scheme) shall be mapped to the real resource origin (perhaps in the 'coap' scheme).</t>
<t>In case HC is a forward proxy, no URL translation is needed since the client already knows the "real name" of the resource.</t>
<t>An interception HC proxy, instead, MAY use the homogeneous mapping strategy to operate without any pre-configuration need.</t>
<t>As noted in Appendix B of <xref target="RFC3986" /> any correctly formatted URL can be matched by a POSIX regular expression.
By leveraging on this property, we suggest a syntax that describes the URL mapping
in terms of substituting the regex-matching portions of the requested URL into the mapped URL template.</t>
<t>E.g.: given the source regular expression '^http://example.com/coap/.*$' and destination template 'coap://$1' (where $1 stands for the first - and only in this specific case - substring matched by the regex pattern in the source), the input URL "http://example.com/coap/node1/resource2" translates to "coap://node1/resource2".</t>
<t>This is a well established technique used in many todays web components (e.g. Django URL dispatcher, Apache mod_rewrite, etc.), which provides a compact and powerful engine to implement what essentially is an URL rewrite function.</t>
<figure><artwork><![CDATA[
INPUT
* requested URL
OUTPUT
* target URL
SYNTAX
url_map [rule name] {
requested_url <regex>
mapped_url <regex match subst template>
}
EXAMPLE 1
url_map homogeneous {
requested_url '^http://.*$'
mapped_url 'coap//$1'
}
EXAMPLE 2
url_map embedded {
requested_url '^http://example.com/coap/.*$'
mapped_url 'coap//$1'
}
]]></artwork></figure>
<t>Note that many different url_map records may be given in order to build the whole mapping function. Each of these records can be queried (in some predefined order) by the HC proxy until a match is found, or the list is exhausted. In the latter case, depending on the mapping policy (only internal, internal then external, etc.) the original request can be refused, or the same mapping query is forwarded to one or more external URL mapping components.</t>
</section> <!-- End of "URL Map Algorithm" -->
<section title="Security Policy Map Algorithm" anchor="appendix_secpol_map">
<t>In case the "incoming" URL has been successfully translated, the HC proxy must lookup the security policy, if any, that needs to be applied to the request/response transaction carried on the "outgoing" leg.</t>
<figure><artwork align="center"><![CDATA[
INPUT
* target URL (after URL map has been applied)
* original requester identity (given by cookie, or IP address, or
crypto credentials/security context, etc.)
OUTPUT
* security context that will be applied to access the target URL
SYNTAX
sec_map [rule name] {
target_url <regex> -- one or more
requester_id <TBD>
sec_context <TBD>
}
EXAMPLE
<TBD>
]]></artwork></figure>
</section> <!-- End of "Security Policy Map Algorithm" -->
<section title="Content-Type Map Algorithm">
<t>In case a set of destination URLs is known as being limited in handling a narrow subset of mime types, a content-type map can be configured in order to let the HC proxy transparently handle the compatible/lossless format translation.</t>
<figure><artwork align="center"><![CDATA[
INPUT
* destination URL (after URL map has been applied)
* original content-type
OUTPUT
* mapped content-type
SYNTAX
ct_map {
target_url <regex> -- one or more targetURLs
ct_switch <source_ct, dest_ct> -- one or more CTs
}
EXAMPLE
ct_map {
target_url '^coap://class-1-device/.*$'
ct_switch */xml application/exi
}
]]></artwork></figure>
</section> <!-- End of "Content-Type Map Algorithm" -->
</section> <!-- End of "Internal Mapping Functions" -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:19:49 |