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