Relaxed the business rules to allow inclusion of receipt requests even to the bare JID and even if the sender does not yet know if the intended recipient supports this protocol.
The following business rules apply:
A sender SHOULD NOT include a request for message receipts when sending a message to the bare JID &LOCALBARE; of the recipient, only when sending to a full JID &LOCALFULL;.
A sender SHOULD NOT include a request for message receipts unless it knows (via &xep0030; or &xep0115;) that the intended recipient supports the protocol described herein or unless the use of message receipts is negotiated via &xep0155;.
A sender SHOULD include an 'id' attribute on the message so that the sender can properly track the receipt.
If receipts are desired, a sender SHOULD include a request for message receipts on all messages, no matter whether sending to the bare JID &LOCALBARE; of the recipient or the full JID &LOCALFULL;.
A sender MUST include an 'id' attribute on the message so that the sender can properly track the receipt.
Naturally, message receipts can be combined with the rules specified in Advanced Message Processing (e.g., the deliver rule) for more complete reporting.
If a sender wishes to request message receipts, it SHOULD first determine whether the intended recipient supports message receipts. This can be done directly via Service Discovery or indirectly via Entity Capabilities.
If an entity supports message receipts, it MUST report that by including a service discovery feature of "urn:xmpp:receipts" in response to disco#info requests:
A sender MAY include a request for message receipts even if it has not been able to determine if the intended recipient supports message receipts. This can be done directly via Service Discovery or indirectly via Entity Capabilities.
Two entities MAY negotiate the use of message receipts for a given session using Stanza Session Negotiation. The parameter to be negotiated is named "urn:xmpp:receipts". Its use is illustrated in the following examples.