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

[David Ryan <[e-mail]>]

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.


On Tue, Mar 2, 2010 at 8:30 AM, Zach Shelby <[e-mail]> wrote:
> 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 <[e-mail]>
>> Date: March 1, 2010 23:24:35 GMT+02:00
>> To: [e-mail]
>> Cc: [e-mail]
>> 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: [phone]
>
> 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.
>
>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>