[Standards] rfc3921bis: self-presence

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 29 21:04:17 UTC 2007

Mickael Remond wrote:
> Hello,
> ------- Message original ------- De: Remko Tronçon
> <remko at el-tramo.be> Envoyé: 29.8.'07,  19:06
>>> Maybe the server could only send a client's presence back to him
>>> if it has changed since the server last sent it?
>> I don't get the point. Why complicate things if the current
>> behavior (i.e. send presence back to all resources, no exception)
>> is easier for both the server *and* the client?
> It is easy for both client and server. The only thing is that it
> somewhat add a synchronous semantic. In the past you never get any
> packet on presence send. With the proposed changed you get a reply. 
> In some sense it can be good as it is some kind of ack, but it will
> be use for different things you can be sure (roundtrip mesurements,
> substitute to server pings).
> That said I do not have strong opinion regarding this change except
> that we need to know what is the recommended way for XMPP compliancy.

The text in RFC 3921 was poorly worded:

   In addition, the user's server MUST broadcast initial presence
   from the user's new available resource to any of the user's
   existing available resources (if any).

The construction "... any ... (if any)." is poor English and I'm sorry
it slipped through.

The intent was that the presence is sent to all resources. Therefore in
my working copy of rfc3921bis I have the following text:

   The user's server MUST also broadcast initial presence from the
   user's newly available resource to all of the user's available

I think that makes things clearer.

I do not recall why the "xmppbis" file had that text about not sending
self-presence, but (1) that file consisted only of some notes for
possible revisions and therefore is not canonical in any sense and (2)
the list consensus appears to be that the new text I have quoted above
is the desired functionality.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070829/447ce8ef/attachment.bin>

More information about the Standards mailing list