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

From: "core issue tracker" <[email-masked]>
Date: Tue, 29 Mar 2011 17:30:07 -0000

#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/>

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Tue, 29 Mar 2011 23:15:28 +0200

Thanks for opening this ticket and #133 after my comments.

About this ticket you can find useful text in Section 3.2 of coap-overhead-01

There are some other issues I pointed out during the meeting that I
attach for convenience.

You may want to address them as well in other tickets.

Best,
Angelo

#1 Do we need to point out that a timeout is needed to handle
non-piggybacked responses that never come? (server crashed in the
meantime)

#2 Some text should be added to pinpoint that very constrained
implementation require additional state to handle Token option with
non-piggybacked responses? Refer to Section 2.1 of coap-overhead-01

#3 Pipelined requests with block option could request out-of-bound
blocks, because it does not know how many blocks are remaining. Do we
need a Size as proposed in coap-size-option-00?

On Tue, Mar 29, 2011 at 19:30, core issue tracker
<[email-masked]> wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>