Re: [6lowapp] Next rev of CoRE Charter

[Behcet Sarikaya <[e-mail]>]

Hi Cullen,
  I have a few minor corrections on the charter:



----- Original Message ----
> From: Cullen Jennings <[e-mail]>
> To: [e-mail]
> Sent: Sat, January 30, 2010 12:16:14 PM
> Subject: [6lowapp] Next rev of CoRE Charter
> 
> CoRE (Constrained RESTful Environments)
> 
> 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. LoWPANs are 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

> description. 

resources.

>Typically a single physical host on the network would have
> just one Device but a host may represent multiple logical Devices. 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 translators 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 translation 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 translator that has subscribed,
> when the translator 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
>   Device.
> 
> 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
>   Device.
> 
> 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 .
              ^

add : in the group


> 
> 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
>   cases.
> 
> 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 

>WADL
Web Application Description Language (WADL)


> document) and an optional
>   name. The name taxonomy used for this description will be consistent
>   with other IETF work, e.g. 

>draft-cheshire-dnsext-dns-sd.

This document expired years ago?

Regards,

Behcet