[jdev] presence persistence

[Richard Dobson]

----- Original Message ----- 
From: "Mats Bengtsson" <matben at privat.utfors.se>
To: <jdev at jabber.org>
Sent: Wednesday, November 30, 2005 3:23 PM
Subject: [jdev] presence persistence


>
> Although not recommended, it is allowed to use presence stanzas to 
> broadcast
> custom elements (rfc3921):
> "
>   As described under extended namespaces (Section 2.4), a presence
>   stanza MAY contain any properly-namespaced child element.
> "
> Each client keeps an internal state of
> the users presence state, but what happens to these states when a custom
> presence is received? An example:
>
> If I initially get
>
>   <presence type='available' from='x' ...>
>     <show>dnd</show>
>   </presence>
>
> and then later a custom presence
>
>   <presence from='x' ...>
>     <custom xmlns=.../>
>   </presence>

>
> shall the user 'x' status still be 'dnd'?

No in this example the presence of 'x' has become available.

> But if I instead get
>
>   <presence from='x' .../>

This is again simple an available presence.

> without any custom element the status is obviously 'available' and not 
> 'dnd'.
> This doesn't make any sense. One way out of this is if custom presence
> included the other elements <show/> <status/> <priority/> but that seems 
> clumsy.

Including extra custom elements into the presence stanza does not alter how 
it works in the way you suggest, if you want to broadcast a custom elements 
using presence you must ensure that your element is simply added into 
whatever the presence stanza would be if you wernt going to include it.

Custom presence extensions are simply extra stuff (should really only be 
stuff that is actually also related to your presence), that should be able 
to be completely ignored as if they wernt there without altering how the 
rest of the presence stanza is processed. You must also be aware that it is 
not guaranteed that all your contacts will ever receive any of your 
extensions as servers may filter them out of the presence stanza on route 
for reasons such as reducing bandwidth usage for clients like mobile phones 
where bandwidth is very expensive, or maybe even simply for security reasons 
some servers may filter out all extensions that havent been explicitly 
allowed.

> We already have this situation with caps elements, but they are typically 
> only
> sent with the initial presence, and don't cause this dilemma.

Its not a dilemma its how it works.

> Ideas?    /Mats

Richard