diff --git a/xep-0259.xml b/xep-0259.xml new file mode 100644 index 00000000..4b7b8c85 --- /dev/null +++ b/xep-0259.xml @@ -0,0 +1,466 @@ + + +%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'.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + +]]> + +