Re: [core] Comments and questions on draft-jarvinen-core-fasor-02

[Carsten Bormann <[e-mail]>]

> On Nov 20, 2019, at 14:03, Christer Holmberg <[e-mail]> wrote:
> 
> Hi,
> 
>>> - Does CoAP allow changing option values in retransmissions? 
>> 
>> Yes, it actually encourages that, e.g.:
>> 
>>   The value is intended to be current at the time of transmission.
>>   Servers that provide resources with strict tolerances on the value of
>>   Max-Age SHOULD update the value before each retransmission.[…]
>> 
>> https://tools.ietf.org/html/rfc7252#section-5.10.5
> 
>   So, that means that implementations will have to perform a full parse of received retransmissions, instead of only parsing enough in order to detect a retransmission?

I don’t think that is the intention.
If the message-id of a received message is the same as the one the server just processed, just discard.
(On the other hand, for safe, idempotent methods, the server might well decide to indeed process the request again instead of de-duplicating it.)

(And I hope nobody tries this trick with non-safe methods.  Please make three coffees. <timeout waiting for ack>.  Please make two coffees.)

> In addition, if a retransmission contains updated information, retransmissions will have to be exposed to the application, rather than being handled by the protocol stack.

Right.  That is not the intention.

>> (The interesting part here is eventual consistency — you can’t be sure that the acknowledgement you get is actually for the most recent retransmission.)
> 
>    Retransmissions can also be received out of order, and if they contain different information the receiver may not necessarily know which is the most recent.

Indeed.  The problem with max-age is, of course, that the receiver (here: the client) does not know how long the packet needed to transit the network, so reordering does not really add to that ambiguity.

Grüße, Carsten