Re: [core] Retransmission of non-confirmable response message upon receiving request message retranmission?

[Carsten Bormann <[e-mail]>]

> 
> Section 5 is then about the request/response 5.2.2, page 34 (top), "If a retransmitted request is received (perhaps because the original Acknowledgement was delayed), another Empty Acknowledgement is sent, and any response MUST be sent as a separate response."
> That seem to point to the same intention: retransmit the original messages (flight) as answer.
> 
> (It seems that my understanding differs from Carsten’s answer.)


   When the server chooses to use a separate response, it sends the
   Acknowledgement to the Confirmable request as an Empty message.  Once
   the server sends back an Empty Acknowledgement, it MUST NOT send back



Shelby, et al.               Standards Track                   [Page 33]
RFC 7252       The Constrained Application Protocol (CoAP)     June 2014


   the response in another Acknowledgement, even if the client
   retransmits another identical request.  If a retransmitted request is
   received (perhaps because the original Acknowledgement was delayed),
   another Empty Acknowledgement is sent, and any response MUST be sent
   as a separate response.

This means that once the server sends an empty ACK, it is committed to replying in a separate response; it can’t go back to piggybacking, even if a conveniently arriving retransmission of the request might suggest so.  It does not mean the separate response is automatically retransmitted (that has its own ACK cycle).

Grüße, Carsten