idnits 2.17.1 draft-castellani-core-advanced-http-mapping-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 14 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 870 has weird spacing: '... client clie...' == Line 1239 has weird spacing: '... */xml appl...' -- The document date (December 23, 2013) is 3776 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-core-block' is defined on line 1013, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-httpbis-p1-messaging' is defined on line 1036, but no explicit reference was found in the text == Unused Reference: 'I-D.bormann-core-simple-server-discovery' is defined on line 1074, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-core-resource-directory' is defined on line 1079, but no explicit reference was found in the text == Unused Reference: 'I-D.vanderstok-core-bc' is defined on line 1088, but no explicit reference was found in the text == Unused Reference: 'RFC3040' is defined on line 1093, but no explicit reference was found in the text == Unused Reference: 'RFC4732' is defined on line 1096, but no explicit reference was found in the text == Outdated reference: A later version (-21) exists of draft-ietf-core-block-12 == Outdated reference: A later version (-25) exists of draft-ietf-core-groupcomm-09 == Outdated reference: A later version (-17) exists of draft-ietf-core-http-mapping-00 == Outdated reference: A later version (-16) exists of draft-ietf-core-observe-08 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p1-messaging-22 == Outdated reference: A later version (-26) exists of draft-ietf-httpbis-p2-semantics-22 ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-00 Summary: 2 errors (**), 0 flaws (~~), 18 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group A. Castellani 3 Internet-Draft University of Padova 4 Intended status: Informational S. Loreto 5 Expires: June 26, 2014 Ericsson 6 A. Rahman 7 InterDigital Communications, LLC 8 T. Fossati 9 KoanLogic 10 E. Dijk 11 Philips Research 12 December 23, 2013 14 Guidelines for HTTP-CoAP Mapping Implementations 15 draft-castellani-core-advanced-http-mapping-03 17 Abstract 19 This draft describes advanced features for HTTP-CoAP proxy 20 implementors. It details deployment options, discusses possible 21 approaches for URI mapping, and provides useful considerations 22 related to protocol translation. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on June 26, 2014. 41 Copyright Notice 43 Copyright (c) 2013 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 3 59 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Use Case: HTTP/IPv4-CoAP/IPv6 Proxy . . . . . . . . . . . . . 3 61 4. Multiple Message Exchanges Mapping . . . . . . . . . . . . . 6 62 4.1. Relevant Features of Existing Standards . . . . . . . . . 6 63 4.1.1. Multipart Messages . . . . . . . . . . . . . . . . . 6 64 4.1.2. Immediate Message Delivery . . . . . . . . . . . . . 6 65 4.1.3. Detailing Source Information . . . . . . . . . . . . 7 66 4.2. Multicast Mapping . . . . . . . . . . . . . . . . . . . . 7 67 4.2.1. URI Identification and Mapping . . . . . . . . . . . 7 68 4.2.2. Request Handling . . . . . . . . . . . . . . . . . . 8 69 4.2.3. Examples . . . . . . . . . . . . . . . . . . . . . . 8 70 4.3. Multicast Response Caching . . . . . . . . . . . . . . . 10 71 4.4. Observe Mapping . . . . . . . . . . . . . . . . . . . . . 11 72 4.4.1. Identification . . . . . . . . . . . . . . . . . . . 11 73 4.4.2. Notification(s) Mapping . . . . . . . . . . . . . . . 13 74 4.4.3. Examples . . . . . . . . . . . . . . . . . . . . . . 14 75 5. HTML5 Scheme Handler Registration . . . . . . . . . . . . . . 20 76 6. Placement and Deployment . . . . . . . . . . . . . . . . . . 20 77 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 81 10.1. Cross-protocol Security Policy Mapping . . . . . . . . . 24 82 10.2. Subscription . . . . . . . . . . . . . . . . . . . . . . 24 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 85 11.2. Informative References . . . . . . . . . . . . . . . . . 25 86 Appendix A. Internal Mapping Functions (from an Implementer's 87 Perspective) . . . . . . . . . . . . . . . . . . . . 26 88 A.1. URL Map Algorithm . . . . . . . . . . . . . . . . . . . . 27 89 A.2. Security Policy Map Algorithm . . . . . . . . . . . . . . 28 90 A.3. Content-Type Map Algorithm . . . . . . . . . . . . . . . 29 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 93 1. Terminology and Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 This document assumes readers are familiar with the terms and 100 concepts that are used in [I-D.ietf-core-coap] . In addition, this 101 document defines the following terminology: 103 A device providing cross-protocol HTTP-CoAP mapping is called an 104 HTTP-CoAP cross-protocol proxy (HC proxy). 106 At least two different kinds of HC proxies exist: 108 o One-way cross-protocol proxy (1-way proxy): This proxy translates 109 from a client of a protocol to a server of another protocol but 110 not vice-versa. 112 o Two-way (or bidirectional) cross-protocol proxy (2-way proxy): 113 This proxy translates from a client of both protocols to a server 114 supporting one protocol. 116 2. Introduction 118 RESTful protocols, such as HTTP [RFC2616] and CoAP 119 [I-D.ietf-core-coap], can interoperate through an intermediary proxy 120 which performs cross-protocol mapping. 122 A base reference for the mapping process is provided in 123 [I-D.ietf-core-coap]. However, depending on the involved 124 application, deployment scenario, or network topology, such mapping 125 can be realized using a wide range of intermediaries. 127 Moreover, the process of implementing such a proxy can be complex, 128 and details regarding its internal procedures and design choices 129 deserve further discussion, which is provided in this document. 131 This draft itself is an evolution of the mapping features covered in 132 [I-D.ietf-core-http-mapping]. 134 3. Use Case: HTTP/IPv4-CoAP/IPv6 Proxy 136 This section covers the expected common use case regarding an HTTP/ 137 IPv4 client accessing a CoAP/IPv6 resource. 139 While HTTP and IPv4 are today widely adopted communication protocols 140 in the Internet, a pervasive deployment of constrained nodes 141 exploiting the IPv6 address space is expected: enabling direct 142 interoperability of such technologies is a valuable goal. 144 An HC proxy supporting IPv4/IPv6 mapping is said to be a v4/v6 proxy. 146 An HC v4/v6 proxy SHOULD always try to resolve the URI authority, and 147 SHOULD prefer using the IPv6 resolution if available. The authority 148 part of the URI is used internally by the HC proxy and SHOULD NOT be 149 mapped to CoAP. 151 Figure 1 shows an HTTP client on IPv4 (C) accessing a CoAP server on 152 IPv6 (S) through an HC proxy on IPv4/IPv6 (P). The DNS has an A 153 record for "node.coap.something.net" resolving to the IPv4 address of 154 the HC proxy, and an AAAA record with the IPv6 address of the CoAP 155 server. 157 C P S 158 | | | 159 | | | Source: IPv4 of C 160 | | | Destination: IPv4 of P 161 +---->| | GET /foo HTTP/1.1 162 | | | Host: node.coap.something.net 163 | | | ..other HTTP headers .. 164 | | | 165 | | | Source: IPv6 of P 166 | | | Destination: IPv6 of S 167 | +---->| CON GET 168 | | | URI-Path: foo 169 | | | 170 | | | Source: IPv6 of S 171 | | | Destination: IPv6 of P 172 | |<----+ ACK 173 | | | 174 | | | ... Time passes ... 175 | | | 176 | | | Source: IPv6 of S 177 | | | Destination: IPv6 of P 178 | |<----+ CON 2.00 179 | | | "bar" 180 | | | 181 | | | Source: IPv6 of P 182 | | | Destination: IPv6 of S 183 | +---->| ACK 184 | | | 185 | | | Source: IPv4 of P 186 | | | Destination: IPv4 of C 187 |<----+ | HTTP/1.1 200 OK 188 | | | .. other HTTP headers .. 189 | | | 190 | | | bar 191 | | | 193 Figure 1: HTTP/IPv4 to CoAP/IPv6 Mapping 195 The proposed example shows the HC proxy operating also the mapping 196 between IPv4 to IPv6 using the authority information available in any 197 HTTP 1.1 request. This way, IPv6 connectivity is not required at the 198 HTTP client when accessing a CoAP server over IPv6 only, which is a 199 typical expected use case. 201 When P is an interception HC proxy, the CoAP request SHOULD have the 202 IPv6 address of C as source (IPv4 can always be mapped into IPv6). 204 The described solution takes into account only the HTTP/IPv4 clients 205 accessing CoAP/IPv6 servers; this solution does not provide a full 206 fledged mapping from HTTP to CoAP. 208 In order to obtain a working deployment for HTTP/IPv6 clients, a 209 different HC proxy access method may be required, or Internet AAAA 210 records should not point to the node anymore (the HC proxy should use 211 a different DNS database pointing to the node). 213 When an HC interception proxy deployment is used this solution is 214 fully working even with HTTP/IPv6 clients. 216 4. Multiple Message Exchanges Mapping 218 This section discusses the mapping of the multicast and observe 219 features of CoAP, which have no corresponding primitive in HTTP, and 220 as such are not immediately translatable. 222 The mapping, which must be considered in both the arrow directions 223 (H->C, C->H) may involve multi-part responses, as in the multicast 224 use case, asynchronous delivery through HTTP bidirectional 225 techniques, and HTTP Web Linking in order to reduce the semantics 226 lost in the translation. 228 4.1. Relevant Features of Existing Standards 230 Various features provided by existing standards are useful to 231 efficiently represent sessions involving multiple messages. 233 4.1.1. Multipart Messages 235 In particular, the "multipart/*" media type, defined in Section 5.1 236 of [RFC2046], is a suitable solution to deliver multiple CoAP 237 responses within a single HTTP payload. Each part of a multipart 238 entity SHOULD be represented using "message/http" media type 239 containing the full mapping of a single CoAP response as previously 240 described. 242 4.1.2. Immediate Message Delivery 244 An HC proxy may prefer to transfer each CoAP response immediately 245 after its reception. This is possible thanks to the HTTP Transfer- 246 Encoding "chunked", that enables transferring single responses 247 without any further delay. 249 A detailed discussion on the use of chunked Transfer-Encoding to 250 stream data over HTTP can be found in [RFC6202]. Large delays 251 between chunks can lead the HTTP session to timeout, more details on 252 this issue can be found in [I-D.thomson-hybi-http-timeout]. 254 An HC proxy MAY prefer (e.g. to avoid buffering) to transfer each 255 response related to a multicast request as soon as it comes in from 256 the server. One possible way to achieve this result is using the 257 "chunked" Transfer-Encoding in the HTTP response, to push individual 258 responses until some trigger is fired (timeout, max number of 259 messages, etc.). 261 An example showing immediate delivery of CoAP responses using HTTP 262 chunks will be provided in Section 4.4, while describing its 263 application to an observe session. 265 4.1.3. Detailing Source Information 267 Under some circumstances, responses may come from different sources 268 (i.e. responses to a multicast request); in this case details about 269 the actual source of each CoAP response MAY be provided to the 270 client. Source information can be represented using HTTP Web Linking 271 as defined in [RFC5988], by adding the actual source URI into each 272 response using Link option with "via" relation type. 274 4.2. Multicast Mapping 276 In order to establish a multicast communication such a feature should 277 be offered either by the network (i.e. IP multicast, link-layer 278 multicast, etc.) or by a gateway (i.e. the HC proxy). Rationale on 279 the methods available to obtain such a feature is out-of-scope of 280 this document, and extensive discussion of group communication 281 techniques is available in [I-D.ietf-core-groupcomm]. 283 Additional considerations related to handling multicast requests 284 mapping are detailed in the following sections. 286 4.2.1. URI Identification and Mapping 288 In order to successfully handle a multicast request, the HC proxy 289 MUST successfully perform the following tasks on the URI: 291 Identification: The HC proxy MUST understand whether the requested 292 URI identifies a group of nodes. 294 Mapping: The HC proxy MUST know how to distribute the multicast 295 request to involved servers; this process is specific of the group 296 communication technology used. 298 When using IPv6 multicast paired with DNS, the mapping to IPv6 299 multicast is simply done using DNS resolution. If the group 300 management is performed at the proxy, the URI or part of it (i.e. the 301 authority) can be mapped using some static or dynamic table available 302 at the HC proxy. In Section 3.5 of [I-D.ietf-core-groupcomm] 303 discusses a method to build and maintain a local table of multicast 304 authorities. 306 4.2.2. Request Handling 308 When the HC proxy receives a request to a URI that has been 309 successfully identified and mapped to a group of nodes, it SHOULD 310 start a multicast proxying operation, if supported by the proxy. 312 Multicast request handling consists of the following steps: 314 Multicast TX: The HC proxy sends out the request on the CoAP side by 315 using the methods offered by the specific group communication 316 technology used in the constrained network; 318 Collecting RXs: The HC proxy collects every response related to the 319 request; 321 Timeout: The HC proxy has to pay special attention in multicast 322 timing, detailed discussion about timing depends upon the 323 particular group communication technology used; 325 Distributing RXs to the client: The HC proxy can distribute the 326 responses in two different ways: batch delivering them at the end 327 of the process or on timeout, or immediately delivering them as 328 they are available. Batch requires more caching and introduces 329 delays but may lead to lower TCP overhead and simpler processing. 330 Immediate delivery is the converse. A trade-off solution of 331 partial batch delivery may also be feasible and efficient in some 332 circumstances. 334 4.2.3. Examples 336 Figure 2 shows an HTTP client (C) requesting the resource "/foo" to a 337 group of CoAP servers (S1/S2/S3) through an HC proxy (P) which uses 338 IP multicast to send the corresponding CoAP request. 340 C P S1 S2 S3 341 | | | | | 342 +---->| | | | GET /foo HTTP/1.1 343 | | | | | Host: group-of-nodes.coap.something.net 344 | | | | | .. other HTTP headers .. 345 | | | | | 346 | +---->|---->|---->| NON GET 347 | | | | | URI-Path: foo 348 | | | | | 349 | |<----------+ | NON 2.00 350 | | | | | "S2" 351 | | | | | 352 | | X---------------+ NON 2.00 353 | | | | | "S3" 354 | | | | | 355 | |<----+ | | NON 2.00 356 | | | | | "S1" 357 | | | | | 358 | | | | | ... Timeout ... 359 | | | | | 360 |<----+ | | | HTTP/1.1 200 OK 361 | | | | | Content-Type: multipart/mixed; 362 | | | | | boundary="response" 363 | | | | | .. other HTTP headers .. 364 | | | | | 365 | | | | | --response 366 | | | | | Content-Type: message/http 367 | | | | | 368 | | | | | HTTP/1.1 200 OK 369 | | | | | Link: ; 370 | | | | | rel=via 371 | | | | | 372 | | | | | S2 373 | | | | | 374 | | | | | --response 375 | | | | | Content-Type: message/http 376 | | | | | 377 | | | | | HTTP/1.1 200 OK 378 | | | | | Link: ; 379 | | | | | rel=via 380 | | | | | 381 | | | | | S1 382 | | | | | 383 | | | | | --response-- 384 | | | | | 386 Figure 2: Unicast HTTP to Multicast CoAP Mapping 388 The example proposed in the above diagram does not make any 389 assumption on which underlying group communication technology is 390 available in the constrained network. Some detailed discussion is 391 provided about it along the following lines. 393 C makes a GET request to group-of-nodes.coap.something.net. This 394 domain name MAY either resolve to the address of P, or to the IPv6 395 multicast address of the nodes (if IP multicast is supported and P is 396 an interception proxy), or the proxy P is specifically known by the 397 client that sends this request to it. 399 To successfully start multicast proxying operation, the HC proxy MUST 400 know that the destination URI involves a group of CoAP servers, e.g. 401 the authority group-of-nodes.coap.something.net is known to identify 402 a group of nodes either by using an internal lookup table, using DNS 403 paired with IPv6 multicast, or by using some other special technique. 405 A specific implementation option is proposed to further explain the 406 proposed example. Assume that DNS is configured such that all 407 subdomain queries to coap.something.net, such as group-of- 408 nodes.coap.something.net, resolve to the address of P. P performs 409 the HC URI mapping by removing the 'coap' subdomain from the 410 authority and by switching the scheme from 'http' to 'coap' (result: 411 "coap://group-of-node.something.net/foo"); "group-of- 412 nodes.something.net" is resolved to an IPv6 multicast address to 413 which S1, S2 and S3 belong. The proxy handles this request as 414 multicast and sends the request "GET /foo" to the multicast group . 416 4.3. Multicast Response Caching 418 We call perfect caching when the proxy uses only the cached 419 representations to provide a response to the HTTP client. In the 420 case of a multicast CoAP request, perfect caching is not adequate. 421 This section updates the general caching and congestion control 422 guidelines of with specific guidelines for the multicast use case. 424 Due to the inherent unreliable nature of the NON messages involved 425 and since nodes may have dynamic membership in multicast groups, 426 responding only with previously cached responses without issuing a 427 new multicast request is not recommended. This perfect caching 428 behaviour leads to miss responses of nodes that later joined the 429 multicast group, and/or to repeatedly serve partial representations 430 due to message losses. Therefore a multicast CoAP request SHOULD be 431 sent by a HC proxy for each incoming request addressed to a multicast 432 group. 434 Caching of multicast responses is still a valuable goal to pursue 435 reduce network congestion, battery consumption and response latency. 437 Some considerations to be performed when adopting a multicast caching 438 behaviour are outlined in the following paragraph. 440 Caching of multicast GET responses MAY be implemented by adopting 441 some technique that takes into account either knowledge about dynamic 442 characteristics of group membership (occurrence or frequency of group 443 changes) or even better its full knowledge (list of nodes currently 444 part of the group). 446 When using a technique exploiting this knowledge, valid cached 447 responses SHOULD be served from cache. 449 4.4. Observe Mapping 451 By design, and certainly not without a good rationale, HTTP lacks a 452 publish-subscriber facility. This implies that the mapping of the 453 CoAP observe semantics has to be created ad hoc, perhaps by making 454 use of one of the well-known HTTP techniques currently employed to 455 establish an HTTP bidirectional connection with the target resource - 456 as documented in [RFC6202]. 458 In the following sections we will describe some of the approaches 459 that can be used to identify an observable resource and to create the 460 communication bridging needed to set up an end to end HTTP-CoAP 461 observation. 463 4.4.1. Identification 465 In order to appropriately process an observe request, the HC proxy 466 needs to know whether a given request is intended to establish an 467 observation on the target resource, instead of triggering a regular 468 request-response exchange. 470 At least two different approaches to identify such special requests 471 exist, as discussed below. 473 4.4.1.1. Observable URI Mapping 475 An URI is said to be observable whenever every request to it 476 implicitly requires the establishment of an HTTP bidirectional 477 connection to the resource. 479 Such subscription to the resource is always paired, if possible, to a 480 CoAP observe session to the actual resource being observed. In 481 general, multiple connections that are active with a single 482 observable resource at the same time, are multiplexed to the single 483 observe session opened by the intermediary. Its notifications are 484 then de-multiplexed by the HC proxy to every HTTP subscriber. 486 An intermediary MAY pair a couple of distinct HTTP URIs to a single 487 CoAP observable resource: one providing the usual request-response 488 mediated access to the resource, and the other that always triggers a 489 CoAP observe session. 491 4.4.1.1.1. Discovery 493 As shown in Figure 3, in order to know whether an URI is observable, 494 an HTTP UA MAY do a pre-flight request to the target resource using 495 the HTTP OPTIONS method (see section 6.2 of 496 [I-D.ietf-httpbis-p2-semantics]) to discover the communication 497 options available for that resource. 499 If the resource supports observation, the proxy adds a Link Header 500 [RFC5988] with the "obs" attribute as link-param (see Section 7 of 501 [I-D.ietf-core-observe]). 503 C P S 504 | | | OPTIONS /kitchen/temp HTTP/1.1 505 +------>| | Host: node.coap.something.net 506 | | | 507 | +------>| CON GET 508 | | | Uri-Path: /.well-known/core?anchor=/kitchen/temp 509 | | | 510 | |<------+ ACK 2.05 511 | | | Payload: ;obs 512 | | | 513 |<------+ | HTTP/1.1 200 OK 514 | | | Link: ; obs; 515 | | | type="application/atom+xml" 516 | | | Allow: GET, OPTIONS 518 Figure 3: Discover Observability with HTTP OPTIONS 520 4.4.1.2. Differentiation Using HTTP Header 522 Discerning an observation request through in-protocol means, e.g. via 523 the presence and values of some HTTP metadata, avoids introducing 524 static "observable" URIs in the HC proxy namespace. Though ideally 525 the former should be preferred, there seems to be no standard way to 526 use one of the established HTTP headers to convey the observe 527 semantics. 529 Standardizing such methods is out-of-scope of this document, so we 530 just point out some possible approaches that in the future may be 531 used to differentiate observation requests from regular requests. 533 4.4.1.2.1. Expect Header 535 The first method involves the use of the Expect header as defined in 536 Section 9.3 of [I-D.ietf-httpbis-p2-semantics]. Whenever an HC proxy 537 receives a request with a "206-partial-content" expectation, the 538 proxy MUST fulfill this expectation by pairing this request to either 539 a new or existing observe session to the resource. 541 If the proxy is unable to observe the resource, or if the observation 542 establishment fails, the proxy MUST reply to the client with "417 543 Expectation Failed" status code. 545 Given that the Expect header is processed hop-by-hop, this method 546 will fail immediately in case a proxy not supporting this expectation 547 is traversed. For this reason, at present, the said approach can't 548 be used in the public Internet. 550 4.4.1.2.2. Prefer Header 552 A second, very similar, approach involves the use of the Prefer 553 header, defined in [I-D.snell-http-prefer]. The HTTP user agent 554 expresses the preference to establish an observation with the target 555 resource by including a "streaming" preference to request an HTTP 556 Streaming session, or a "long-polling" preference to signal to the 557 proxy its intended polling behaviour (see [RFC6202]). 559 A compliant HC proxy will try to fulfill the preference, and manifest 560 observation establishment success by responding with a status code of 561 "206 Partial Content". The observation request fails, falling back 562 to a single response, whenever the status code is different from 206. 564 This approach will never fail immediately, differently from the 565 previous one, even across a chain of unaware proxies; however, as 566 documented in [RFC6202], caching intermediaries may interfere, delay 567 or block the HTTP bidirectional connection, making this approach 568 unacceptable when no weak consistency of the resource can be 569 tolerated by the requesting UA. 571 4.4.2. Notification(s) Mapping 573 Multiplexing notifications using a single HTTP bidirectional session 574 needs some further considerations about the selection of the media 575 type that best fits this specific use case. 577 The usage of two different content-types that are suitable for 578 carrying multiple notifications in a single session, is discussed in 579 the following sections. 581 4.4.2.1. Multipart Messaging 583 As already discussed in Section 4.1.1 for multicasting, the 584 "multipart/*" media type is a suitable solution to deliver multiple 585 CoAP notifications within a single HTTP payload. 587 As in the multicast case, each part of the multipart entity MAY be 588 represented using a "message/http" media type, containing the full 589 mapping of the single CoAP notification mapped, so that CoAP envelope 590 information are preserved (e.g. the response code). 592 A more sophisticated mapping could use multipart/mixed with native or 593 translated media type. 595 4.4.2.2. Using ATOM Feeds 597 Popular observable resources with refresh rates higher than a couple 598 of seconds may be treated as Atom feeds [RFC4287], especially with 599 delay tolerant user agents and where persistence is required. 601 Figure 3 shows a resource supporting 'application/atom+xml' media- 602 type. In such case clients can listen to update notification by 603 regularly polling the resource via opportunely spaced GETs, i.e. 604 driven by the advertised max-age value. 606 4.4.3. Examples 608 Figure 4 shows the interaction between an HTTP client (C), an HC 609 proxy (P), and a CoAP server (S) for the observation of the resource 610 "temperature" (T) available on S. 612 C manifests its intention to observe T by including the Expect Header 613 in the request; if P or S do not support this interaction, the 614 request MUST fail with "417 Expectation Failed" return code. In the 615 presented example, both P and C support this interaction, and the 616 subscription is successful, as stated by the "206 Partial Content" 617 return code. 619 At every notification corresponds the emission of a HTTP chunk 620 containing a single part, which contains a "message/http" payload 621 containing the full mapping of the notification. When the 622 observation is dropped by the CoAP server, the HTTP streaming session 623 is closed. 625 C P S 626 | | | 627 +---->| | GET /temperature HTTP/1.1 628 | | | Host: node.coap.something.net 629 | | | Expect: 206-partial-content 630 | | | Accept: multipart/mixed 631 | | | 632 | +---->| CON GET 633 | | | Uri-Path: temperature 634 | | | Observe: 0 635 | | | 636 | |<----+ ACK 2.05 637 | | | Observe: 3482 638 | | | "22.1 C" 639 | | | 640 |<----+ | HTTP/1.1 206 Partial Content 641 | | | Content-Type: multipart/mixed; boundary=notification 642 | | | 643 | | | XX 644 | | | --notification 645 | | | Content-Type: message/http 646 | | | 647 | | | HTTP/1.1 200 OK 648 | | | 649 | | | 22.1 C 650 | | | 651 | | | ... about 60 seconds have passed ... 652 | | | 653 | |<----+ NON 2.05 654 | | | Observe: 3542 655 | | | "21.6 C" 656 | | | 657 |<----+ | YY 658 | | | --notification 659 | | | Content-Type: message/http 660 | | | 661 | | | HTTP/1.1 200 OK 662 | | | 663 | | | 21.6 C 664 | | | 665 | | | ... if the server drops the relationship ... 666 | | | 667 | |<----+ NON 2.05 668 | | | "21.8 C" 669 | | | 670 |<----+ | ZZ 671 | | | --notification 672 | | | Content-Type: message/http 673 | | | 674 | | | HTTP/1.1 200 OK 675 | | | 676 | | | 21.8 C 677 | | | 678 | | | --notification-- 679 | | | 680 | | | 0 682 Figure 4: HTTP Streaming to CoAP Observe 684 Figure 5 shows the interaction between an HTTP client (C), an HC 685 proxy (P), and a CoAP server (S) for the observation of the resource 686 "temperature" (T) available on S. 688 C manifests its intention to observe T by including the Prefer Header 689 in the request; if P or S do not support this interaction, the 690 request silently fails if a status code "200 OK" is returned, which 691 means that no further notification is expected on that session. 693 In the presented example, both P and C support this interaction, and 694 the subscription is successful, as stated by the "206 Partial 695 Content" status code. At every notification a new response is sent 696 to the pending client, always containing the "206 Partial Content" 697 status code, to indicate that the observe session is still active, so 698 that C can issue a new long-polling request immediately after this 699 notification. 701 If the observation relationship is dropped by S, P notifies the last 702 received content using the "200 OK" status code, indicating that no 703 further notification is expected on this observe session. 705 C P S 706 | | | 707 +---->| | GET /temperature HTTP/1.1 708 | | | Host: node.coap.something.net 709 | | | Prefer: long-polling 710 | | | 711 | +---->| CON GET 712 | | | Uri-Path: temperature 713 | | | Observe: 0 714 | | | 715 | |<----+ ACK 2.05 716 | | | Observe: 3482 717 | | | "22.1 C" 718 | | | 719 |<----+ | HTTP/1.1 206 Partial Content 720 | | | 721 | | | 22.1 C 722 | | | 723 +---->| | GET /temperature HTTP/1.1 724 | | | Host: node.coap.something.net 725 | | | Prefer: long-polling 726 | | | 727 | | | ... about 60 seconds have passed ... 728 | | | 729 | |<----+ NON 2.05 730 | | | Observe: 3542 731 | | | "21.6 C" 732 | | | 733 |<----+ | HTTP/1.1 206 Partial Content 734 | | | 735 | | | 21.6 C 736 | | | 737 +---->| | GET /temperature HTTP/1.1 738 | | | Host: node.coap.something.net 739 | | | Prefer: long-polling 740 | | | 741 | | | ... if the server drops the relationship ... 742 | | | 743 | |<----+ NON 2.05 744 | | | "21.8 C" 745 | | | 746 |<----+ | HTTP/1.1 200 OK 747 | | | 748 | | | 21.8 C 750 Figure 5: HTTP Long Polling to CoAP Observe 752 Figure 6 shows the interaction between an HTTP client (C), an HC 753 proxy (P), and a CoAP server (S) for the observation of the resource 754 "kitchen/temp" (T) available on S. 756 It is assumed that the HC proxy knows that the requested resource is 757 observable (since perhaps being asked beforehand to discover its 758 properties as described in Figure 3.) When asked by the HTTP client 759 to retrieve the resource, it requests an observation - in case it 760 weren't already in place - and then sends the collected data to the 761 client as an Atom feed. The data coming through in the constrained 762 network is stored locally on the proxy, and forwarded when further 763 requests are received on the HTTP side. As already said, using the 764 Atom format has two main advantages: first, there is always a 765 "current" feed, but there may also be a complete log made available 766 to HTTP clients; secondly, the HTTP intermediaries can play a 767 substantial role in absorbing a fair amount of the load on the HC 768 proxy. The latter is a very important property when the requested 769 resource is or becomes very popular. 771 C P S 772 | | | GET /kitchen/temp HTTP/1.1 773 +------>| | Host: node.coap.something.net 774 | | | 775 | +------>| CON GET 776 | | | Uri-Path: kitchen/temp 777 | | | Observe: 0 778 | | | 779 | |<------+ ACK 2.05 780 | | | Observe: 1000 781 | | | Max-Age: 10 782 | | | "22.3 C" 783 | | | 784 |<------+ | HTTP/1.1 200 OK 785 | | | Cache-Control: max-age=10 786 | | | ETag: "0x5555" 787 | | | Content-Type: application/atom+xml 788 | | | 789 | | | 790 | | | 791 | | | urn:uuid: 792 | | | bf08203a-fbbf-49e8-bf11-3c4cff708525 793 | | | 2012-03-07T11:14:30 794 | | | 795 | | | 22.3 C 796 | | | 797 | | | 798 | | | 799 | | | 800 | | | 801 | |<------+ NON 2.05 802 | | | Observe: 1010 803 | | | Max-Age: 10 804 | | | "22.4 C" 805 | | | 806 +------>| | GET /kitchen/temp HTTP/1.1 807 | | | Host: node.coap.something.net 808 | | | 809 | | | [...] 810 | | | 812 Figure 6: Observation via Atom feeds 814 5. HTML5 Scheme Handler Registration 816 The draft HTML5 standard offers a mechanism that allows an HTTP user 817 agent to register a custom scheme handler through an HTML5 web page. 818 This feature permits to an HC proxy to be registered as "handler" for 819 URIs with the 'web+coap' or 'web+coaps' schemes using an HTML5 web 820 page which embeds the custom scheme handler registration call 821 registerProtocolHandler() described in Section 6.5.1.2 of 822 [W3C.HTML5]. 824 Example: the HTML5 homepage of a HC proxy at h2c.example.org could 825 include the method call: 827 registerProtocolHandler('web+coap','proxy?url=%s','example HC proxy') 829 This registration call will prompt the HTTP user agent to ask for the 830 user's permission to register the HC proxy as a handler for all 831 'web+coap' URIs. If the user accepts, whenever a 'web+coap' link is 832 requested, the request will be fulfilled through the HC proxy: URI 833 "web+coap://foo.org/a" will be transformed into URI "http:// 834 h2c.example.org/proxy?url=web+coap://foo.org/a". 836 6. Placement and Deployment 838 In typical scenarios, for communication from a CoAP client to an HTTP 839 origin server, the HC proxy is expected to be located on the client- 840 side (CS). Specifically, the HC proxy is expected to be deployed at 841 the edge of the constrained network as shown in Figure 7. 843 The arguments supporting CS placement are as follows: 845 Client/Proxy/Network configuration overhead: CoAP clients require 846 either static proxy configuration or proxy discovery support. 847 This overhead is simplified if the proxy is placed on the same 848 network domain of the client. 850 TCP/UDP: Translation between CoAP and HTTP requires also UDP to TCP 851 mapping; UDP performance over the unconstrained Internet may not 852 be adequate. In order to minimize the number of required 853 retransmissions on the constrained part of the network and the 854 overall reliability, TCP/UDP conversion SHOULD be performed as 855 soon as possible in the network path. 857 Caching: Efficient caching requires that all the CoAP traffic is 858 intercepted by the same proxy, thus a CS placement, collecting all 859 the traffic, is strategic for this need. 861 +------+ 862 | | 863 | DNS | 864 | | 865 +------+ 866 -------------------- 867 // \\ 868 / /-----\ /---\ \ 869 / CoAP CoAP \ 870 || client client || 871 +----------+ \-----/ \-----/ || 872 | HTTP/CoAP| /-----\ || 873 | Proxy | CoAP || 874 |(HC Proxy)| client || 875 +------+ +----------+ \-----/ || 876 |HTTP | || /-----\ || 877 |Origin| || CoAP || 878 |Server| \ client /-----\ / 879 +------+ \ \-----/ CoAP / 880 \ client / 881 \\ \-----/ // 882 ------------------ 884 Figure 7: Client-side HC Proxy Deployment Scenario 886 7. Examples 888 Figure 8 shows an example implementation of a basic CoAP GET request 889 with an HTTP URI as the value of a Proxy-URI option. The proxy 890 retrieves a representation of the target resource from the HTTP 891 origin server. It converts the payload to a UTF-8 charset, 892 calculates the Max-Age Option from the Expires header field, and 893 derives an entity-tag from the ETag header field. 895 C P S 896 | | | 897 +---------->| | CoAP Header: GET (T=CON, Code=1, MID=0x1633) 898 | CoAP | | Token: 0x5a 899 | Get | | Proxy-URI: http://www.example.com/foo/bar 900 | | | 901 | | | 902 | +---------->| HTTP/1.1 GET /foo/bar 903 | | HTTP | Host: www.example.com 904 | | GET | 905 | | | 906 | | | 907 |<----------+ | CoAP Header: (T=ACK, Code=0, MID=0x1633) 908 | | | 909 | | | 910 | |<----------+ HTTP/1.1 200 OK 911 | | HTTP | Date: Friday, 14 Oct 2011 15:00:00 GMT 912 | | 200 OK | Content-Type: text/plain; charset=iso-8859-1 913 | | | Content-Length: 11 914 | | | Expires: Friday, 14 Oct 2011 16:00:00 GMT 915 | | | ETag: "xyzzy" 916 | | | Connection: close 917 | | | 918 | | | Hello World 919 | | | 920 | | | 921 |<----------+ | CoAP Header: 2.00 OK 922 | | | (T=CON, Code=64, MID=0xAAFO) 923 | CoAP | | Token: 0x5a 924 | 2.00 OK | | C-Type: text/plain; charset=utf-8 925 | | | Max-Age: 3600 926 | | | ETag: 0x78797A7A79 927 | | | Payload: "Hello World" 928 | | | 929 +---------->| | CoAP Header: (T=ACK, Code=0, MID=0xAAF0) 931 Figure 8: A Basic CoAP-HTTP GET Request 933 The example in Figure 9 builds on the previous example and shows an 934 implementation of a GET request that includes a previously returned 935 ETag Option. The proxy makes a Conditional Request to the HTTP 936 origin server by including an If-None-Match header field in the HTTP 937 GET Request. The CoAP response indicates that the response stored by 938 the client is fresh. It includes a Max-Age Option calculated from 939 the HTTP response's Expires header field. 941 C P S 942 | | | 943 +---------->| | CoAP Header: GET (T=CON, Code=1, MID=0x1CBO) 944 | CoAP | | Token: 0x7b 945 | Get | | Proxy-URI: http://www.example.com/foo/bar 946 | | | ETag: 0x78797A7A79 947 | | | 948 | | | 949 | +---------->| HTTP/1.1 GET /foo/bar 950 | | HTTP | Host: www.example.com 951 | | GET | If-None-Match: "xyzzy" 952 | | | 953 | | | 954 |<----------+ | CoAP Header: (T=ACK, Code=0, MID=0x1CBO) 955 | | | 956 | | | 957 | |<----------+ HTTP/1.1 304 Not Modified 958 | | HTTP | Date: Friday, 14 Oct 2011 17:00:00 GMT 959 | | 304 | Expires: Friday, 14 Oct 2011 18:00:00 GMT 960 | | | ETag: "xyzzy" 961 | | | Connection: close 962 | | | 963 | | | 964 |<----------+ | CoAP Header: 2.03 Valid 965 | | | (T=CON, Code=67, MID=0xAAFF) 966 | CoAP | | Token: 0x7b 967 | 2.03 | | Max-Age: 3600 968 | | | ETag: 0x78797A7A79 969 | | | 970 | | | 971 +---------->| | CoAP Header: (T=ACK, Code=0, MID=0xAAFF) 973 Figure 9: A CoAP-HTTP GET Request with an ETag Option 975 8. Acknowledgements 977 TBD. 979 9. IANA Considerations 981 This memo includes no request to IANA. 983 10. Security Considerations 984 10.1. Cross-protocol Security Policy Mapping 986 At the moment of this writing, CoAP and HTTP are missing any cross- 987 protocol security policy mapping. 989 The HC proxy SHOULD flexibly support security policies between the 990 two protocols, possibly as part of the HC URI mapping function, in 991 order to statically map HTTP and CoAP security policies at the proxy 992 (see Appendix A.2 for an example.) 994 10.2. Subscription 996 As noted in Section 7 of [I-D.ietf-core-observe], when using the 997 observe pattern, an attacker could easily impose resource exhaustion 998 on a naive server who's indiscriminately accepting observer 999 relationships establishment from clients. The converse of this 1000 problem is also present, a malicious client may also target the HC 1001 proxy itself, by trying to exhaust the HTTP connection limit of the 1002 proxy by opening multiple subscriptions to some CoAP resource. 1004 Effective strategies to reduce success of such a DoS on the HTTP side 1005 (by forcing prior identification of the HTTP client via usual web 1006 authentication mechanisms), must always be weighted against an 1007 acceptable level of usability of the exposed CoAP resources. 1009 11. References 1011 11.1. Normative References 1013 [I-D.ietf-core-block] 1014 Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", 1015 draft-ietf-core-block-12 (work in progress), June 2013. 1017 [I-D.ietf-core-coap] 1018 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 1019 Application Protocol (CoAP)", draft-ietf-core-coap-18 1020 (work in progress), June 2013. 1022 [I-D.ietf-core-groupcomm] 1023 Rahman, A. and E. Dijk, "Group Communication for CoAP", 1024 draft-ietf-core-groupcomm-09 (work in progress), May 2013. 1026 [I-D.ietf-core-http-mapping] 1027 Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 1028 E. Dijk, "Best Practices for HTTP-CoAP Mapping 1029 Implementation", draft-ietf-core-http-mapping-00 (work in 1030 progress), June 2013. 1032 [I-D.ietf-core-observe] 1033 Hartke, K., "Observing Resources in CoAP", draft-ietf- 1034 core-observe-08 (work in progress), February 2013. 1036 [I-D.ietf-httpbis-p1-messaging] 1037 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1038 (HTTP/1.1): Message Syntax and Routing", draft-ietf- 1039 httpbis-p1-messaging-22 (work in progress), February 2013. 1041 [I-D.ietf-httpbis-p2-semantics] 1042 Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 1043 (HTTP/1.1): Semantics and Content", draft-ietf- 1044 httpbis-p2-semantics-22 (work in progress), February 2013. 1046 [I-D.thomson-hybi-http-timeout] 1047 Thomson, M., Loreto, S., and G. Wilkins, "Hypertext 1048 Transfer Protocol (HTTP) Keep-Alive Header", draft- 1049 thomson-hybi-http-timeout-03 (work in progress), July 1050 2012. 1052 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 1053 Extensions (MIME) Part Two: Media Types", RFC 2046, 1054 November 1996. 1056 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1057 Requirement Levels", BCP 14, RFC 2119, March 1997. 1059 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1060 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1061 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1063 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1064 Resource Identifier (URI): Generic Syntax", STD 66, RFC 1065 3986, January 2005. 1067 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 1068 Syndication Format", RFC 4287, December 2005. 1070 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 1072 11.2. Informative References 1074 [I-D.bormann-core-simple-server-discovery] 1075 Bormann, C., "CoRE Simple Server Discovery", draft- 1076 bormann-core-simple-server-discovery-01 (work in 1077 progress), March 2012. 1079 [I-D.ietf-core-resource-directory] 1080 Shelby, Z., Krco, S., and C. Bormann, "CoRE Resource 1081 Directory", draft-ietf-core-resource-directory-00 (work in 1082 progress), June 2013. 1084 [I-D.snell-http-prefer] 1085 Snell, J., "Prefer Header for HTTP", draft-snell-http- 1086 prefer-18 (work in progress), January 2013. 1088 [I-D.vanderstok-core-bc] 1089 Stok, P. and K. Lynn, "CoAP Utilization for Building 1090 Control", draft-vanderstok-core-bc-05 (work in progress), 1091 October 2011. 1093 [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web 1094 Replication and Caching Taxonomy", RFC 3040, January 2001. 1096 [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- 1097 Service Considerations", RFC 4732, December 2006. 1099 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 1100 "Known Issues and Best Practices for the Use of Long 1101 Polling and Streaming in Bidirectional HTTP", RFC 6202, 1102 April 2011. 1104 [W3C.HTML5] 1105 Hickson, I., "HTML5", World Wide Web Consortium WD (work 1106 in progress) WD-html5-20111018, October 2011, 1107 . 1109 Appendix A. Internal Mapping Functions (from an Implementer's 1110 Perspective) 1112 At least three mapping functions have been identified, which take 1113 place at different stages of the HC proxy processing chain, involving 1114 the URL, Content-Type and Security Policy translation. 1116 All these maps are required to have at least URL granularity so that, 1117 in principle, each and every requested URL may be treated as an 1118 independent mapping source. 1120 In the following, the said map functions are characterized via their 1121 expected input and output, and a simple, yet sufficiently rich, 1122 configuration syntax is suggested. 1124 In the spirit of a document providing implementation guidance, the 1125 specification of a map grammar aims at putting the basis for a 1126 reusable software component (e.g. a stand-alone C library) that many 1127 different proxy implementations can link to, and benefit from. 1129 A.1. URL Map Algorithm 1131 In case the HC proxy is a reverse proxy, i.e. it acts as the origin 1132 server in face of the served network, the URL of the resource 1133 requested by its clients (perhaps having an 'http' scheme) shall be 1134 mapped to the real resource origin (perhaps in the 'coap' scheme). 1136 In case HC is a forward proxy, no URL translation is needed since the 1137 client already knows the "real name" of the resource. 1139 An interception HC proxy, instead, MAY use the homogeneous mapping 1140 strategy to operate without any pre-configuration need. 1142 As noted in Appendix B of [RFC3986] any correctly formatted URL can 1143 be matched by a POSIX regular expression. By leveraging on this 1144 property, we suggest a syntax that describes the URL mapping in terms 1145 of substituting the regex-matching portions of the requested URL into 1146 the mapped URL template. 1148 E.g.: given the source regular expression '^http://example.com/coap/ 1149 .*$' and destination template 'coap://$1' (where $1 stands for the 1150 first - and only in this specific case - substring matched by the 1151 regex pattern in the source), the input URL "http://example.com/coap/ 1152 node1/resource2" translates to "coap://node1/resource2". 1154 This is a well established technique used in many todays web 1155 components (e.g. Django URL dispatcher, Apache mod_rewrite, etc.), 1156 which provides a compact and powerful engine to implement what 1157 essentially is an URL rewrite function. 1159 INPUT 1160 * requested URL 1162 OUTPUT 1163 * target URL 1165 SYNTAX 1166 url_map [rule name] { 1167 requested_url 1168 mapped_url 1169 } 1171 EXAMPLE 1 1172 url_map homogeneous { 1173 requested_url '^http://.*$' 1174 mapped_url 'coap//$1' 1175 } 1177 EXAMPLE 2 1178 url_map embedded { 1179 requested_url '^http://example.com/coap/.*$' 1180 mapped_url 'coap//$1' 1181 } 1183 Note that many different url_map records may be given in order to 1184 build the whole mapping function. Each of these records can be 1185 queried (in some predefined order) by the HC proxy until a match is 1186 found, or the list is exhausted. In the latter case, depending on 1187 the mapping policy (only internal, internal then external, etc.) the 1188 original request can be refused, or the same mapping query is 1189 forwarded to one or more external URL mapping components. 1191 A.2. Security Policy Map Algorithm 1193 In case the "incoming" URL has been successfully translated, the HC 1194 proxy must lookup the security policy, if any, that needs to be 1195 applied to the request/response transaction carried on the "outgoing" 1196 leg. 1198 INPUT 1199 * target URL (after URL map has been applied) 1200 * original requester identity (given by cookie, or IP address, or 1201 crypto credentials/security context, etc.) 1203 OUTPUT 1204 * security context that will be applied to access the target URL 1206 SYNTAX 1207 sec_map [rule name] { 1208 target_url -- one or more 1209 requester_id 1210 sec_context 1211 } 1213 EXAMPLE 1214 1216 A.3. Content-Type Map Algorithm 1218 In case a set of destination URLs is known as being limited in 1219 handling a narrow subset of mime types, a content-type map can be 1220 configured in order to let the HC proxy transparently handle the 1221 compatible/lossless format translation. 1223 INPUT 1224 * destination URL (after URL map has been applied) 1225 * original content-type 1227 OUTPUT 1228 * mapped content-type 1230 SYNTAX 1231 ct_map { 1232 target_url -- one or more targetURLs 1233 ct_switch -- one or more CTs 1234 } 1236 EXAMPLE 1237 ct_map { 1238 target_url '^coap://class-1-device/.*$' 1239 ct_switch */xml application/exi 1240 } 1242 Authors' Addresses 1244 Angelo P. Castellani 1245 University of Padova 1246 Via Gradenigo 6/B 1247 Padova 35131 1248 Italy 1250 Email: angelo@castellani.net 1252 Salvatore Loreto 1253 Ericsson 1254 Hirsalantie 11 1255 Jorvas 02420 1256 Finland 1258 Email: salvatore.loreto@ericsson.com 1260 Akbar Rahman 1261 InterDigital Communications, LLC 1262 1000 Sherbrooke Street West 1263 Montreal H3A 3G4 1264 Canada 1266 Phone: +1 514 585 0761 1267 Email: Akbar.Rahman@InterDigital.com 1269 Thomas Fossati 1270 KoanLogic 1271 Via di Sabbiuno 11/5 1272 Bologna 40136 1273 Italy 1275 Phone: +39 051 644 82 68 1276 Email: tho@koanlogic.com 1278 Esko Dijk 1279 Philips Research 1281 Email: esko.dijk@philips.com