CORE Working Group A. Castellani Internet-Draft University of Padova Intended status: Informational S. Loreto Expires: July 29, 2011 Ericsson January 25, 2011 Best Practice to map HTTP to COAP and viceversa draft-castellani-core-http-coap-mapping-00.txt Abstract This draft aims at being a simple guide to the use of CoAP REST interface, to show how it can be mapped to and from HTTP, and at being a base reference documentation for CoAP/HTTP proxy implementors. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on July 29, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Castellani & Loreto Expires July 29, 2011 [Page 1] Internet-Draft Map HTTP to COAP January 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. CoAP/HTTP best practice . . . . . . . . . . . . . . . . . . . 4 2.1. Methods and Status . . . . . . . . . . . . . . . . . . . . 4 2.2. Headers and Content . . . . . . . . . . . . . . . . . . . 5 3. CoAP observe to HTTP options . . . . . . . . . . . . . . . . . 5 3.1. HTTP subscription to a CoAP resource . . . . . . . . . . . 6 3.1.1. Subscription parameters mapping . . . . . . . . . . . 6 3.1.2. Soft state requirements . . . . . . . . . . . . . . . 8 3.1.3. HTTP long-polling to CoAP observe . . . . . . . . . . 8 3.1.4. HTTP streaming to CoAP observe . . . . . . . . . . . . 10 3.2. CoAP observing an HTTP resource . . . . . . . . . . . . . 11 3.3. Open questions . . . . . . . . . . . . . . . . . . . . . . 13 4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Resource Discovery . . . . . . . . . . . . . . . . . . . . . . 14 5.1. CoRE resource discovery by an HTTP Client . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 Appendix A. Alternatives for CoAP subscription/notification(s) . 17 A.1. Server-to-server notifications . . . . . . . . . . . . . . 17 A.2. Observe using native Transfer-Encoding chunked . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Castellani & Loreto Expires July 29, 2011 [Page 2] Internet-Draft Map HTTP to COAP January 2011 1. Introduction Since implementing on constrained devices the full HyperText Transfer Protocol (HTTP) [RFC2616] is believed to be operationally and computationally too complex, especially in an M2M communication environment, resources available on constrained nodes are expected to be served using CoAP [I-D.ietf-core-coap]. These days on the web, we observe that information is increasingly converging to HTTP, thus a paramount feature of CoAP will be HTTP interoperability. A convenient choice to operate this mapping is by simply using an HTTP/CoAP proxy. The HTTP clients can transparently get access to this network through the proxy. The proxy itself does not require any particular knowledge about the constrained network topology, devices contained, nor about the content of data exchanged. The mapping operated by the proxy spans across several protocol layers: o HTTP is mapped to CoAP o TCP is used on the HTTP side, while CoAP uses UDP transport o IPv4/IPv6 are converted to 6LoWPAN in this document we will focus on the HTTP to CoAP mapping, assuming the aforementioned lower layer protocol conversions. The HTTP/CoAP proxy is expected to be deployed at the edge of the constrained network. The arguments supporting this assumption are the following: o Translation between HTTP and CoAP requires also a TCP to UDP mapping; UDP performance over the Internet may not be adequate, UDP should be dropped as soon as possible to minimize the number of required retransmissions and overall reliability. o Efficient caching requires that all the CoAP traffic is intercepted by the same proxy, network edge is a strategical placement for this need. o To enable access to local-multicast in the constrained network, the HTTP/CoAP proxy may require a network interface directly attached to the constrained network. The following sections outline the possible issues of the HTTP/CoAP mapping in many typical use cases: o Section 2 focuses on providing insight on the practice to map CoAP to HTTP; Castellani & Loreto Expires July 29, 2011 [Page 3] Internet-Draft Map HTTP to COAP January 2011 o Section 3 outlines the options available to map CoAP observe to the well-known HTTP bidirectional methods; o Section 4 describes how to map a CoAP multicast reques; o Section 5 outlines the mapping of CoAP link format; o Appendix A proposes two alternative mappings for observe, that however require modifications to the current observe functionality. 2. CoAP/HTTP best practice Mapping of CoAP to HTTP as described in Section 7 of [I-D.ietf-core-coap], is a straightforward conversion of features present in both protocols. Transaction layer messages without application layer content are transparent to HTTP, thus the proxy MUST not map them to HTTP. Every request served by the proxy, from HTTP to CoAP and viceversa, requires the proxy to keep a state, in order to map the TCP connection on the HTTP side to the Transaction ID on the CoAP side. The proxy COULD support HTTP clients using persistent TCP connections, always updating the TID of every new CoAP transaction in the state related to the HTTP connection. 2.1. Methods and Status HTTP methods supported by CoAP (Table 1 in [I-D.ietf-core-coap]) are mapped directly. Every other HTTP method (e.g. HEAD etc.) not supported, will cause the proxy to drop the request and generate a response with status "405 Method Not Allowed" to the HTTP client. Because CoAP supports a subset of HTTP methods, mapping from CoAP to HTTP is direct. Even if OPTIONS method is not defined in CoAP [I-D.ietf-core-coap], an HTTP OPTIONS request MAY be translated as a CoAP GET to the "/.well-known/core" URI. Status codes supported by CoAP are listed in Table 3 of [I-D.ietf-core-coap]. If an HTTP response carries a status not supported by CoAP, the proxy should map the response using CoAP "502 Bad Gateway". Viceversa if the response issued by a CoAP server contains a status code not supported by HTTP, the proxy should issue an HTTP response with status "502 Bad Gateway". Castellani & Loreto Expires July 29, 2011 [Page 4] Internet-Draft Map HTTP to COAP January 2011 2.2. Headers and Content HTTP traffic, as can be seen circulating in the traditional Internet, SHOULD not enter the constrained network if it is not light enough to fit this particular environment. Given the constrained nature of the environment, the content size of the exchange is expected to be low; higher attention should be paid to the well-known detail richness of the HTTP headers. Even if the high level of detail carried by HTTP headers is an advantage to better describe the REQ/RES exchange, in our special environment this is not feasible and should be avoided. CoAP Headers are a minimal subset of HTTP Headers (see Section 3.2 in [I-D.ietf-core-coap]), HTTP messages MUST be mapped dropping all headers not supported by CoAP (e.g. User-Agent, Accept, Cookie, etc). When a request to be properly served requires a feature not offered by CoAP, that request can be dropped by the proxy sending a "505 HTTP Version Not Supported" error message to the HTTP client. In contrast to this, when a message is to be mapped from CoAP to HTTP, the proxy should describe the HTTP message with the highest possible richness of details present in the CoAP message. The mapping of URI requires special processing to split URI-Path part from the URI-Query part. CoAP URI-Authority header MUST be mapped to Host HTTP header. When a CoAP message is lacking the URI-Authority Header, it MUST be translated to HTTP/1.0 [RFC1945] because it is lacking the information to complete the required Host HTTP Header; alternatively can be evaluated the use of a reverse DNS lookup at the proxy to complete the Host header. 3. CoAP observe to HTTP options HyperText Transfer Protocol [RFC2616] is a request/response protocol, where every request MUST be initiated by a client and can generate only a single response. HTTP does not natively support any mechanism for sending push notifications of changes on a specific resource on a client. However, in the real world, various mechanisms have been used successfully for years in advanced web services. These mechanisms Castellani & Loreto Expires July 29, 2011 [Page 5] Internet-Draft Map HTTP to COAP January 2011 enable a web server to send updates to clients without waiting for a poll request from the client. Such mechanisms can deliver updates to clients in a more timely manner while avoiding the latency experienced by client applications due to the frequent opening and closing of connections required to periodically poll for data. The two most common server push mechanisms are "HTTP long polling" and "HTTP streaming" [I-D.loreto-http-bidirectional]. These mechanisms can be used to observe the status of a resource changing over time. The subscription to a resource (the information kept by the server about an observation request to be continuously notified of changes in the state of the resource) is mimicked by the presence on the server of a hanging get (in the case of HTTP long polling) or by the fact that the client stays connected (in the case of HTTP streaming). An observable resource can be an "event source" that emits notifications corresponding to each change in its representation. Events occur regardless of whether or not they are observed. The CoAP server can mimic event sources on non event-enabled resources, by locally polling the resource and transmitting a notification when the content changes. Each observable resource can be identified using the "obs" link extension. 3.1. HTTP subscription to a CoAP resource In this section the mapping of CoAP observe to an HTTP client wishing to subscribe to a CoAP resource is discussed; [I-D.loreto-http-bidirectional] is a base reference of the most widely used HTTP bidirectional methods. The following sections are organized as follows: o Section 3.1.1 discusses possible mappings available for subscription parameters; o Section 3.1.2 points out the state required from an HTTP/CoAP proxy for handling CoAP observe sessions; o Section 3.1.3 proposes a possible mapping of CoAP observe to HTTP long-polling; o Section 3.1.4 describes a second mapping to HTTP streaming. 3.1.1. Subscription parameters mapping An HTTP client wishing to subscribe to a CoAP resource MUST insert in the first request the lifetime of the subscription, in order to enable the observe mechanism in the CoAP server. Castellani & Loreto Expires July 29, 2011 [Page 6] Internet-Draft Map HTTP to COAP January 2011 To insert in the request the needed options, there exist at least three options: o HTTP Request content: An XML document can be defined to hold the lifetime parameter. o HTTP URI Query parameter: The lifetime option can be inserted in the query parameters of the HTTP URI requested. A major issue in this method is the requirement for the HTTP/CoAP proxy to look through all the query parameters present in every served request, searching for the "lifetime" option. Moreover if found, the proxy needs to read it, insert a "Subscription-lifetime" CoAP option header and hopefully remove that query parameter from the request, before inserting the URI Option header in the CoAP packet. If the CoAP resource needs a "lifetime" parameter for its needs, in this way this parameter will not be accessible by the HTTP clients. o HTTP Header Option: a Subscription-Lifetime option header can be inserted in the HTTP request itself. The proxy can directly map that option to CoAP, operating only on the headers of the request without modifying the URI or the content of the message. HTTP standardization of a new header is required (IANA action?). The lifetime option SHOULD be inserted only to notify the CoAP server that the lifetime associated with that particular subscription has changed. The proxy MUST relay the information to the CoAP server, if the HTTP client has passed this option. The observe functionality is designed to be used for observing changes on resources, however if the resource value changes frequently, sending every new value is not viable; with the current observe design the traffic can be limited by the server. In some specific circumstances this cannot satisfy particular application requirements. Example: the resource "energy" is attached to a sensor measuring the energy detected in a channel in the previous K seconds, if energy is higher than X the application ALARM wants to be notified immediately; however ALARM cannot notify its threshold X to the server. This can lead to a notification delay or to missing the notification of the value of interest. As the example suggests, to better define the notification conditions, vendors may desire to use an extended set of parameters. For this reason observe parameters SHOULD be easily mappable to HTTP, and SHOULD support a possible growth of these parameters in number and type. The aforementioned reasons lead to prefer the "HTTP Request Content" method, and also to encourage a specific effort to define this Castellani & Loreto Expires July 29, 2011 [Page 7] Internet-Draft Map HTTP to COAP January 2011 format, to obtain the best interoperability and efficiency in it. Even if the unique parameter of the subscription will be the lifetime, probably the simplest technique seems to be using the HTTP request content. 3.1.2. Soft state requirements Current [I-D.ietf-core-observe] design requires the HTTP/CoAP proxy to maintain a state for each subscription, throughout the whole life of the observe session. As observe sessions are expected to be very long, this requirement has a strong impact on the proxy efficiency, in terms of maximum number of manageable subscriptions. In particular for every concurrent subscription, the proxy is required to maintain the data related to every active protocol: 1. CoAP endpoint IP/port, TID and headers as Token; 2. HTTP session data and in particular the TCP connection. This state may lead to various issues when the number of subscriptions grows, in particular the number of concurrently active TCP connections per proxy should be limited. As an added complexity, requiring the proxy to actively operate in the subscription process leads to an added point-of-failure of the subscription (e.g.: proxy restart leads to a subscription drop) and could add complexity to deploy load-balancing proxies for crowded WPANs. The state requested by CoAP observe is higher than the minimum possible, and different options for observe exist (as briefly described in Appendix A) that remove the need for subscription-long TCP connections. Further evaluation of the observe method in terms of state requirements is encouraged, especially towards solutions that do not require the presence of application-level data in the state (e.g. Token). 3.1.3. HTTP long-polling to CoAP observe HTTP long-polling is a well-known method to obtain notifications over HTTP. An extensive description of this technique can be found in Section 2 of [I-D.loreto-http-bidirectional]. Figure 1 shows an HTTP client requesting to start the observation of a CoAP resource for a period of time with duration "lifetime". Castellani & Loreto Expires July 29, 2011 [Page 8] Internet-Draft Map HTTP to COAP January 2011 A GET requesting a subscription can be distinguished by the presence of the "lifetime" parameter; the parameter is shown in the chart, but the actual method of transmitting that parameter is still an open issue as discussed in Section 3.1.1. The following charts also pin-point a list of open questions. To the best of our knowledge the questions have not yet been discussed in the WG, and for convenience have been gathered in Section 3.3. HTTP HTTP-CoAP CoAP client proxy server | | | | GET /foo | | | lifetime=60s | | |----------------------->| | | (hanging GET) | CON tid=47 | | | GET /foo | | | lifetime=60s | | |----------------------->| | | ACK tid=47 | | | 200 /foo | | 200 OK | "| | | (hanging GET) | Open question #1, #2 | | | | | | ..Time Passes.. | | | | | | CON tid=703 | | | 200 /foo | | | "| |"| GET foo | | | lifetime=60s | | |----------------------->| | | ACK tid=47 | | | 200 foo | | | "| |<-----------------------| | | | | | Open question #5 | | Castellani & Loreto Expires July 29, 2011 [Page 10] Internet-Draft Map HTTP to COAP January 2011 Figure 2: HTTP streaming to CoAP observe 3.2. CoAP observing an HTTP resource In Figure 3 a CoAP client wishes to observe an HTTP resource; the proxy to serve this request uses an HTTP long-polling. This is not possible without an assumption on the HTTP resource "/foo": the client should know in advance that "/foo" is a long- polling resource and it shares this knowledge with the proxy by inserting the "lifetime" option in the first message. The proxy receiving a GET with the "lifetime" option SHOULD handle that request differently, by requesting again the "/foo" resource every time a response is received and the lifetime is not expired. Castellani & Loreto Expires July 29, 2011 [Page 11] Internet-Draft Map HTTP to COAP January 2011 CoAP CoAP-HTTP HTTP client proxy server | | | | CON tid=47 | | | GET foo | | | lifetime=60s | | |----------------------->|GET /foo | | |----------------------->| | Open question #6 |hanging GET | | | | | Empty ACK? | | | ACK tid=47 | | |<-----------------------| | | | ..Time Passes.. | | | | | |<-----------------------| | | 200 OK | | CON tid=703 |"|GET /foo | | |----------------------->| | |hanging GET | | | | | | ..Time Passes.. | | | | | | Open question #7 | | | | | |<-----------------------| | CON tid=755 | 200 OK | | 200 foo"| | Figure 3: CoAP observe to HTTP long polling To the best of our knowledge a possible mapping for an HTTP streaming resource is not possible using the currently proposed protocol. Appendix A.2 briefly describes a possible solution to this, by proposing to add native support for chunked transfer encoding in CoAP. Castellani & Loreto Expires July 29, 2011 [Page 12] Internet-Draft Map HTTP to COAP January 2011 3.3. Open questions Open question #1 The second GET is identical to the first one. How should the proxy understand that this is not a new client requesting a subscription? Related question: How to match the received GETs to the right CoAP observe session (e.g.: token)? Open question #2 Should we need to consider the time-out issues present in bidirectional HTTP as described in [I-D.loreto-http-timeout]? Open question #3 Should the proxy send an ACK message immediately after receiving the response (+1) or after the HTTP client has received it? Open question #4 A response code different from the first one will be dropped. Does the subscription remain valid or should be dropped? (e.g.: Should a 500 error on the second notification be ignored or should the proxy drop the HTTP session?) Open question #5 Should the CoAP subscription be closed immediately (+1) or should send a RST when receives another notification? Open question #6: If lifetime expires while the HTTP GET is still waiting for a response, should the proxy should drop the TCP connection or .. what ? Open question #7: Should the proxy send always/all the notifications in a Confirmable way?. 4. Multicast CoAP supports multicast communication by using the UDP transport, while HTTP using TCP cannot talk to multiple hosts with a single request. The CoAP/HTTP proxy is in charge of the UDP to TCP mapping and will be also the most convenient place to merge multiple UDP responses to a single TCP stream. Notifications and multicast responses share a similarity between them, both are multiple responses to a single request; for this reason, a straightforward mapping for a request to a multicast CoAP resource is using the HTTP bidirectional methods. In contrast to this, the actual source of the response is lost using a direct mapping. This problem can be handled using two different Castellani & Loreto Expires July 29, 2011 [Page 13] Internet-Draft Map HTTP to COAP January 2011 approaches: o Proxy adds it: the proxy has the information available and can add it in the stream, using a predefined data format (efficient but requires a standardization effort/+1). o Not needed/Application adds it: the source information itself is not believed valuable by default, applications that require it should add the information in their content (no standardization, not efficient). Mappings proposed for the CoAP observe can also be suitable to solve this problem too: o HTTP streaming can be the preferred solution, because the client does not require a new connection for every value o the technique described in Appendix A.1 is also valid for receiving responses to multicast requests. o HTTP long polling can be also used, in the case the proxy is able to encapsulate more answers within a single message-body (e.g. Content-type: multipart/*). 5. Resource Discovery [I-D.ietf-core-link-format] specifies a link format useful for CoRE Resource Discovery; link format is realized extending the HTTP Link Header Format defined in [RFC5988]. This link format is offered as content of resources and transmitted using a new Internet media type (application/link-format), the typical resource holding this content is the "/.well-known/core": it contains a list of links useful for resource discovery. As defined in [RFC5988], in HTTP the links are delivered as HTTP headers within a specific resource; this architectural difference leads to a harder mapping of CoRE resource discovery in HTTP. 5.1. CoRE resource discovery by an HTTP Client If [I-D.ietf-core-link-format] is supported and the HTTP client handles the "application/link-format" media type, the well-known URI "/.well-known/core" can be accessed directly by the client and the resource discovery can be performed as discussed in [I-D.ietf-core-link-format]. Castellani & Loreto Expires July 29, 2011 [Page 14] Internet-Draft Map HTTP to COAP January 2011 HTTP HTTP-CoAP CoAP client proxy server | | | | GET /.well-known/core | | | Host: xxx.xxx | | | Accept: application/link-format | |----------------------->| | | | CON tid=47 | | | GET /.well-known/core | | | Accept: application/link-format | |----------------------->| | | CON tid=47 | | | 200 OK | | | Content-Type: application/link-format | | ;rel="index";n="Sensor Index" | 200 OK |<-----------------------| | Content-Type: application/link-format | | ;rel="index";n="Sensor Index" | |<-----------------------| | Figure 4: HTTP-Core Discovery If the HTTP client does not support the link format specification, some alternative mapping may be investigated: o HTTP OPTIONS method could be mapped to a "GET /.well-known/core"; o CoRE resource discovery can be implemented inside the proxy; the proxy can operate the resource discovery as a separate task, and can keep a cached version of the well-known URI(s). Using this knowledge Link headers can be inserted in the HTTP responses, even if that information is not present in the CoAP response. 6. Security Considerations TBD 7. IANA Considerations This document does not require any actions by the IANA. 8. Acknowledgements Special thanks to Nicola Bui and Michele Zorzi for their support and for the various contributions to this document. Castellani & Loreto Expires July 29, 2011 [Page 15] Internet-Draft Map HTTP to COAP January 2011 Thanks to Brian Frank for its support and its feedback about the content. 9. References 9.1. Normative References [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [I-D.ietf-core-coap] Shelby, Z., Frank, B., and D. Sturek, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-03 (work in progress), October 2010. [I-D.ietf-core-observe] Hartke, K. and Z. Shelby, "Observing Resources in CoAP", draft-ietf-core-observe-00 (work in progress), October 2010. [I-D.ietf-core-link-format] Shelby, Z., "CoRE Link Format", draft-ietf-core-link-format-02 (work in progress), December 2010. 9.2. Informative References [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [I-D.loreto-http-bidirectional] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, "Known issues and best practices for the Use of Long Polling and Streaming in Bidirectional HTTP", draft-loreto-http-bidirectional-05 (work in progress), October 2010. [I-D.loreto-http-timeout] Loreto, S., Thomson, M., and G. Wilkins, "Hypertext Transfer Protocol (HTTP) Timeouts", draft-loreto-http-timeout-00 (work in progress), June 2010. Castellani & Loreto Expires July 29, 2011 [Page 16] Internet-Draft Map HTTP to COAP January 2011 Appendix A. Alternatives for CoAP subscription/notification(s) A.1. Server-to-server notifications In an M2M network environment, communication between entities is envisioned to happen using a peer-to-peer host model. Such consideration could motivate a subscription architecture working in server-to-server fashion. HTTP HTTP-CoAP CoAP client proxy server | | | | GET /foo | | | Link: ; rel=via | | | | | | " | | | | | | | " | | |----------------------->| | | | | | | CON tid=47 | | | GET foo | | | source-URI=bar | | | lifetime=60s | | |----------------------->| | | | | | ACK tid=47 | | | 200 | | | "; rel=via | | | Content-Type: message/http | | | | | 200 OK | | | "| | | | | | | ..Time Passes.. | | | | | | CON tid=703 | | | 200 bar | | | source-URI=foo | | | "; rel=via | | | Content-Type: message/http | | | | | 200 OK | | | "| | | | | | | ACK tid=703 | | |----------------------->| | | | | | | Figure 5: Server-to-Server HTTP Mapping The diagram depicted in Figure 5 introduces a new CoAP Option header, source-URI representing the resource that is the source of the request. When this option is present in a request, the client is willing to start a subscription session to the resource. This option can remove the need for the Subscription-lifetime header; the lifetime parameter, together with the other subscription parameters, can be carried as part of the content of the initial subscription request, as described in Section 3.1.1. Castellani & Loreto Expires July 29, 2011 [Page 18] Internet-Draft Map HTTP to COAP January 2011 The interaction is performed between two entities both assuming the server role. This characteristic can cause at least two issues that need to be properly evaluated: o Only hosts supporting inbound connectivity on a TCP port can access this subscription functionality. In an IPv6/M2M network environment this problem can be more easily addressed. o Accepting inbound connections can lead to new security threats, this requires deeper investigation Nevertheless server-to-server has significant advantages in terms of scalability and reliability; it does not require the HTTP/CoAP proxy to hold any state about the subscription. For this reason even if the proxy is load-balanced or rebooted the subscription will remain in place. Moreover the need for maintaining permanent TCP connections for every observe session is fully removed. A.2. Observe using native Transfer-Encoding chunked Transfer-Encoding chunked is a data transfer mechanism present in HTTP [RFC2616]; this technique is used in HTTP to obtain a bidirectional channel as described in [I-D.loreto-http-bidirectional]. If the observe mechanism is built upon a Native chunked Transfer- Encoding in CoAP, it could be mapped straightforwardly to HTTP streaming by an HTTP/CoAP proxy, without any soft-state in the CoAP part of the proxy (on the HTTP side, the TCP connection must be kept open). Porting chunked Transfer-Encoding to an UDP based protocol can be realized with a new CoAP Option header (New-Opt). If the New-Opt option is present with value 1, the exchange is not ending with a single response but only when a response is received with a 0-valued New-Opt option. If the source emits only one message without acknowledgment the transaction number can be preserved, in this scenario the source can emit new chunks only if the previous one has been acknowledged. The Token header can be used if more than one unacknowledged message has to be transmitted simultaneously. Realizing the HTTP streaming mapping in CoAP with this option present is straightforward, however on the HTTP side of the proxy a TCP connection is open for every active subscription. If this functionality is properly investigated, it may offer a solution also to the transfer of resources having a large Castellani & Loreto Expires July 29, 2011 [Page 19] Internet-Draft Map HTTP to COAP January 2011 representation. Example: the chunks may belong to a single large representation (case A) or to multiple smaller representations (case B). The client can distinguish between case A and B, if the server tells the client in the first message using a flag in New-Opt. Authors' Addresses Angelo P. Castellani University of Padova Via Gradenigo 6/B Padova 35131 Italy Email: angelo@castellani.net Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: salvatore.loreto@ericsson.com Castellani & Loreto Expires July 29, 2011 [Page 20]