%ents; ]>
Message Mine-ing In servers that deliver messages intended for the bare JID to all resources, the resource that claims a conversation notifies all of the other resources of that claim. &LEGALNOTICE; 0259 Experimental Standards Track Standards Council XMPP Core XEP-0030 XEP-0045 XEP-0115 mine &hildjj; 0.1 2009-01-21 psa

Initial published version.

0.0.1 2008-10-22 jjh

First draft.

At the time of original writing of this XEP, many XMPP servers handle message stanzas sent to a user@host (or "bare") JID with no resource by delivering that message only to the resource with the highest priority for the target user. Some server implementations, however, have chosen to send these messages to all of the online resources for the target user. If the target user is online with multiple resources when the orginal message is sent, a conversation ensues on one of the user's devices; if the user subsequently switches devices, parts of the conversation may end up on the alternate device, causing the user to be confused, misled, or annoyed.

This XEP proposes an approach for cleaning up the leftover conversation shards on alternate devices, paving the way for servers to deliver messages to multiple devices. As the basic approach, the receiving server asks all of the resources of a user "whose message is this?". The first resource to say "mine!" wins.

If a server implements the Mine capability, it MUST specify the 'urn:xmpp:tmp:mine:0' feature in its service discovery information features as specified in &xep0115; or &xep0030;. Clients MUST NOT send ownership changes if their server does not support this feature.

]]> ... ... ]]>

Clients that support this protocol MUST support XEP-0115, and MUST add the 'urn:xmpp:tmp:mine:0' feature to their entity capabilities, in order to allow for potential server optimizations.

]]> ]]>

When a server that implements the Mine capability receives a message addressed to a user's bare JID, it MUST:

  • Ensure that no "whose" element is already on the message. See the Errors section for processing.
  • Add a whose element to the message, containing an id attribute with a new value
  • Ensure that the the same value of the "id" attribute is never sent to the same session

Messages that have been processed to include a valid "whose" element, are now also considered an "ownership request"

Wherefore art thou, Romeo? 0e3141cd80894871a68e6fe6b1ec56fa ]]> Wherefore art thou, Romeo? 0e3141cd80894871a68e6fe6b1ec56fa ]]>

The receiving server MUST send a copy of the ownership request to each of that user's non-negative priority resources. Each copy of the message MUST contain a whose element, each of which has the same id attribute.

Wherefore art thou, Romeo? 0e3141cd80894871a68e6fe6b1ec56fa Wherefore art thou, Romeo? 0e3141cd80894871a68e6fe6b1ec56fa Wherefore art thou, Romeo? 0e3141cd80894871a68e6fe6b1ec56fa ]]>

When one client for a receiving user detects that the user's attention has been directed to a given message, that client MUST send an ownership claim (mine!) to the bare JID of the receiving user. If there was a thread element in the original message, it MUST be included in the acceptance notification. There MUST NOT be a body element in the message, and the message SHOULD use the same message type as the ownership request. The mine element MUST include an id element for each of the messages that the client wants to accept. The mine element MUST include at least one id.

0e3141cd80894871a68e6fe6b1ec56fa 4 ]]>

As with all messages sent to a bare JID at a server implementing the Mine feature, the acceptance message MUST be forwarded to all of the non-negative priority resources.

0e3141cd80894871a68e6fe6b1ec56fa 4 0e3141cd80894871a68e6fe6b1ec56fa 4 0e3141cd80894871a68e6fe6b1ec56fa 4 ]]>

When a client receives an ownership claim that was sent from that client for an ID that has not been previously claimed, the client MUST note that the message associated with the ID has been confirmed, and ignore any further ownership claims for that ID.

When a client receives an ownership claim that was sent from a different client of the same user for a ID that has not been previously received, the client MUST note that the message associated with the ID has been retracted, and ignore any further ownership claims for that ID. Retracted messages SHOULD be removed from the client's user interface, or otherwise marked in some way as retracted.

Clients MUST ignore ownership claims for IDs for which they have no corresponding message.

Assuming that messages are delivered and processed in order, these rules should ensure that exactly one client resource has a confirmed copy of the message

The same approach that has been described for one-to-one messages above can also be used by &xep0045; (MUC) rooms. Rooms that want to participate MUST send the 'urn:xmpp:tmp:mine:0' feature in the room's disco info. The room MUST then perform the role of the server in the above descriptions, ensuring that unique ID's are assigned to all outbound groupchat messages that were addressed to the bare JID of the room. Ownership claims MUST be sent to the bare JID of the room, not the receiving user.

This capability might be used to distribute questions to multiple experts in a room, such that a single expert answers a question.

Harpier cries: 'tis time, 'tis time. ]]> Harpier cries: 'tis time, 'tis time. Harpier cries: 'tis time, 'tis time. Harpier cries: 'tis time, 'tis time. ]]> 5 ]]>

A server receives a message addressed to the bare JID of a user, from a different user than the one in the to address, containing a "whose" or "mine" element, it MUST NOT forward the message on to any clients. This case is always either an attack, a misconfiguration, or the result of bad code. If the user in the from address is already known to the user in the to address (for example, to user in the to address has a presence subscription to the user in the from address), the server MAY send back a helpful "bad-request" error.

0e3141cd80894871a68e6fe6b1ec56fa My client runneth over Yours ]]>

However, if the user in the from address is not known to the user in the to address, or the server perfers not to send helpful errors, the server MUST treat the message as if it was addressed to an unknown user. Otherwise, sending a message with an invalid "whose" or "mine" could allow an attacker to probe for valid users at a site.

The value of the id attribute sent by servers MUST be valid output from the NODEPREP profile of stringprep.

The value of the id resource is completely opqaque; receiving clients MUST NOT use any apparent order or semantic in the value of the id to perform optimizations or business logic.

Clients MUST only compare the value of ID's for equality, never for order. ID's MUST be compared for equality octet-for-octet or codepoint-for-codepoint; a basic string comparison with no extra canonicalization.

A client MAY send multiple id elements in an accceptance. Clients that receive a notification with multiple IDs MUST process each ID individually, as if multiple claims had been sent.

To avoid race conditions and edge cases (including invisibility), if both the client and server support the Mine capability, the client SHOULD send ownership queries regardless of whether or not the client sees other resources for the same user online, or the capabilities of those other resources.

Clients that do not implement the Mine capability MAY be sent notifications by the server. The server MAY be optimized to avoid these notifications, however.

Some examples of events that might lead to a client sending an ownsership claim:

Some care should be given to the events that can cause ownsership claims, particularly in the MUC client implementations, such that users with different abilities all have a chance to claim ownership.

Clients MUST ignore acceptance notifications received from other users.

This document requires no interaction with &IANA;.

This XEP proposes the new namespace 'urn:xmpp:tmp:mine:0'.

]]>