[Standards-JIG] rfc3921bis, RC3

Peter Saint-Andre stpeter at jabber.org
Fri Oct 13 16:37:26 UTC 2006

So, to summarize, I think for directed presence we send empty presence
if the user is still online and empty unavailable presence if the user
is now offline. Thus (using the rfc3921bis examples):

<presence from='romeo at example.net/orchard'
          to='shakespeare at chat.example.com'/>


<presence from='romeo at example.net/orchard'
          to='shakespeare at chat.example.com'

Peter Saint-Andre wrote:
> Ian Paterson wrote:
>> Peter Saint-Andre wrote:
>>> <snip/>
>>> Oh, and the stuff about probes related to directed presence is here:
>>> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-00.html#presence-directed
>> The recipient already knows the content of the directed available
>> presence stanza it received. So, IMO, if the user is still available the
>> server should only respond to the probe with an *empty* presence stanza.
>> Returning the "last broadcasted available presence" may well leak
>> information that the other entity has no right to, and/or provide
>> incorrect information (e.g. if I'm DND to everyone except the occupants
>> of a room).
> Tough luck? Or maybe just send an empty presence packet if the user is
> still online? All we really care about here is determining whether the
> entity that sent directed presence is still online or has gone offline.
>> Also I think it would be helpful to indicate that once the client has
>> gone offline then the server should respond to a probe with the same
>> error as if the other entity had never been sent directed presence (i.e.
>> as soon as the client goes offline the server can forget about any
>> directed presence it sent on the client's behalf).
> Yes, that's the desired behavior.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061013/42925ff0/attachment.bin>

More information about the Standards mailing list