Abstract: | This document provides a protocol using which a server is able to provide information to clients indicating that previously received presence data may be stale. |
Author: | Kevin Smith |
Copyright: | © 1999 - 2011 XMPP Standards Foundation. SEE LEGAL NOTICES. |
Status: | ProtoXEP |
Type: | Standards Track |
Version: | 0.0.1 |
Last Updated: | 2012-01-03 |
WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards Foundation, and this document is not yet an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://xmpp.org/extensions/> and announced on the <standards@xmpp.org> mailing list.
1. Introduction
2. Requirements
3. Discovery
4. Use Cases
4.1. Remote Server Unavailable
4.2. Local User Paused
4.3. MUC loses contact with occupant
5. Business Rules
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
9. XML Schema
Appendices
A: Document Information
B: Author Information
C: Legal Notices
D: Relation to XMPP
E: Discussion Venue
F: Requirements Conformance
G: Notes
H: Revision History
Presence data received by a client are typically cached and displayed until they are replaced by an update (whereupon the new data will be cached and displayed...), for example graphically annotating availability of contacts in a roster. Where the entity from which the client has received the presence data is remote (residing upon a different server), unavailability of the server to server link will render the client unable to receive further presence updates from the entity but unaware that this is the case. Where the remote entity is a contact, it may cause the contact appear to be online (or offline, or away etc.) to the user of the client when they are not. Where the remote entity is a MUC room the case is more severe, as the MUC room may have ejected the client due to the S2S link being unavailable to send stanzas but the client may still consider itself present in the room.
This extension provides a simple mechanism by which the local server can resend previous presence data to the client, annotated such that the client knows it would be unable to receive future updates.
Allow servers to annotate presence stanzas sent to clients indicating lack of availability of a client or server link necessary for receipt of updated presence.
Clients supporting this should have a feature of "urn:xmpp:psa" in caps. Servers autoenable based on this.
There are three main cases that links may be unavailable, leading to Romeo (a user of the montague.lit server) receiving presence state annotations:
Here we address each in turn. In each of these examples Romeo's client is assumed to have already indicated support for PSAs, as described in 'discovery' above.
In this example, Romeo (romeo@montague.lit) has received presence from Juliet (juliet@capulet.lit/orchard), either because she's in his roster or because she sent directed presence.
<presence from='juliet@capulet.lit/orchard' to='romeo@montague.lit/lane'> <status>Available</status> </presence>
The server to server connection between capulet.lit and montague.lit then becomes unavailable for some reason (montague.lit can't know if this is a network error, a server failure, or some other condition). Juliet may now be updating her presence (e.g. she might now have gone offline), and Romeo would not be able to receive the presence update stanzas. As such, montague.lit MUST push the old presence to Romeo, annotated that this may now be stale due to an s2s outage.
The state-annotation element alerts Romeo's client to the unavailability of the server link through the server-unavailable child. The state-annotation MUST have a 'from' attribute set to the entity annotating the stanza (in this case montague.lit), and an OPTIONAL description child MAY provide human-readable text describing the change.
<presence from='juliet@capulet.lit/orchard' to='romeo@montague.lit/lane'> <status>Available</status> <state-annotation xmlns="urn:xmpp:psa" from="montague.lit"> <server-unavailable/> <description>The capulet.lit server is no longer available</description> </state-annotation> </presence>
When the link between montague.lit and capulet.lit again becomes available, montague.lit MUST send an empty annotation of the previous presence to Romeo. It MAY subsequently attempt to refresh this presence by reprobing the remote entity.
<presence from='juliet@capulet.lit/orchard' to='romeo@montague.lit/lane'> <status>Available</status> <state-annotation xmlns="urn:xmpp:psa" from="montague.lit"/> </presence>
When an S2S connection is deemed not to be available, or to return to availability afterwards (TODO: guidelines on what this means), the server MUST send a corresponding annotated presence for every remote full JID on the unavailable server to every local client requesting PSAs where the local client has received presence from the remote JID and the most recent presence is an available type (i.e. not error or unavailable). Subscription requests are excluded from this processing.
In this example, Romeo (romeo@montague.lit) has received presence from Benvolio (benvolio@montague.lit/lane), who is using BOSH.
<presence from='benvolio@montague.lit/lane' to='romeo@montague.lit/lane'> <status>He ran this way, and leap'd this orchard wall</status> </presence>
Benvolio's client then uses the BOSH 'pause' feature for suspending the session. The montague.lit server MUST then send an annotated presence to Romeo's client saying that Benvolio's session has been paused. This MUST include the connection-paused element, MUST include a 'from' attribute of the entity doing the annotating (montague.lit) and MAY include a human-readable description element
<presence from='benvolio@montague.lit/lane' to='romeo@montague.lit/lane'> <state-annotation xmlns="urn:xmpp:psa" from="montague.lit"> <connection-paused/> <description>benvolio's BOSH session has been paused</description> </state-annotation> <status>He ran this way, and leap'd this orchard wall</status> </presence>
After pausing the session, Benvolio's client can either resume it or allow it to time out. If the session is resumed, the server MUST send an empty state-annotation to Romeo's client. If the session times out, it will simply send an unavailable presence as normal.
<presence from='benvolio@montague.lit/lane' to='romeo@montague.lit/lane'> <state-annotation xmlns="urn:xmpp:psa" from="montague.lit"/> <status>He ran this way, and leap'd this orchard wall</status> </presence>
<presence from='benvolio@montague.lit/lane' to='romeo@montague.lit/lane' type='unavailable'/>
When a server detects that a client's session has been temporarily suspended (either through a BOSH pause, or through a disconnection while using 198 prior to the resume period timing out) it MUST send annotated presence, as above, to every local and remote JID that has received the client session's presence (and where the presence is not subscription-related and has not been cancelled by a corresponding unavailable presence) and requests PSAs. If a paused session is resumed, the server MUST then send a corresponding empty state-annotation to each of these JIDs, as above. If the session is terminated the server MUST send unavailable presence using the usual rules from RFC6121.
In this example, Romeo (romeo@montague.lit) is an occupant in the orchard@chats.shakespeare.lit MUC room, alongside Juliet (juliet@capulet.lit). (For these examples, the usual MUC payloads are elided; they should be present as required by xep45).
<presence from='orchard@chats.shakespeare.lit/Juliet' to='romeo@montague.lit/lane'> <status>Ay me!</status> </presence>
Some time later, the MUC service chats.shakespeare.lit loses server to server connectivity to capulet.lit (the server upon which Juliet's account resides). If the server does not immediately remove Juliet as an occupant of the room, it MUST send Romeo an annotated presence, following the rules for server-unavailable defined above in s2s.
<presence from='orchard@chats.shakespeare.lit/Juliet' to='romeo@montague.lit/lane'> <state-annotation xmlns="urn:xmpp:psa" from="chats.shakespeare.lit"> <server-unavailable/> <description>The user's server is no longer reachable</description> </state-annotation> <status>Ay me!</status> </presence>
If the S2S link becomes available and the MUC service has not yet ejected Juliet from the room, it MUST send an empty state-annotation to indicate this. If, instead, it has ejected Juliet in the meantime there is no additional stanza to send (as the ejection will already have been communicated to Romeo's client following the rules in xep45).
<presence from='orchard@chats.shakespeare.lit/Juliet' to='romeo@montague.lit/lane'> <state-annotation xmlns="urn:xmpp:psa" from="chats.shakespeare.lit"/> <status>Ay me!</status> </presence>
Although this involves sending stanzas on behalf of another entity, these are always sent by entities that are already within trust domains able to spoof such stanzas (e.g. the local server sending to a local user, or a remote server sending on behalf of its local users).
None.
Needs a namespace.
When advanced.
Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status:
ProtoXEP
Type:
Standards Track
Version: 0.0.1
Last Updated: 2012-01-03
Approving Body: XMPP Council
Dependencies: XMPP Core
Supersedes: None
Superseded By: None
Short Name: PSA
This document in other formats:
XML
PDF
Email:
kevin.smith@isode.com
JabberID:
kevin.smith@isode.com
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
Initial published version.
(kis)END