Subject: [core] Fwd: New Version Notification for draft-shelby-core-coap-00

From: Zach Shelby <[email-masked]>
Date: Mon, 1 Mar 2010 23:30:11 +0200

http://www.ietf.org/id/draft-shelby-core-coap-00.txt

Here is a very early draft of a CoAP protocol specification based on the requirements and initial ideas formulated in draft-shelby-core-coap-req-00 and the previous work by Brian in draft-frank-6lowapp-chopan. Looking forward to lots of good discussion around CoAP, and as you can see from all the TODOs and TBDs - lots of WG stuff to do here! 

At the same time I'd like to request a time-slot to present this in Anaheim.

Zach

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: March 1, 2010 23:24:35 GMT+02:00
> To: [email-masked]
> Cc: [email-masked]
> Subject: New Version Notification for draft-shelby-core-coap-00 
> 
> 
> A new version of I-D, draft-shelby-core-coap-00.txt has been successfuly submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-shelby-core-coap
> Revision:	 00
> Title:		 Constrained Application Protocol (CoAP)
> Creation_date:	 2010-03-01
> WG ID:		 Independent Submission
> Number_of_pages: 17
> 
> Abstract:
> This document specifies the Constrained Application Protocol (CoAP),
> a RESTful protocol for use with constrained networks and nodes.  CoAP
> easily translates to HTTP for integration with the web while meeting
> specialized requirements such as multicast support, very low overhead
> and simplicity for constrained environments.
> 
> 
> 
> The IETF Secretariat.
> 
> 

-- 
http://www.sensinode.com
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - New book - "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

This e-mail and all attached material are confidential and may contain legally privileged information. If you are not the intended recipient, please contact the sender and delete the e-mail from your system without producing, distributing or retaining copies thereof.

---

From: "Adriano Pezzuto (apezzuto)" <[email-masked]>
Date: Tue, 2 Mar 2010 23:47:52 +0100

Hello Zach,

may be useful to have also an explicit SUBSCRIBE method in addition to the other methods listed in section 3.1. The SUBSCRIBE and NOTIFY methods can be used in combination for asynch data notification. The SUBSCRIBE request header will include the URI for the further NOTIFY requests to subscribing node and other some useful info.

An example may help (please, consider this only as an example: details can be tuned).

Let to have a source CoAP node having a light sensor and a target CoAP node having a dimmer for awnings. The source node is controlling the awnings on the target node when the light sun is too heavy (a threshold is defined on the light sensor that triggers ON/OFF commands to the dimmer).
The source node has a read-only resource addressed by the URI coap://source-node/light-sensor while the target node has a read-write resource addressed by coap://target-node/awnings-dimmer. 

Source <---------------------- CoAP ----------------------> Target

                                <-                  SUBSCRIBE Request CoAP/1.0
                                                    URI coap://source-node/light-sensor
                                                    Request header: /target-node/awnings-dimmer
                                                    Request header: threshold for light-sensor
CoAP/1.0 202 (Accepted)         ->
Response header: /source-node/light-sensor
....
the threshold on light-sensor is set 
....
light-sensor threshold is crossed triggering a data notification
....

NOTIFY Request CoAP/1.0         ->
URI coap://target-node/awnings-dimmer
Entity body: 'DIMMER ON' command

                                 <-                  CoAP/1.0 200 (OK)
                                                     ....                   
                                                     awnings-dimmer is switched ON

....................

Hope this help,
Adriano

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: lunedì 1 marzo 2010 22.30
To: 6LoWAPP; [email-masked]
Subject: [core] Fwd: New Version Notification for draft-shelby-core-coap-00

Zach

Zach Shelby
Head of Research
Sensinode Ltd.
Kidekuja 2
88610 Vuokatti, FINLAND

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 2 Mar 2010 17:50:03 -0500

Looking at the message flow, you are well on your way to re-invent SIP :-) (or XMPP, for that matter).

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Mar 2010 13:38:35 +0100

:-) Looking at the draft text below, you're well on your way to 
re-invent IPv6:

"The base header may be followed by options in ICMP-style
  Type-Length-Value format.

:-)

Alex
(for some reason I am subscribed to this list, and I can't remember
  whether I've subscribed intentionally or someone else subscribed me,
  sorry.)

Le 02/03/2010 23:50, Henning Schulzrinne a écrit :
>> Source<---------------------- CoAP ---------------------->  Target
>>
>>> From: IETF I-D Submission Tool<[email-masked]>

---

From: David Ryan <[email-masked]>
Date: Fri, 19 Mar 2010 10:01:35 +1100

Hi All,

I sent the following questions and feedback to Brian and Zach who
suggested I forward this to the list for further discussion.  I won't
be at the meeting in Anaheim next week, so here's my input.

First off, a question regarding the compression of the protocol.
You've managed to compress the header into 4 bytes.  Obviously the
size of the header is going to be important.  In the priority list of
features, is this the most important?  Would another byte or two hurt?

I notice between Chopan and COAP you've dropped the magic number
headers.  This must have been a conscious decision. I would have liked
to see a one byte magic value to identify the packet or TCP stream.
This would at least give a server a chance to throw away the request
if it receives a bad message.

In regard to version.  Two bits only leaves four possible versions.
Extending this to 4 bits would at least extend this to 16 versions.
This goes back to the original point regarding size of header.

Back in 2008 I did a thought experiment on a binary REST based
protocol.  Details available at:

http://blog.livemedia.com.au/search?updated-min=2008-01-01T00%3A00%3A00%2B11%3A00&updated-max=2009-01-01T00%3A00%3A00%2B11%3A00&max-results=7

Many of the elements are not applicable to COAP, but there might be
one or two features I developed which could be worth discussing.

One element of this through experiment was to include a "slotsAvailable"
in the response.  As the "transactionid" field allows multiple
requests to be sent to a single recipient, the "slotsAvailable" in the
response allows a client to limit the number of requests sent.  I'd
suggest 4 bits in the response.  If the server can handle more than 16
requests it can return 16 in all responses.  A small device might
return 1 at all times.

Another concept I thought about was to have a bit field for protocol
features.  This may not be applicable in this case, however, something
to put on the back burner.  The idea is that a small device might only
respond to a limited set of features (or options).  A bit field can be
used to identify in the request which features are being used and in
the response what features the server can handle.

I was also surprised that the protocol doesn't include the URI path in
the main part of the header.  I must admit I'm still trying to
understand how the index based approach to URI paths will work in your
proposal.

I tried taking your proposal and combined it with a few of the above
changes and came up with the following:

Packet
  preamble/magic  (1 byte)

  version (4 bits)
  features (4 bits)

  response (1 bit)
  options (1 bit)
  asynchronous (1 bit)
  locationType (1 bit)     (0 URI location field enabled, 1 location
specified in options)
  method/slots (4 bits)  (method type in request/slots available in response)

  transactionId (16 bits)

  location (URI location if locationType 0)

  options length (8 bits - length)
  ... options ...

  payload length (variable length int)
  ...payload data...

The base header in this case is 5 bytes instead of the 4 bytes.

I also suggested that the number of options is at the start of the
options list.  This allows the server to quickly decide if the packet
can be handled and all the option list can be processed.  In a
constrained device only a selected number of options could be
processed.  This removes the need for the 0 byte end of options byte.

I have also used a variable length integer for the payload.  This is
to allow the protocol to move to TCP with larger packets.

Regards,
David.