CoRE Working Group A.P. Castellani
Internet-Draft University of Padova
Intended status: Informational S. Loreto
Expires: January 03, 2013 Ericsson
A. Rahman
InterDigital Communications, LLC
T. Fossati
E. Dijk
Philips Research
July 04, 2012

Best Practices for HTTP-CoAP Mapping Implementation


This draft provides reference information for HTTP-CoAP proxy implementors. It details deployment options, discusses possible approaches for URI mapping, and provides useful considerations related to protocol translation.

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

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 January 03, 2013.

Copyright Notice

Copyright (c) 2012 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 ( 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.

Table of Contents

1. Introduction

RESTful protocols, such as HTTP [RFC2616] and CoAP [I-D.ietf-core-coap], can interoperate through an intermediary proxy which performs cross-protocol mapping.

A reference about the mapping process is provided in [I-D.ietf-core-coap]. However, depending on the involved application, deployment scenario, or network topology, such mappings can be realized using a wide range of intermediaries.

Moreover, the process of implementing such a proxy can be complex, and details regarding its internal procedures and design choices require further elaboration, which is provided in this document.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2. Terminology

Cross-Protocol Proxy (or Cross Proxy): a cross-protocol mapping proxy, typically a HTTP-CoAP mapping proxy in the context of this document.

HC URI mapping: mapping of a HTTP URI to an equivalent CoAP URI

One-way and two-way cross proxies can be realized using the following general types of proxies:

Forward proxy (F):
Is a proxy known by the client (either CoAP or HTTP) used to access a specific cross-protocol server (respectively HTTP or CoAP). Main feature: server(s) do not require to be known in advance by the proxy (ZSC: Zero Server Configuration).
Reverse proxy (R):
Is a proxy known by the client to be the server, however for a subset of resources it works as a proxy, by knowing the real server(s) serving each resource. When a cross-protocol resource is accessed by a client, the request will be silently forwarded by the reverse proxy to the real server (running a different protocol). If a response is received by the reverse proxy, it will be mapped, if possible, to the original protocol and sent back to the client. Main feature: client(s) do not require to know in advance the proxy (ZCC: Zero Client Configuration).
Interception proxy (I):
This proxy [RFC3040] can intercept any origin protocol request (HTTP or CoAP) and map it to the destination protocol, without any kind of knowledge about the client or server involved in the exchange. Main feature: client(s) and server(s) do not require to know or be known in advance by the proxy (ZCC and ZSC).

A server-side (SS) proxy is placed in the same network domain of the server; Conversely a client-side (CS) is in the same network domain of the client. In any other case than SS or CS, the proxy is said to be External (E).

3. Cross-Protocol Usage of URIs

A Uniform Resource Identifier (URI) provides a simple and extensible means for identifying a resource. It enables uniform identification of resources via a separately defined extensible set of naming schemes [RFC3986].

URIs are formed of at least three components: scheme, authority and path. The scheme is the first part of the URI, and it often corresponds to the protocol used to access the resource. However, as noted in Section 1.2.2 of [RFC3986] the scheme does not imply that a particular protocol is used to access the resource.

Both CoAP and HTTP implement the REST paradigm, so, in general, the same web resource, i.e., identified by the same URI, can be accessed using either one of these protocols.

This could happen as long as the URI scheme of the target resource is supported by the client; however, web clients may support only a limited set of schemes. Example: HTTP clients typically support only 'http' and 'https' schemes.

Whenever does not exist an URI to access the resource with a scheme supported by the client, communication may still happen if the cross proxy supports mapping URIs to a supported scheme. The involved process is discussed in the following section.

4. URI Mapping

URI Mapping: the act of providing an alternative URI to access a target resource.

Example: Assume that the target resource is "coap://". A possible URI mapping could be "".

In the previous example the scheme changes between the mapped URI and the original one; this special kind of URI is defined here as cross-protocol URI (or cross URI).

Cross proxies MAY provide cross URI to allow accessing them to clients supporting only a limited set of schemes.

If a cross-protocol URI exists, authority and path parts of the URI may change as well.

Example: Assume that the following resource exists - "coap://". The resource identified by "" may not exist or be non-equivalent to the one identified by the 'coap' scheme.

The process of providing cross URIs could be complex, since a proper mechanism to statically or dynamically (discover) map the resource is needed.

Two static HC URI mappings are discussed in the following subsections.

4.1. Homogeneous Mapping

The URI mapping between CoAP and HTTP is called homogeneous, if the same resource is identified by URIs with different schemes.

Example: The CoAP resource "//" identified either by the URI "coap://", and or by the URI "" is the same. When the resource is accessed using HTTP, the mapping from HTTP to CoAP is performed by a cross proxy

When homogeneous cross URIs are available, HTTP-CoAP Interception Cross Proxies are easily implementable.

4.2. Embedded Mapping

When the HC URI mapping of the resource embeds inside it the authority and path part of the native URI, then the mapping is said to be embedded.

Example: The CoAP resource "coap://" can be accessed at "".

This mapping technique can be used to reduce the mapping complexity in an HTTP-CoAP Reverse Cross Proxy.

5. HTTP-CoAP Implementation

The mapping of HTTP requests to CoAP and of the response back to HTTP is defined in Section 8.2 of [I-D.ietf-core-coap].

The mapping of a CoAP response code to HTTP is not straightforward, this mapping MUST be operated according to Table 4 of [I-D.ietf-core-coap].

No temporal upper bound is defined for a CoAP server to provide the response, thus for long delays the HTTP client or any other proxy in between MAY timeout. Further discussion is available in Section 7.1.4 of [I-D.ietf-httpbis-p1-messaging].

The cross proxy MUST define an internal timeout for each pending CoAP request, because the CoAP server may silently die before completing the request.

Even if the DNS protocol may not be used inside the constrained network, having valid DNS entries for constrained hosts, where possible, MAY help HTTP clients to access the resources offered by them.

HTTP connection pipelining (section of [I-D.ietf-httpbis-p1-messaging]) is transparent to the CoAP network: the cross proxy will sequentially serve the pipelined requests by issuing different CoAP requests.

5.1. HTTP-CoAP Reverse Cross Proxy

HTTP-CoAP Reverse Cross (HCRC) Proxy is accessed by web clients only supporting HTTP, and handles their requests directed to CoAP servers by mapping them to CoAP, and mapping back the received response to HTTP. This mechanism is transparent to the client, as it may assume that is communicating with a regular HTTP server.

Typically, the HCRC Proxy is expected to be located server-side (SS), in particular deployed at the edge of the constrained network. The arguments supporting SS placement in this case are the following:

Translation between HTTP and CoAP requires also a TCP to UDP mapping; UDP performance over the unconstrained Internet may not be adequate. In order to minimize the number of required retransmissions and overall reliability, TCP/UDP conversion SHOULD be performed at a SS placed proxy.
Efficient caching requires that all the CoAP traffic is intercepted by the same proxy, thus an SS placement, collecting all the traffic, is strategical for this need.
To support CoAP using local-multicast functionalities available in the constrained network, the cross proxy MAY require a network interface directly attached to the constrained network.
                            |      |                                  
                            | DNS  |                                 
                            |      |                                 
                                               /                    \
                                              /  /-----\     /-----\ \
                                             /     CoAP       CoAP    \
                                            /    server      server    \
                                           ||    \-----/     \-----/   ||
                                     +----------+                      ||
                                     | HTTP/CoAP|        /-----\       ||
                                     |  Cross   |          CoAP        ||
                                     |  Proxy   |         server       ||
    +------+                         +----------+        \-----/       ||
    |HTTP  |                               ||   /-----\                ||
    |Client|                               ||    CoAP                  ||
    +------+                                \    server                /
                                             \  \-----/               /
                                              \         /-----\      /
                                               \         CoAP       /
                                                \        server    /
                                                 \      \-----/   /

5.2. Other Placement Aspects

Other important aspects involved in the selection of which type of proxy deployment, whose choice impacts its placement too, are the following:

Client/Proxy/Network configuration overhead:
Forward proxies require either static configuration or discovery support in the client. Reverse proxies require either static configuration, server discovery or embedded URI mapping in the proxy. Interception proxies require minimal deployment effort (i.e. routing setup of web traffic toward the proxy).
Both aspects are typically addressed using redundancy. CS deployments, due to the limited catchment area and administrative-wide domain of operation, have looser requirements on this. SS deployments, in dense/popular/critical environments, have stricter requirements and MAY need to be replicated. Stateful proxies (e.g. reverse) may be complex to replicate.

Discussion about security impacts of different deployments is covered in Section 8.

Table 1 shows some interesting cross proxy deployment scenarios, and notes the advantages related to each scenario.

Interesting cross proxy deployments
Feature F CS R SS I SS
TCP/UDP - + +
Multicast - + +
Caching - + +
Scalability/Availability + +/- +
Configuration - - +

Guidelines proposed in the previous paragraphs have been used to fill out the above table. In the first three rows, it can be seen that SS deployment is preferred versus CS. Scalability/Availability issues can be generally handled, but some complexity may be involved in reverse proxies scenarios. Configuration overhead could be simplified when interception proxies deployments are feasible.

When support for legacy HTTP clients is required, it may be preferable using configuration/discovery free deployments. Discovery procedures for client or proxy auto-configuration are still under active-discussion: see [I-D.vanderstok-core-bc], [I-D.bormann-core-simple-server-discovery] or [I-D.shelby-core-resource-directory]. Static configuration of multiple forward proxies is typically not feasible in existing HTTP clients.

5.3. Caching and Congestion Control

The cross proxy SHOULD limit the number of requests to CoAP servers by responding, where applicable, with a cached representation of the resource.

Duplicate idempotent pending requests to the same resource SHOULD in general be avoided, by duplexing the response to the relevant hosts without duplicating the request.

If the HTTP client times out and drops the HTTP session to the proxy (closing the TCP connection), the cross proxy SHOULD wait for the CoAP response and cache it if possible. Further idempotent requests to the same resource can use the result present in cache, or, if a response has still to come, requests will wait on the open CoAP session.

Resources experiencing a high access rate coupled with high volatility MAY be observed [I-D.ietf-core-observe] by the cross proxy to keep their cached representation fresh while minimizing the number of needed messages. See Section 5.4 for a heuristic that enables the cross proxy to decide whether observing is a more convenient strategy than ordinary refreshing via Max-Age/ETag-based mechanisms.

Specific deployments may show highly congested servers/resources -- e.g. popular servers, etc. A careful analysis is required to pick the correct caching policy involving these resources, also taking into consideration the security implications that may impact these targets specifically, and the constrained network in general.

To this end when traffic reduction obtained by the caching mechanism is not adequate, the cross proxy could apply stricter policing by limiting the amount of aggregate traffic to the constrained network. In particular, the cross proxy SHOULD pose a rigid upper limit to the number of concurrent CoAP requests pending on the same constrained network; further request MAY either be queued or dropped. In order to efficiently apply this congestion control, the cross proxy SHOULD be SS placed.

5.4. Cache Refresh via Observe

There are cases where using the CoAP observe protocol to handle proxy cache refresh may be preferable to the validation mechanism based on ETag's defined in section 5.6.2 of [I-D.ietf-core-coap]. Such scenarios include, but are not limited to, sleeping nodes -- with possibly high variance in requests' distribution -- which would greatly benefit from a server driven cache update mechanism. Ideal candidates would also be the crowded or very low throughput networks, where reduction of the total number of exchanged messages is an important requirement.

This subsection aims at providing a practical evaluation method to decide whether the refresh of a cached resource R is more efficiently handled via ETag validation or by establishing an observation on R.

Let T_R be the mean time between two client requests to resource R, let F_R be the freshness lifetime of R representation, and let M_R be the total number of messages exchanged towards resource R. If we assume that the initial cost for establishing the observation is negligible, an observation on R reduces M_R iff T_R < 2*F_R with respect to using ETag validation, that is iff the mean arrival time of requests for resource R is greater than half the refresh rate of R.

When using observations M_R is always upper bounded by 2*F_R: in the constrained network no more than 2*F_R messages will be generated towards resource R.

Proof: Let T be the evaluated interval of time, let M_Ro be the total number of messages exchanged towards resource R using observation, and let M_Re be the total number of messages exchanged towards resource R using ETag validation. The following equations hold M_Re = T*2/T_R, M_Ro = T/F_R. M_Ro < M_Re iff 1/F_R < 2/T_R, that is T_R < 2*F_R. The amount of messages saved using observation is T*(2*F_R-T_R)/(T_R*F_R).

Example: assume that F_R is one second and T_R is 1.5 seconds. Since 1.5 is lower than 2*1, an observation on R reduces M_R. In a single day of usage, 28800 messages will be saved if the cross proxy establishes an observation on R. The single message cost required to establish this observation is negligible.

5.5. Use of CoAP Blockwise Transfer

A cross proxy SHOULD support CoAP blockwise transfers [I-D.ietf-core-block] to allow transport of large CoAP payloads while avoiding link-layer fragmentation in LLNs, and to cope with small datagram buffers in CoAP end-points as described in [I-D.ietf-core-coap]. A cross proxy SHOULD attempt to retry a CoAP PUT or POST request with a payload using blockwise transfer if the destination CoAP server responded with 4.13 (Request Entity Too Large) to the original request. A cross proxy SHOULD attempt to use blockwise transfer when sending a CoAP PUT or POST request message that is larger than BLOCKWISE_THRESHOLD. The value of BLOCKWISE_THRESHOLD is implementation-specific, for example it may set by an administrator, preset to a known or typical UDP datagram buffer size for CoAP end-points, to N times the size of a link-layer frame where e.g. N=5, preset to a known IP MTU value, or set to a known Path MTU value.

For improved latency a cross proxy MAY initiate a blockwise CoAP request triggered by an incoming HTTP request even when the HTTP request message has not yet been fully received, but enough data has been received to send one or more data blocks to a CoAP server already.

6. CoAP-HTTP Implementation

The CoAP protocol [I-D.ietf-core-coap] allows CoAP clients to request CoAP proxies to perform an HTTP request on their behalf. This is accomplished by the CoAP client populating an HTTP absolute URI in the 'Proxy-URI' option of the CoAP request to the CoAP proxy. An HTTP absolute URI is an HTTP URI that does not contain a fragment component [RFC3986]. The proxy then composes an HTTP request with the given URI and sends it to the appropriate HTTP origin server. The server then returns the HTTP response to the proxy, which the proxy returns to the CoAP client via a CoAP response.

6.1. Basic mapping

The basic mapping of CoAP methods to HTTP is defined in [I-D.ietf-core-coap]. Specifically the {GET, PUT, POST, DELETE} set of CoAP methods are mapped to the equivalent HTTP methods.

In general, an implementation will translate and forward CoAP requests to the HTTP origin server and translate back HTTP responses to CoAP responses, typically employing a certain amount of caching to make this translation more efficient.

The next sections give some hints and examples for implementing the translation.

6.2. Payloads and Media Types

CoAP supports only a subset of media types. A proxy should convert payloads and approximate content-types as closely as possible. For example, if a HTTP server returns a resource representation in "text/plain; charset=iso-8859-1" format, the proxy should convert the payload to "text/plain; charset=utf-8" format. If conversion is not possible, the proxy can specify a media type of "application/octet-stream".

6.3. Max-Age and ETag Options

The proxy can determine the Max-Age Option for responses to GET requests by calculating the freshness lifetime (see Section 13.2.4 of [RFC2616]) of the HTTP resource representation retrieved. The Max-Age Option for responses to POST, PUT or DELETE requests should always be set to 0.

The proxy can assign entity tags to responses it sends to a client. These can be generated locally, if the proxy employs a cache, or be derived from the ETag header field in a response from the HTTP origin server, in which case the proxy can optimize future requests to the HTTP by using Conditional Requests. Note that CoAP does not support weak entity tags.

6.4. Use of CoAP Blockwise Transfer

A CoAP-to-HTTP cross proxy SHOULD support CoAP blockwise transfers [I-D.ietf-core-block] to allow transport of large CoAP payloads while avoiding link-layer fragmentation in LLNs, and to cope with small datagram buffers in CoAP end-points as described in [I-D.ietf-core-block].

For improved latency a CoAP-to-HTTP cross proxy MAY initiate a HTTP request triggered by an incoming blockwise CoAP request even when blocks of the CoAP request have only been partially received by the proxy, in cases where the Content-Length field is not going to be used in the HTTP request. This is useful especially if the network between proxy and HTTP server involves low-bandwidth links.

6.5. HTTP Status Codes 1xx and 3xx

CoAP does not have provisional responses (HTTP Status Codes 1xx) or responses indicating that further action needs to be taken (HTTP Status Codes 3xx). When a proxy receives such a response from the HTTP server, the response should cause the proxy to complete the request, for example, by following redirects. If the proxy is unable or unwilling to do so, it can return a 5.02 (Bad Gateway) error.

7. IANA Considerations

This memo includes no request to IANA.

8. Security Considerations

The security concerns raised in Section 15.7 of [RFC2616] also apply to the cross proxy scenario. In fact, the cross proxy is a trusted (not rarely a transparently trusted) component in the network path.

The trustworthiness assumption on the cross proxy cannot be dropped. Even if we had a blind, bi-directional, end-to-end, tunneling facility like the one provided by the CONNECT method in HTTP, and also assuming the existence of a DTLS-TLS transparent mapping, the two tunneled ends should be speaking the same application protocol, which is not the case. Basically, the protocol translation function is a core duty of the cross proxy that can't be removed, and makes it a necessarily trusted, impossible to bypass, component in the communication path.

A reverse proxy deployed at the boundary of a constrained network is an easy single point of failure for reducing availability. As such, a special care should be taken in designing, developing and operating it, keeping in mind that, in most cases, it could have fewer limitations than the constrained devices it is serving.

The following sub paragraphs categorize and argue about a set of specific security issues related to the translation, caching and forwarding functionality exposed by a cross proxy module.

8.1. Traffic overflow

Due to the typically constrained nature of CoAP nodes, particular attention SHOULD be posed in the implementation of traffic reduction mechanisms (see Section 5.3), because inefficient implementations can be targeted by unconstrained Internet attackers. Bandwidth or complexity involved in such attacks is very low.

An amplification attack to the constrained network may be triggered by a multicast request generated by a single HTTP request mapped to a CoAP multicast resource, as considered in Section XX of [I-D.ietf-core-coap].

The impact of this amplification technique is higher than an amplification attack carried out by a malicious constrained device (i.e. ICMPv6 flooding, like Packet Too Big, or Parameter Problem on a multicast destination [RFC4732]), since it does not require direct access to the constrained network.

The feasibility of this attack, disruptive in terms of CoAP server availability, can be limited by access controlling the exposed HTTP multicast resource, so that only known/authorized users access such URIs.

8.2. Handling Secured Exchanges

It is possible that the request from the client to the cross proxy is sent over a secured connection. However, there may or may not exist a secure connection mapping to the other protocol. For example, a secure distribution method for multicast traffic is complex and MAY not be implemented (see [I-D.ietf-core-groupcomm]).

By default, a cross proxy SHOULD reject any secured client request if there is no configured security policy mapping. This recommendation MAY be relaxed in case the destination network is believed to be secured by other, complementary, means. E.g.: assumed that CoAP nodes are isolated behind a firewall (e.g. as the SS cross proxy deployment shown in Figure 1), the cross proxy may be configured to translate the incoming HTTPS request using plain CoAP (i.e. NoSec mode.)

The HC URI mapping MUST NOT map to HTTP (see Section 4) a CoAP resource intended to be accessed only using HTTPS.

A secured connection that is terminated at the cross proxy, i.e. the proxy decrypts secured data locally, raises an ambiguity about the cacheability of the requested resource. The cross proxy SHOULD NOT cache any secured content to avoid any leak of secured information. However in some specific scenario, a security/efficiency trade-off could motivate caching secured information; in that case the caching behavior MAY be tuned to some extent on a per-resource basis.

8.3. Spoofing and Cache Poisoning

In web security jargon, the "cache poisoning" verb accounts for attacks where an evil user causes the proxy server to associate incorrect content to a cached resource, which work through especially crafted HTTP requests or request/response combos.

When working in CoAP NoSec mode, the use of UDP makes cache poisoning on the constrained network easy and effective, simple address spoofing by a malicious host is sufficient to perform the attack. The implicit broadcast nature of typical link-layer communication technologies used in constrained networks lead this attack to be easily performed by any host, even without the requirement of being a router in the network. The ultimate outcome depends on both the order of arrival of packets (legitimate and rogue) and the processing/discarding policy at the CoAP node; attackers targeting this weakness may have less requirements on timing, thus leading the attack to succeed with high probability.

In case the threat of a rogue mote acting in the constrained network can't be winded up by appropriate procedural means, the only way to avoid such attacks is for any CoAP server to work at least in MultiKey mode with a 1:1 key with the cross proxy. SharedKey mode would just mitigate the attack, since a guessable MIDs and Tokens generation function at the cross proxy side would make it feasible for the evil mote to implement a "try until succeed" strategy. Also, (authenticated) encryption at a lower layer (MAC/PHY) could be defeated by a slightly more powerful attacker, a compromised router mote.

9. Acknowledgements

Special credit is given to Klaus Hartke who provided the text for Section 6 and a lot of direct input to this document. Special credit about the text in Section 6 is given to Carsten Bormann who provied parts of it.

Thanks to Zach Shelby, Michele Rossi, Nicola Bui, Michele Zorzi, Peter Saint-Andre, Cullen Jennings, Kepeng Li, Brian Frank, Peter Van Der Stok, Kerry Lynn, Linyi Tian, Dorothy Gellert for helpful comments and discussions that have shaped the document.

The research leading to these results has received funding from the European Community's Seventh Framework Programme [FP7/2007-2013] under grant agreement n. [251557].

10. References

10.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3986] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[I-D.ietf-core-coap] Shelby, Z, Hartke, K, Bormann, C and B Frank, "Constrained Application Protocol (CoAP)", Internet-Draft draft-ietf-core-coap-10, June 2012.
[I-D.ietf-core-observe] Hartke, K, "Observing Resources in CoAP", Internet-Draft draft-ietf-core-observe-05, March 2012.
[I-D.ietf-core-block] Bormann, C and Z Shelby, "Blockwise transfers in CoAP", Internet-Draft draft-ietf-core-block-08, February 2012.
[I-D.ietf-core-groupcomm] Rahman, A and E Dijk, "Group Communication for CoAP", Internet-Draft draft-ietf-core-groupcomm-01, March 2012.
[I-D.ietf-httpbis-p1-messaging] Fielding, R, Lafon, Y and J Reschke, "HTTP/1.1, part 1: URIs, Connections, and Message Parsing", Internet-Draft draft-ietf-httpbis-p1-messaging-19, March 2012.

10.2. Informative References

[RFC3040] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001.
[RFC4732] Handley, M., Rescorla, E., IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[I-D.vanderstok-core-bc] Stok, P and K Lynn, "CoAP Utilization for Building Control", Internet-Draft draft-vanderstok-core-bc-05, October 2011.
[I-D.bormann-core-simple-server-discovery] Bormann, C, "CoRE Simple Server Discovery", Internet-Draft draft-bormann-core-simple-server-discovery-01, March 2012.
[I-D.shelby-core-resource-directory] Shelby, Z and S Krco, "CoRE Resource Directory", Internet-Draft draft-shelby-core-resource-directory-03, May 2012.

Authors' Addresses

Angelo P. Castellani University of Padova Via Gradenigo 6/B Padova, 35131 Italy EMail:
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas, 02420 Finland EMail:
Akbar Rahman InterDigital Communications, LLC 1000 Sherbrooke Street West Montreal, H3A 3G4 canada Phone: +1 514 585 0761 EMail:
Thomas Fossati KoanLogic Via di Sabbiuno 11/5 Bologna, 40136 Italy Phone: +39 051 644 82 68 EMail:
Esko Dijk Philips Research EMail: