From 77cb6d32e877e7bd42f087aad9430d504bdad427 Mon Sep 17 00:00:00 2001 From: Kevin Smith Date: Wed, 4 Jan 2012 13:12:37 +0000 Subject: [PATCH] Presence Server Annotations protoXEP for the inbox. --- inbox/psa.xml | 187 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 187 insertions(+) create mode 100644 inbox/psa.xml diff --git a/inbox/psa.xml b/inbox/psa.xml new file mode 100644 index 00000000..3fc636a6 --- /dev/null +++ b/inbox/psa.xml @@ -0,0 +1,187 @@ + + +%ents; +]> + + +
+ Presence State Annotations + 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. + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + + + + PSA + &ksmithisode; + + 0.0.1 + 2012-01-03 + kis +

Initial published version.

 + +
+ +

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.

+ +Appropriate action - alert user, attempt to rejoin MUC, whatever. + +

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:

+
    +
  • That a connection from montague.lit to a remote server, such as capulet.lit, is unavailable, leading to remote presence from users on capulet.lit (e.g. juliet@capulet.lit) being potentially stale.
    • +
  • That a connection from a client to montague.lit has been paused (e.g. because the client uses Stream Management and has a ready-to-resume session, or has a paused BOSH session), such that Romeo's representation of a paused session such as benvolio@montague.lit's is not accurate.
    • +
  • That the connection between a MUC room in which Romeo is an occupant and another of that room's occupants is affected by either of the cases above, making Romeo's view of the room occupancy stale.
    • +
+

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.

+ + Available + +]]> +

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.

+ + Available + + + The capulet.lit server is no longer available + + +]]> +

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.

+ + Available + + +]]> +

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.

+ + He ran this way, and leap'd this orchard wall + +]]> +

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

+ + + + benvolio's BOSH session has been paused + + He ran this way, and leap'd this orchard wall + +]]> +

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.

+ + + He ran this way, and leap'd this orchard wall + +]]> + +]]> + +

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).

+ + Ay me! + +]]> +

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.

+ + + + The user's server is no longer reachable + + Ay me! + +]]> +

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).

+ + + Ay me! + +]]> + + + + + + +
    +
  • When getting 'available again' for a remote MUC, MAY message yourself in the MUC and rejoin if not present.
    • +
  • When MUC service re-establishes S2S, may send a probe to see if remote client is still online.
    • +
+ + + +

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.

+ +