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

From: Salvatore Loreto <[email-masked]>
Date: Thu, 01 Jul 2010 11:35:36 +0200

section 2.1.5 Transaction IDs states that the initial Transaction ID 
should be randomized and then changed for each new request/notify,
but it does not define how it should be changed. still randomized or in 
an incremental way?

/Sal

On 6/7/10 5:00 PM, Zach Shelby wrote:
> Hi,
>
> http://www.ietf.org/id/draft-ietf-core-coap-00.txt
>
> A new version of the (now working group) document for CoAP has been posted (note it became -00 again as it now has a draft-ietf name). We integrated a bunch of editorial comments, removed the TCP binding, removed the Magic Byte header and Uri-Code for now, and marked the Sub/Notify feature as Experimental while we are discussing the new design in the WG. Managed to make a doc a couple pages shorter ;-) Next step is to make WG trac tickets for all the open issues and TODOs, these we should plan to close by the next release of the doc planned for the end of June.
>
>     Changes from shelby-01 to ietf-00:
>
>        o Removed the TCP binding section, left open for the future.
>
>        o Fixed a bug in the example.
>
>        o Marked current Sub/Notify as (Experimental) while under WG
>        discussion.
>
>        o Temporarily removed the Magic Byte header as TCP is no longer
>        included as a binding.
>
>        o Removed the Uri-code Option as different URI encoding schemes
>        are being discussed.
>
>        o Changed the rel= field to desc= for resource discovery.
>
>        o Changed the maximum message size to 1024 bytes to allow for IP/
>        UDP headers.
>
>        o Made the URI slash optimization and method impotence MUSTs
>
>        o Minor editing and bug fixing.
>
>
> Begin forwarded message:
>
>    
>> From: IETF I-D Submission Tool<[email-masked]>
>> Date: June 7, 2010 5:52:00 PM GMT+03:00
>> To: [email-masked]
>> Cc: [email-masked],[email-masked]
>> Subject: New Version Notification for draft-ietf-core-coap-00
>>
>>
>> A new version of I-D, draft-ietf-core-coap-00.txt has been successfully submitted by Zach Shelby and posted to the IETF repository.
>>
>> Filename:	 draft-ietf-core-coap
>> Revision:	 00
>> Title:		 Constrained Application Protocol (CoAP)
>> Creation_date:	 2010-06-07
>> WG ID:		 core
>> Number_of_pages: 30
>>
>> Abstract:
>> This document specifies the Constrained Application Protocol (CoAP),
>> a specialized 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 typical
>> throughput of 10s of kbit/s.  CoAP provides request/reply and
>> subscribe/notify interaction models between application end-points,
>> supports built-in resource discovery, and includes key web concepts
>> such as URIs and RESTful methods.  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.
>>
>>
>>      
>    

-- 
Salvatore Loreto
www.sloreto.com

---

From: Zach Shelby <[email-masked]>
Date: Thu, 1 Jul 2010 14:05:48 +0300

Hi,

On Jul 1, 2010, at 12:35 PM, Salvatore Loreto wrote:

> section 2.1.5 Transaction IDs states that the initial Transaction ID should be randomized and then changed for each new request/notify,
> but it does not define how it should be changed. still randomized or in an incremental way?

That is up to the implementation, you could do it either way. We do need to improve the text describing how long you need to wait before re-using old IDs however...

Zach

-- 
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: Szymon <[email-masked]>
Date: Thu, 01 Jul 2010 14:24:39 +0300

> That is up to the implementation, you could do it either way. We do need to improve the text describing how long you need to wait before re-using old IDs however...

Time for re-use ID could be calculated from formula:
RESPONSE_TIMEOUT * (2 ^ MAX_RETRANSMIT - 1)

Which would make sure that during possible retransmissions there is no 
new message with same tid. In case of 1s timeout and 5 retransmissions 
it gives 31 seconds.

Szymon