Subject: Re: [core] #148: Explain that message sizes should be chosen consciously

From: "core issue tracker" <[email-masked]>
Date: Tue, 05 Jul 2011 11:22:05 -0000

#148: Explain that message sizes should be chosen consciously

Changes (by zach@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Done, new section added to coap-07.

-- 
--------------------------------+-------------------------------------------
 Reporter:  cabo@…              |        Owner:  cabo@…      
     Type:  editorial           |       Status:  closed      
 Priority:  minor               |    Milestone:              
Component:  coap                |      Version:              
 Severity:  Active WG Document  |   Resolution:  fixed       
 Keywords:                      |  
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/148#comment:1>
core <http://tools.ietf.org/core/>

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 5 Jul 2011 13:52:53 +0200

Dear authors,

core-block-03 "overloads" the meaning of the 4.13 error response code (Request Entity Too Large). I see here an interoperability problem if different implementers attribute different meanings to the 4.13 response.

With the overloaded meaning of 4.13 I mean: "The error code 4.13 (Request Entity Too Large) can be returned at any time by a server that does not currently have the resources to store blocks for a block-wise request payload transfer that it would intend to implement in an atomic fashion."

The original meaning of 4.13 (payload truncated) from coap-06 still holds because block-03 does not revoke it. So if a client sends a first request with Block Option, and the packet is truncated at the server side due to a too-large packet, the server responds 4.13. But now the client may interpret (per block-03) this response as "the server doesn't have resources to store blocks" even though that is not the case. This is a clear case where client implementers may assume different meanings of a 4.13.

One solution may be to point out in the block-03 text that a 4.13 response to a request with Block Option may mean either "truncated" or "do not have resources for blockwise", not necessarily the latter only. Another solution is to define that a 4.13 for a first block means "truncated", while for a second block it means "do not have resources".

best regards,
Esko

Esko Dijk

Philips Corporate Technologies, Research
High Tech Campus 34, Eindhoven, The Netherlands
[email-masked]

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.