Re: [core] COAP basic implementation.

[Zach Shelby <[e-mail]>]

Awesome David, nice work! We are also working on a couple implementations in the SENSEI project. 

On Mar 24, 2010, at 4:16 , David Ryan wrote:

> 
> One of the questions that came up during implementation was what is a
> malformed request?  How does the server tell and under what situations
> should an error response be sent?  

These need to be defined, contribs welcome. 

> Also, should a request have to come
> from a client using the COAP port, or should the server send responses
> to the client port that sent it?

The latter. 

Zach

> 
> You can find the download under Colony COAP near the bottom of
> http://www.einet.com.au/Downloads
> 
> Comments and feedback appreciated.
> 
> Regards,
> David.
> 
> 
> On Fri, Mar 19, 2010 at 10:01 AM, David Ryan <[e-mail]> wrote:
>> 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
>>> 
>> 

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