CoRE Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Standards Track March 27, 2012 Expires: September 28, 2012 CoRE Roadmap and Implementation Guide draft-bormann-core-roadmap-00 Abstract The CoRE set of protocols, in particular the CoAP protocol, is defined in draft-ietf-core-coap in conjunction with a number of specifications that are currently nearing completion. There are also several dozen more individual Internet-Drafts in various states of development, with various levels of WG review and interest. Today, this is simply a bewildering array of documents. Beyond the main four documents, it is hard to find relevant information and assess the status of proposals. At the level of Internet-Drafts, the IETF has only adoption as a WG document to assign status - too crude an instrument to assess the level of development and standing for anyone who does not follow the daily proceedings of the WG. With a more long-term perspective, as additional drafts mature and existing specifications enter various levels of spec maintenance, the entirety of these specifications may become harder to understand, pose specific implementation problems, or be simply inconsistent. The present guide aims to provide a roadmap to these documents as well as provide specific advice how to use these specifications in combination. In certain cases, it may provide clarifications or even corrections to the specifications referenced. This guide is intended as a continued work-in-progress, i.e. a long- lived Internet-Draft, to be updated whenever new information becomes available and new consensus on how to handle issues is formed. Similar to the ROHC implementation guide, RFC 4815, it might be published as an RFC at some future time later in the acceptance curve of the specifications. This document does not describe a new protocol or attempt to set a new standard of any kind - it mostly describes good practice in using the existing specifications, but it may also document emerging consensus where a correction needs to be made. The current version -00 of this document is an early draft that is intended to spark the further collection of relevant information. Bormann Expires September 28, 2012 [Page 1] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 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 September 28, 2012. 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 (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. Bormann Expires September 28, 2012 [Page 2] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Main Four . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. The CoAP protocol . . . . . . . . . . . . . . . . . . . . 5 2.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. Further reading . . . . . . . . . . . . . . . . . . . . . 7 3. Informational Drafts . . . . . . . . . . . . . . . . . . . . . 8 3.1. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . . 8 4. CoAP over X . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Optional components of CoRE . . . . . . . . . . . . . . . . . 10 5.1. CoAP-misc . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Patience, Leisure, Pledge, or: Timing extensions . . . . . 10 5.3. Extending Observe . . . . . . . . . . . . . . . . . . . . 11 5.4. Service discovery . . . . . . . . . . . . . . . . . . . . 11 5.5. Server discovery, Naming, etc. . . . . . . . . . . . . . . 12 5.6. More support for sleepy nodes . . . . . . . . . . . . . . 12 6. Replaced drafts . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 Bormann Expires September 28, 2012 [Page 3] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 1. Introduction (To be written - for now please see the Abstract.) 1.1. Terminology This document is a guide. However, it might evolve to make specific recommendations on how to use standards-track specifications. Therefore: 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 RFC 2119. They indicate requirement levels for compliant CoRE implementations [RFC2119]. Note that these keywords are not only used where a correction or clarification is intended; the latter are explicitly identified as such. The term "byte" is used in its now customary sense as a synonym for "octet". Bormann Expires September 28, 2012 [Page 4] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 2. The Main Four The main component of the CoRE architecture is the Constrained Application Protocol (CoAP). It aims to provide a RESTful transfer service, not unlike HTTP, but radically simplified for the use on constrained devices on constrained networks. REST is the architectural style that informed the design of HTTP [REST]. The terms "constrained device" and "constrained network" refer to limited-capability devices such as sensors operating on networks such as the IEEE 802.15.4 based 6LoWPAN [RFC4919]. [I-D.bormann-lwig-guidance] provides a more detailed discussion of what we mean by these terms. 2.1. The CoAP protocol The CoAP protocol is defined in three specifications: o [I-D.ietf-core-coap] o [I-D.ietf-core-block] o [I-D.ietf-core-observe] The first specification, [I-D.ietf-core-coap], provides the core transfer protocol, including the means to provide communication security using the DTLS protocol [RFC6347] (compare this to the way [RFC2616] and [RFC2818] define HTTP and HTTPS). The protocol is structured into a message layer, which provides duplicate detection and optional message reliability on top of UDP, and a request/ response layer, which provides the usual REST operations GET, PUT, POST, and DELETE. A highly efficient protocol encoding carries the 4-byte base header, a sequence of _Options_, and the payload (body) of a message. The main extension points of CoAP are its Options, similar to the way new header fields are used to extend HTTP. Since CoAP is a very simple protocol based on UDP, it is limited in its transfer size by the datagram sizes provided by UDP. As a further constraint, many constrained networks do not provide good reliability of delivery once their small frame sizes are exceeded and the adaptation layer is forced to fragment [WEI]. This may lead to a practical limitation to payload sizes as small as 64 bytes. [I-D.ietf-core-block] extends the base CoAP protocol with three options that enable _blockwise_ transfer, i.e., splitting up a larger transfer into a sequence of smaller transactions, as well as the early determination of the overall size of the resource representation. In HTTP, transactions are always client initiated, and it is the Bormann Expires September 28, 2012 [Page 5] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 responsibility of the client to perform GET operations again and again (polling) if it wants to stay up to date about the status of a resource. This "pull model" becomes expensive in an environment with limited power, limited network resources, and nodes that sleep most of the time. Some more or less savory workarounds have been developed for HTTP [RFC6202], but, as a new protocol, CoAP can do better. [I-D.ietf-core-observe] extends the base CoAP protocol with an option that a client can use to indicate its interest in further updates from a resource. If the server accepts this option, the client becomes an _Observer_ of this resource and receives an asynchronous notification message each time it changes. Each such notification message is identical in structure to the response to the initial GET request. While the "Block" and "Observe" specifications are optional additions to the CoAP protocol (just as the core specification already defines 14 options most of which will not need to be used in every message), they together form what is now generally considered to be the CoAP protocol. All three CoAP specifications are, at the time of this writing, in Working-Group Last-Call [RFC2418], a prerequisite to submitting them to the IESG for publication as a Standards-Track RFC. The specifications, together with link-format (below), have been widely implemented in highly interoperable implementations: the recent ETSI "plugtest" event was attended by 15 organizations with 20 implementations; in over 3000 tests performed only about 6 % failed. 2.2. Discovery The fourth specification in the main set now nearing completion does not extend the CoAP protocol but addresses a different problem. In the Web, a number of methods for discovery of resources are common. Initially, Web discovery was just performed by humans based on an entry resource to a server (e.g., "/index.html"). This resource then includes links that directly or indirectly allow a human to reach the other Web resources that make up the Web site. Web discovery can be performed by machines if standardized interfaces and resource descriptions are available. Among the component mechanisms for Web discovery that are standardized in the IETF are the well-known resource path "/.well-known/..." [RFC5785] and the HTTP link header [RFC5988]. Several related techniques are in common use today. Clearly, in the machine-to-machine environments that will be typical of CoAP applications, it is important to enable devices to discover each other and their resources. Autonomous devices and embedded systems necessitate uniform, interoperable resource discovery. Bormann Expires September 28, 2012 [Page 6] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 A basic component for this is provided by a standardized description format for the resources a server provides, the _link-format_. Unless other methods of discovery are available, CoAP servers should provide such a description via the well-known URI "/.well-known/core", available for access via a GET request on that URI. (More advanced resource discovery schemes might make the same description available by other means, e.g. by posting it to a resource directory.) The description format has been adapted from the format used in the HTTP link header [RFC5988], which is simple and easy to parse. In contrast to the HTTP specification, link-format is specified as an Internet media type (what used to be called "MIME type") and intended to be carried around in the payload [I-D.ietf-core-link-format]. [I-D.ietf-core-link-format] has passed Working-Group Last-Call and was submitted to the IESG and started IETF last-call on 2012-02-14. With several very good comments received during the IETF-wide review process, another revision is expected before publication as a Standards-Track RFC, but there will be few implications on the interoperability of current implementations. 2.3. Further reading A recent article provides a more detailed overview over the CoRE documents nearing completion [SB]. While the specification documents themselves have to go into meticulous details on every aspect of their protocols, they are the ultimate reference source and are the recommended reading if this basic overview is not sufficient. Bormann Expires September 28, 2012 [Page 7] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 3. Informational Drafts 3.1. Multicast As it is based on UDP, CoAP easily supports the use of IP multicast to confer messages. However, there are difficult issues around making the desirable multicast applications actually work well. This led to an additional milestone on the CoRE charter: Nov 2012: Using CoAP for group communications to IESG as Informational This draft is still in an explorative mode and will require additional investigation before conclusive results become available [I-D.ietf-core-groupcomm]. 3.2. Security Several individual drafts analyze the issues around the security of constrained devices in constrained networks. | Draft | Most Recent | | draft-garcia-core-security | 2012-03-26 | | draft-sarikaya-core-sbootstrapping | 2011-10-31 | Figure 1 The approach favored by the latter draft is extended towards pre- shared keys (PSK, symmetric cryptography) in [I-D.ohba-core-eap-based-bootstrapping]. draft-yegin-coap-security-options-00 was more of a trial balloon to explore one approach that is not actively pursued. [I-D.hartke-core-codtls] looks specifically into the use of DTLS in constrained networks. It raises issues that pertain both to the LWIG and CoRE working groups of the IETF. 3.3. Intermediaries [I-D.castellani-core-http-mapping] discusses some ideas about what HTTP/CoAP intermediaries could do beyond the basic mapping defined in [I-D.ietf-core-coap]. ([I-D.moritz-core-proxy-encode] is one proposal to add an option to influence the behavior of such intermediaries.) Bormann Expires September 28, 2012 [Page 8] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 4. CoAP over X [I-D.becker-core-coap-sms-gprs] shows how to run CoAP over cellular SMS and in mixed SMS/GPRS environments. [I-D.hartke-core-coap-xmpp] discusses interfacing to XMPP (colloquially known as the Jabber protocol). Bormann Expires September 28, 2012 [Page 9] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 5. Optional components of CoRE Additional sub-protocols are being discussed in the IETF that may become optional protocols in CoREs. This document will track these sub-protocols and be amended once the sub-protocols reach formal status in the IETF. Since the WG is cautious in adopting additional work while the main specifications near completion, none of the additional protocols proposed have become WG documents yet. 5.1. CoAP-misc One draft is a little different from the other drafts in this category: [I-D.bormann-coap-misc] is a running document capturing CoAP extensions that are in various states of being cooked. Some of these extensions may finally be adopted for the WG documents and then vanish from CoAP-misc. For other extensions, we may decide that they are not very good ideas. Instead of deleting them from CoAP-misc, they are moved to an appendix. This documents the approach, the best implementation of that approach that was reached, and the reasons why it was not adopted. This documentation should spare the WG and its contributors from the continuous reinvention of bad ideas. Small extensions documented in CoAP-misc that might become part of the WG documents soon and that are not mentioned elsewhere, currently include: o vendor-specific option (Section 3) 5.2. Patience, Leisure, Pledge, or: Timing extensions Several proposals intend to extend the amount of information available during an exchange about the timing requirements of the participants. +------------------------------------+-------------+ | Draft | Most Recent | +------------------------------------+-------------+ | draft-li-core-coap-patience-option | 2012-02-27 | +------------------------------------+-------------+ Another discussion is in Section 4 of [I-D.bormann-coap-misc]. Bormann Expires September 28, 2012 [Page 10] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 5.3. Extending Observe Observe, as defined, attempts to achieve eventual consistency only ("data retrieval"). In other words, not every intermediate state of a resource is guaranteed to be captured by a client ("data monitoring"). [I-D.loreto-core-coap-streaming] appears to be extending Observe towards data monitoring, in this case for e.g. streaming camera data. Observe is not trying to create another one of those complex publish- subscribe architectures, CoAP effectively provides a minimal enhancement to the REST model: just adding the well-known Observer pattern. The server is in total control of when the updates are sent. Several proposals have been made to provide more control to the client. Obviously, the URI can be used to relay specific information such as thresholds and time spans. A proposal to add CoAP options for this is: +-----------------------------------+-------------+ | Draft | Most Recent | +-----------------------------------+-------------+ | draft-li-core-conditional-observe | 2012-03-12 | +-----------------------------------+-------------+ 5.4. Service discovery Basic service discovery is defined in [I-D.ietf-core-link-format]. A JSON representation of the same information is defined in [I-D.bormann-core-links-json]. The intention is to make this information available in an equivalent format that is more accessible to classic Web servers, both as a file format (Internet media type) and as a format that can be used in e.g. a JavaScript API. [I-D.shelby-core-interfaces] provides additional semantics that can be used to make resource descriptions more directly machine- interpretable. This ties in to a more general discussion about CoRE profiles that has only just begun. [I-D.arkko-core-dev-urn] defines a new Uniform Resource Name (URN) namespace that can be used to provide hardware device identifiers in resource descriptions. Bormann Expires September 28, 2012 [Page 11] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 5.5. Server discovery, Naming, etc. On the boundary between service and server discovery, resource directory servers provide a way to collect resource descriptions from multiple servers into one accessible location. [I-D.bormann-core-simple-server-discovery] provides a basic way to discover such servers in a constrained node/network without necessarily having to resort to multicast. [I-D.shelby-core-resource-directory] defines protocol elements that can be used for setting up such a resource directory. [I-D.nieminen-core-service-discovery] extends this discussion towards Constrained Application Autoconfiguration. Additional drafts include: +-------------------------------+-------------+ | Draft | Most Recent | +-------------------------------+-------------+ | draft-ma-core-dhcp-pd | 2012-03-12 | | | | | draft-cao-core-pd | 2012-03-12 | | | | | draft-he-core-energy-aware-pd | 2011-10-24 | +-------------------------------+-------------+ An attempt to merge mDNS/DNS-SD-based discovery (colloquially known as zeroconf or Bonjour), including recent approaches to extend these for constrained networks, into the picture is documented in [I-D.vanderstok-core-dna]. 5.6. More support for sleepy nodes The basic communication model of CoAP was imported from the Web. This applies well to some communication requirements in constrained node/ networks, but leaves some other requirements open. A number of drafts aim to extend the CoAP communication model towards more support for sleepy nodes. Bormann Expires September 28, 2012 [Page 12] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 +--------------------------------------------+-------------+ | Draft | Most Recent | +--------------------------------------------+-------------+ | draft-vial-core-mirror-proxy | 2012-03-02 | | | | | draft-giacomin-core-sleepy-option | 2012-02-29 | | | | | draft-fossati-core-publish-monitor-options | 2012-03-10 | +--------------------------------------------+-------------+ Bormann Expires September 28, 2012 [Page 13] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 6. Replaced drafts Internet-Drafts often get replaced by merged drafts or get promoted to WG drafts. As the relationships between drafts are not always accurately captured by the secretariat tools, this table provides a mapping from current drafts to any previous drafts they are replacing: +---------------------------------+--------------------------------+ | current draft | replaced draft | +---------------------------------+--------------------------------+ | [I-D.ietf-core-coap] | draft-shelby-core-coap | | | | | [I-D.ietf-core-block] | draft-bormann-core-coap-block | | | | | | draft-li-core-coap-size-option | | | | | [I-D.ietf-core-observe] | draft-hartke-coap-observe | | | | | [I-D.ietf-core-link-format] | draft-shelby-core-link-format | | | | | [I-D.ietf-core-groupcomm] | draft-rahman-core-groupcomm | | | | | | draft-dijk-core-groupcomm-misc | | | | | [I-D.becker-core-coap-sms-gprs] | draft-li-core-coap-over-sms | | | | | [I-D.vanderstok-core-dna] | draft-vanderstok-core-bc | +---------------------------------+--------------------------------+ Note that draft-scim-core-schema is just named against the naming conventions and actually unrelated to the CoRE working group. Bormann Expires September 28, 2012 [Page 14] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 7. IANA Considerations This document has no actions for IANA. Bormann Expires September 28, 2012 [Page 15] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 8. Security Considerations (None so far; this section will certainly grow as additional security considerations beyond those listed in the base specifications become known.) Bormann Expires September 28, 2012 [Page 16] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 9. Acknowledgements (The concept for this document is borrowed from [RFC4815], which was invented by Lars-Erik Jonsson. Thanks!) Bormann Expires September 28, 2012 [Page 17] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 10. References 10.1. Normative References [I-D.ietf-core-block] Bormann, C. and Z. Shelby, "Blockwise transfers in CoAP", draft-ietf-core-block-08 (work in progress), February 2012. [I-D.ietf-core-coap] Shelby, Z., Hartke, K., Bormann, C., and B. Frank, "Constrained Application Protocol (CoAP)", draft-ietf-core-coap-09 (work in progress), March 2012. [I-D.ietf-core-link-format] Shelby, Z., "CoRE Link Format", draft-ietf-core-link-format-11 (work in progress), January 2012. [I-D.ietf-core-observe] Hartke, K., "Observing Resources in CoAP", draft-ietf-core-observe-05 (work in progress), March 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5785] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, April 2010. [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012. 10.2. Informative References [I-D.arkko-core-dev-urn] Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Names for Device Identifiers", draft-arkko-core-dev-urn-01 (work in progress), October 2011. [I-D.becker-core-coap-sms-gprs] Becker, M., Li, K., Kuladinithi, K., and T. Poetsch, "Transport of CoAP over SMS, USSD and GPRS", draft-becker-core-coap-sms-gprs-01 (work in progress), March 2012. [I-D.bormann-coap-misc] Bormann, C. and K. Hartke, "Miscellaneous additions to Bormann Expires September 28, 2012 [Page 18] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 CoAP", draft-bormann-coap-misc-13 (work in progress), March 2012. [I-D.bormann-core-links-json] Bormann, C., "Representing CoRE Link Collections in JSON", draft-bormann-core-links-json-00 (work in progress), February 2012. [I-D.bormann-core-simple-server-discovery] Bormann, C., "CoRE Simple Server Discovery", draft-bormann-core-simple-server-discovery-01 (work in progress), March 2012. [I-D.bormann-lwig-guidance] Bormann, C., "Guidance for Light-Weight Implementations of the Internet Protocol Suite", draft-bormann-lwig-guidance-01 (work in progress), January 2012. [I-D.castellani-core-http-mapping] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and E. Dijk, "Best practices for HTTP-CoAP mapping implementation", draft-castellani-core-http-mapping-03 (work in progress), March 2012. [I-D.hartke-core-coap-xmpp] Hartke, K., "A CoAP REST API for XMPP Publish-Subscribe", draft-hartke-core-coap-xmpp-00 (work in progress), January 2012. [I-D.hartke-core-codtls] Hartke, K. and O. Bergmann, "Datagram Transport Layer Security in Constrained Environments", draft-hartke-core-codtls-01 (work in progress), March 2012. [I-D.ietf-core-groupcomm] Rahman, A. and E. Dijk, "Group Communication for CoAP", draft-ietf-core-groupcomm-01 (work in progress), March 2012. [I-D.loreto-core-coap-streaming] Loreto, S. and O. Novo, "CoAP Streaming", draft-loreto-core-coap-streaming-00 (work in progress), March 2012. [I-D.moritz-core-proxy-encode] Moritz, G., "CoAP Proxy Encode-To Option", Bormann Expires September 28, 2012 [Page 19] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 draft-moritz-core-proxy-encode-00 (work in progress), January 2012. [I-D.nieminen-core-service-discovery] Nieminen, J., Patil, B., Savolainen, T., Isomaki, M., Shelby, Z., Gomez, C., and M. Ersue, "Constrained Application Autoconfiguration", draft-nieminen-core-service-discovery-02 (work in progress), March 2012. [I-D.ohba-core-eap-based-bootstrapping] Das, S. and Y. Ohba, "Provisioning Credentials for CoAP Applications using EAP", draft-ohba-core-eap-based-bootstrapping-01 (work in progress), March 2012. [I-D.shelby-core-interfaces] Shelby, Z. and M. Vial, "CoRE Interfaces", draft-shelby-core-interfaces-02 (work in progress), March 2012. [I-D.shelby-core-resource-directory] Krco, S. and Z. Shelby, "CoRE Resource Directory", draft-shelby-core-resource-directory-02 (work in progress), October 2011. [I-D.vanderstok-core-dna] Stok, P., Lynn, K., and A. Brandt, "CoRE Discovery, Naming, and Addressing", draft-vanderstok-core-dna-01 (work in progress), March 2012. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000. [RFC2418] Bradner, S., "IETF Working Group Guidelines and Procedures", BCP 25, RFC 2418, September 1998. [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. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and Clarifications to RFC 3095", RFC 4815, February 2007. [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 Bormann Expires September 28, 2012 [Page 20] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, August 2007. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC6202] 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", RFC 6202, April 2011. [SB] Bormann, C., Castellani, A., and Z. Shelby, "CoAP: An Application Protocol for Billions of Tiny Internet Nodes", DOI 10.1109/MIC.2012.29, 2012. [WEI] Shelby, Z. and C. Bormann, "6LoWPAN: the Wireless Embedded Internet", ISBN 9780470747995, 2009. Bormann Expires September 28, 2012 [Page 21] Internet-Draft CoRE Roadmap and Implementation Guide March 2012 Author's Address Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63921 Fax: +49-421-218-7000 Email: cabo@tzi.org Bormann Expires September 28, 2012 [Page 22]