On Wed, Apr 08, 2009 at 09:05:46AM -0600, Peter Saint-Andre wrote:
> On 4/8/09 6:36 AM, Dave Cridland wrote:
> > On Wed Apr  8 11:21:51 2009, Robin Redeker wrote:
> >> Hi!
> >>
> >> I've recently stumbled across unavailable presence stanzas on s2s
> >> connections
> >> as replies to probes:
> >>
> >>    <presence from="b...@jid" to="..." type="unavailable" />
> >>
> >>
> > Right, we hand those out too, whenever users are known to be offline.
> > We'll also timestamp them, and include <status/>, if we have that
> > information.
> 
> Hmm, is this in response to a probe? That might make some sense, then.

It is sent response to a probe in jabberd2. But I'm wondering about the general
semantics of the unavailable presence from a bare JID of a contact (or even a
non-contact).

After thinking a bit more about presences I went into some other issues which I
didn't find explained in the RFC or didn't make sense to me:

1.

I'm also wondering about the general semantics of _available_ presence from a
bare JID, like discussed in another branch of this thread.

Imagine these presence stanzas are received by a client for contact a...@b:

   <presence from="a...@b/X" to="m...@jid/myres"/>

   <presence from="a...@b/Y" to="m...@jid/myres">
      <priority>10</priority>
      <show>xa</show>
   </presence>

   <presence from="a...@b" to="m...@jid/myres">
      <show>away</show>
   </presence>

What should I display? Is the last presence from 'the "empty" resource'?  Empty
resources make no sense, as any resource's name must not be empty anyways (see
BNF in RFC 3920). But whats the alternative interpretation of presence from a
bare JID? Does it shadow any other presence? Is it guaranteed that a client will
not receive presence for a bare JID and full JID from the same contact?

If services send presence from bare JIDs, how should those be handled? What is
the meaning of <priority/> elements in those presences?

2.

Another question I got is:

   RFC 3921 bis
   4.5.4.  Client Processing of Inbound Unavailable Presence

   
http://xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-07.html#presence-unavailable-client

   1. If the user is in the contact's roster, the client MUST display the
      unavailable presence information in an appropriate roster interface. 

Imagine that some contact was online with 2 resources which become
unavailable and send me their reason for becoming unavailable:

   <presence from="c...@d/X" type="unavailable">
     <priority>20</priority>
     <status>Off for vacation.</status>
   </presence>

   <presence from="c...@d/Y" type="unavailable">
     <priority>10</priority>
     <status>Off for picking girlfriend up.</status>
   </presence>

Ignore the contradicting offline status for now, but for which' of those should
I display the unavailable information? For both resources?  For the unavailable
presence which has been received most recently? Or for the unavailable presence
with the highest priority?

Lets assume the client should display the unavailable presence for _all_ 
resources
which went offline. Wouldn't that be inconsistent with presence probes where the
server returns unavailable information for only one resource? For this read:

   4.3.2.  Server Processing of Inbound Presence Probe 

   2. Else, if the contact has no available resources, the server SHOULD reply
   to the presence probe by sending to the user the full XML of the last 
presence
   stanza of type "unavailable" received by the server from the contact ...

This means a server only remembers the last received unavailable presence, but
a client _must_ display all unavailable presences it receives. That feels a bit
inconsistent to me. Also imagine what happens when people use random resources,
then the list of unavailable presences (which MUST be displayed
"appropriately") will grow indefinitely! Ok, this is maybe no "appropriate",
but what _IS_ actually appropriate in this case?



-- 
Robin Redeker                         | Deliantra, the free code+content MORPG
el...@ta-sa.org / r.rede...@gmail.com | http://www.deliantra.net
http://www.ta-sa.org/                 |

Reply via email to