ietf-wg-mimi / draft-ietf-mimi-content

6 stars 5 forks source link

Sender timestamp in delivery reports #28

Open mar-v-in opened 3 weeks ago

mar-v-in commented 3 weeks ago

Regular messages don't have a sender timestamp (but rather the lastSeen that is up for removal via #27) and rely on the hub received timestamp instead. However, delivery reports currently do have a sender timestamp. As the hub will tag delivery reports the same way as regular messages (because it doesn't even know if it's a regular message or delivery report), it only makes sense to be consistent with the two.

That said, I do see potentially valid usecases for having a sender timestamp, knowing that it can be spoofed: When sending a message on a mobile device with spotty connectivity, the sending client might be unable to deliver the message to the server when the user intends it. Thus indicating a desired sending time might still be beneficial. To avoid confusion, it likely should not be used for message ordering, but could be displayed with a message if there was no room activity between sender timestamp and hub timestamp or could be used just to indicate that the message was seemingly delivered out of order or with significant delay.