Subject: Re: [core] #132: Separate response implicitly acks confirmable request

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 May 2011 09:14:23 -0700

Do you MAY stop or SHOULD stop or MUST stop ?

On Mar 29, 2011, at 10:30 , core issue tracker wrote:

> #132: Separate response implicitly acks confirmable request
> 
> Implementation note: When a client receives a separate response (CON) but
> hasn't received an ACK for the confirmable request yet, then the client
> can stop retransmitting the request.
> 
> -- 
> --------------------------------+-------------------------------------------
> Reporter:  hartke@…            |       Owner:     
>     Type:  editorial           |      Status:  new
> Priority:  minor               |   Milestone:     
> Component:  coap                |     Version:     
> Severity:  Active WG Document  |    Keywords:     
> --------------------------------+-------------------------------------------
> 
> Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/132>
> core <http://tools.ietf.org/core/>
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 9 May 2011 21:30:05 +0200

> Do you MAY stop or SHOULD stop or MUST stop ?

MAY.

4.1 now ends with:

   Implementation notes: Note that a CoAP end-point that sent a
   confirmable message MAY give up in attempting to obtain an ACK even
   before the MAX_RETRANSMIT counter value is reached: E.g., the
   application has canceled the request as it no longer needs a
   response, or there is some other indication that the CON message did
   arrive.  In particular, a CoAP request message may have elicited a
   separate response, in which case it is clear to the requester that
   only the ACK was lost and a retransmission of the request would serve
   no purpose.  However, a responder MUST NOT in turn rely on this
   cross-layer behavior from a requester, i.e. it SHOULD retain the
   state to create the ACK for the request, if needed, even if a
   confirmable response was already acknowledged by the requester.

Do you think there is a reason for SHOULD/MUST?
I think that would create too much imposition on the implementation for little gain.

Gruesse, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 9 May 2011 12:31:57 -0700

That looks fine to me. Key thing I was worried about was that devices don't rely on this cross layer behavior. 

Cullen Jennings