[Standards] Presence extensions
stpeter at jabber.org
Fri Feb 2 17:08:22 UTC 2007
Ralph Meijer wrote:
> I was testing out Palaver, a MUC implementation, and found out the
> following. MUC role changes are pushed to room occupants using presence
> stanzas. However, Palaver sends them out without any other presence
> information. When a user that previously sent away presence, for
> example, the role change stanza doesn't include that and the client
> things that the availability for this user changed to plain available.
> After a small discussion with Ian, it appears this situation is
> underspecified, either in XEP-0045 or in XMPP IM. The question being:
> what to do on broadcasting presence stanzas, and in particular a proxy
> like situation like MUC, with presence extensions.
> I can think of different types of extensions:
> * Extensions that really augment availability information. You have to
> them every time.
> * Extensions that add non-availability information like role changes
> or other information orthogonal to availability. These don't have to
> be sent
> every time. It can be argued that these should not be in presence
> However, several protocols do this.
Yes we could make that argument. But MUC is in a way a kind of legacy
usage and we don't want to break it. More precisely, MUC does function
as a kind of presence proxy. So in order to do the right thing, it needs
to keep track of the last presence it received from the user. The other
approach would be to put all the role change information into message
stanzas rather than presence stanzas, but I don't see a great reason to
do that at this point.
> * Extensions that contain meta information about the actual presence
> stanza being
> sent. An example is a signature to be able to verify the authenticity
> of the
> (proxied) presence. Note that if entities add data to presence before
> broadcasting, such a signature will cease to be valid. So in case of
> you probably cannot pass these on.
> Ian suggests we need to figure out what to do here and edit RFC3920bis
> accordingly. Probably XEP-0045 needs some updated examples, too.
I'm with Remko, I don't see how rfc3920bis comes into this.
XMPP Standards Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards