Subject: [core] Fwd: New Version Notification for draft-ietf-core-coap-03

From: Zach Shelby <[email-masked]>
Date: Tue, 26 Oct 2010 02:02:04 +0300

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

Here is the new version of CoAP, now even with a complete (draft) of the security section thanks to Cullen and Carsten. This now closes all open tickets and issues I could dredge out of the mailing list. As this version did not change the base header, and option type numbers are the same, we have kept the same version number in the header. This should be a fairly easy upgrade for existing implementations (Token Option for asynchronous responses, new CoAP specific error codes, Uri-Query option). And yes, we will test coap-03 at the plugfest in Beijing.

Here is a summary of changes:

   Changes from ietf-02 to ietf-03:

      o Token Option and related use in asynchronous requests added
      (#25).

      o CoAP specific error codes added (#26).

      o Erroring out on unknown critical options changed to a MUST
      (#27).

      o Uri-Query option added.

      o Terminology and definitions of URIs improved.

      o Security section completed (#22).

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: October 26, 2010 1:54:48 AM GMT+03:00
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for draft-ietf-core-coap-03 
> 
> 
> A new version of I-D, draft-ietf-core-coap-03.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
> 
> Filename:	 draft-ietf-core-coap
> Revision:	 03
> Title:		 Constrained Application Protocol (CoAP)
> Creation_date:	 2010-10-26
> WG ID:		 core
> Number_of_pages: 39
> 
> Abstract:
> This document specifies the Constrained Application Protocol (CoAP),
> a specialized web transfer protocol for use with constrained networks
> and nodes for machine-to-machine applications such as smart energy
> and building automation.  These constrained nodes often have 8-bit
> microcontrollers with small amounts of ROM and RAM, while networks
> such as 6LoWPAN often have high packet error rates and a typical
> throughput of 10s of kbit/s.  CoAP provides a method/response
> interaction model between application end-points, supports built-in
> resource discovery, and includes key web concepts such as URIs and
> content-types.  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.
> 
> 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org  - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297

---

From: "Mohana Jeyatharan" <[email-masked]>
Date: Thu, 28 Oct 2010 17:29:37 +0800

Hi Zach,

I have a few comments and questions on the new version of CoAP draft.

[1]In page 7 the token option is used (this is new).  In fact for the
asynchronous transaction section2.1.2
why the token option is used? The transaction ID is changed when the
server sends delayed response. But the URI authority option would
suffice. Why an additional token option?
The client will be able to identify the transaction from the URI
authority option. I really don't understand the need of this token
option.
Unless we are assuming multiple connections to get resource state of the
same resource from the same client. I guess we are not going to open
multiple connections in such constrained environment?

[2]In section 2.3, the error code for "method not allowed" should be
165. This is just editorial.

[3]Is the URI scheme option completely removed from this version
(version 3 coap draft). I don't see it in table 2 option header.
I guess the only scheme is coap://. I assume this is carried in the
scheme option and I was unable to find a description of this scheme
option.
In the earlier version (version 2) there was an http scheme value
present. Why was this removed? If the client wants to talk to an end
device that is running HTTP, then it is easier for the 
Proxy to do the CoAP to HTTP mapping. This was my understanding of the
"HTTP://" value in coap scheme option. 

[4]Deltas are used to identify the option type.  Just a clarification
question.  Why such deltas are used? Why not just have the option type
instead. It makes the processing easier for the devices.

[5] Section 3.2.5: what is the use of location option. It looks the same
as the URI-Path option?

[6] In section 4.4 it is mentioned that default UDP port is used for
resource discovery.  So does this mean that after resource discovery
another UDP port for CoAP will be received from the end device.  Does
resource discovery return UDP port number? Why not use the default UDP
port always for CoAP?

[7] In section 5.3, when the proxy is unable to get the resource value
from origin server it is mentioned that it will send 502 Bad gateway
error. I guess this is fine if the client is a HTTP entity. But if the
client is a CoAP node then the proxy should send an ACK as in the
asynchronous model and then when resource is ready will probably send
the actual resource value.  I am unable to understand why a gateway
error is sent. Am I missing something.

[8] The other question is, what type of proxy are we considering. I mean
when a device sends a message to get or manipulate resource tied to
another device (origin server), it will set the IP address to Proxy IP
address (non-transparent proxy).  I assume that only such proxies are
considered in the draft.  Then in that case in section 10.3.2 why is
Ipsec a problem.  Because the device will use the proxy as the end node.
I am not very clear on the assumption of the proxies here. Are we
considering transparent proxies also?

BR,
Mohana

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Zach Shelby
> Sent: Tuesday, October 26, 2010 7:02 AM
> To: core
> Subject: [core] Fwd: New Version Notification for
draft-ietf-core-coap-03
> Here is the new version of CoAP, now even with a complete (draft) of
the
> security section thanks to Cullen and Carsten. This now closes all
open tickets
> and issues I could dredge out of the mailing list. As this version did
not
> change the base header, and option type numbers are the same, we have
> kept the same version number in the header. This should be a fairly
easy
> upgrade for existing implementations (Token Option for asynchronous
> responses, new CoAP specific error codes, Uri-Query option). And yes,
we
> will test coap-03 at the plugfest in Beijing.
> 
> > A new version of I-D, draft-ietf-core-coap-03.txt has been
successfully
> submitted by Zach Shelby and posted to the IETF repository.
> >
a
> > specialized web transfer protocol for use with constrained networks
and
> > building automation.  These constrained nodes often have 8-bit