Entities receiving a &xep0203; marked are unable to determine if the delay is missing because the stanza was not delayed or because the service does not add delay. This is due a missing service disco possiblity for 203 with the according semantics.

Furthermore xep203 appears to be designed to avoid an timestamp in case there is no delay. However this can be considered a premature and unnecessary optimization which causes confusion (see for example https://medium.com/miquido/successful-migration-to-a-custom-xmpp-solution-76fcdecb0928).

Extension element is added by entities. The 'stamp' attributes contians the timestamp when the entity received the stanza. A missing 'by' attribute determines the timestamp when the orignating entity send the message.

1. Stanza timestamp generating entities, which encounter a &time-stamp; element where the 'by' attribute matches the 'by' attribute they would otherwise set, MUST ovverride that element.
2. Entities, which are routing stanzas, SHOULD NOT strip any elements qualified by the 'urn:xmpp:stanza-timestamps:0' namespace from stanzas unless.
3. Stanzas MUST possess, in the direct child level of the stanza, at most one &time-stamp; extension element with the same XMPP address as value of the 'by' attribute.
4. The value of the 'by' attribute MUST be the XMPP address of the entity adding the timestap of the element. Note that XMPP addresses are normalized as defined in &rfc6122;. TODO update RFC reference.

An entity that follows the buisness rules and adds timestamps to its stanzas SHOULD announce the 'urn:xmpp:stanza-timestamps:0' namespace in its disco features.

Avoid address leaks of originating entities. Entites should verify the timestap by checking if the entity whose address is found in the 'by' attribute announces the according XEP-0030 feature.

This document requires no interaction with &IANA;.

REQUIRED for protocol specifications.

Thanks to Kim Alvefur.