Constrained RESTful Environments

The information below is for an older approved charter
Document Charter Constrained RESTful Environments WG (core) Snapshot
Title Constrained RESTful Environments
Last updated 2010-03-09
State Approved
WG State Active
IESG Responsible AD Alexey Melnikov
Charter Edit AD (None)
Send notices to (None)


CoRE is providing a framework for resource-oriented applications
  intended to run on constrained IP networks. A constrained IP network
  has limited packet sizes, may exhibit a high degree of packet loss, and
  may have a substantial number of devices that may be powered off at any
  point in time but periodically "wake up" for brief periods of time.
  These networks and the nodes within them are characterized by severe
  limits on throughput, available power, and particularly on the
  complexity that can be supported with limited code size and limited RAM
  per node. More generally, we speak of constrained networks whenever at
  least some of the nodes and networks involved exhibit these
  characteristics. Low-Power Wireless Personal Area Networks (LoWPANs)
  are an example of this type of network. Constrained networks can occur
  as part of home and building automation, energy management, and the
  Internet of Things.
  The CoRE working group will define a framework for a limited class of
  applications: those that deal with the manipulation of simple resources
  on constrained networks. This includes applications to monitor simple
  sensors (e.g. temperature sensors, light switches, and power meters), to
  control actuators (e.g. light switches, heating controllers, and door
  locks), and to manage devices.
  The general architecture consists of nodes on the constrained network,
  called Devices, that are responsible for one or more Resources that may
  represent sensors, actuators, combinations of values or other
  information. Devices send messages to change and query resources on
  other Devices. Devices can send notifications about changed resource
  values to Devices that have subscribed to receive notification about
  changes. A Device can also publish or be queried about its
  resources. (Typically a single physical host on the network would have
  just one Device but a host might represent multiple logical Devices.
  The specific terminology to be used here is to be decided by the WG.)
  As part of the framework for building these applications, the WG will
  define a Constrained Application Protocol (CoAP) for the manipulation of
  Resources on a Device.
  CoAP will be designed for use between Devices on the same constrained
  network, between Devices and general nodes on the Internet, and between
  Devices on different constrained networks both joined by an
  internet. CoAP targets the type of operating environments defined in the
  ROLL and 6LOWPAN working groups which have additional constraints
  compared to normal IP networks, but the CoAP protocol will also operate
  over traditional IP networks.
  There also may be proxies that interconnect between other Internet
  protocols and the Devices using the CoAP protocol. The WG will define a
  mapping from CoAP to an HTTP REST API; this mapping will not depend on a
  specific application. It is worth noting that proxy does not have to
  occur at the boundary between the constrained network and the more
  general network, but can be deployed at various locations in the
  unconstrained network.
  CoAP will support various forms of "caching". For example, if a
  temperature sensor is normally asleep but wakes up every five minutes
  and sends the current temperature to a proxy that has subscribed, when
  the proxy receives a request over HTTP for that temperature resource, it
  can respond with the last seen value instead of trying to query the
  Device which is currently asleep.
  The initial work item of the WG is to define a protocol specification
  for CoAP that includes:
  1) The ability to create, read, update and delete a Resource on a
  2) The ability to allow a Device to publish a value or event to another
  Device that has subscribed to be notified of changes, as well as the
  way for a Device to subscribe to receive publishes from another
  3) The ability to support a non-reliable multicast message to be sent to
  a group of Devices to manipulate a resource on all the Devices in the
  4) The core CoAP functionality MUST operate well over UDP and UDP MUST
  be implemented on CoAP Devices. There may be OPTIONAL functions in
  CoAP (e.g. delivery of larger chunks of data) which if implemented are
  implemented over TCP. Applications which require the optional TCP
  features will limit themselves to a narrower subset of deployment
  5) A definition of how to use CoAP to advertise about or query for a
  Device's description. This description may include the device name and
  a list of its Resources, each with a URL, an interface description URI
  (pointing e.g. to a Web Application Description Language (WADL)
  document) and an optional name or identifier. The name taxonomy used
  for this description will be consistent with other IETF work,
  e.g. draft-cheshire-dnsext-dns-sd.
  6) Specification for the HTTP REST based API and translation to
  communicate with Devices. Translation should make use of Device
  description information and should not need code updates to deal with
  new Devices.
  7) Consider operational and manageability aspects of the protocol and at
  a minimum provide a way to tell if a Device is powered on or not.
  The working group will not develop a reliable multicast solution, and
  will not develop a general service discovery solution. There is a desire
  for discovery and configuration features, but the working group has not
  yet closed in on an specific approach. Thus, the WG may explore these
  topics and adopt drafts that define requirements or set problem
  statements, but will not adopt implementable specifications without a
  Security, particularly keying of new Devices, is very challenging for
  these applications. The WG will work to select approaches to security
  bootstrapping which are realistic given the constraints and requirements
  of the network. To ensure that any two nodes can join together, all
  nodes must implement at least one universal bootstrapping method.
  Security can be achieved using either session security or object
  security. For both object and session security, the WG will work with
  the security area to select appropriate security framework and protocol
  as well as selecting a minimal required to implement cipher suite. CoAP
  will initially look at CMS (RFC 5652), TLS/DTLS, and EAP.
  The WG will coordinate on requirements from many organizations including
  OpenSG/NIST, ZigBee/HomePlug, IPSO Alliance, OASIS, SENSEI,
  ASHRAE/BACnet; other SDOs and organizations. The WG will closely
  coordinate with other IETF WGs including ROLL, 6LoWPAN, and appropriate
  groups in the IETF OPS and Security areas.