[Standards] rfc3921bis: self-presence

Peter Saint-Andre stpeter at stpeter.im
Wed Aug 29 22:08:50 UTC 2007

Mridul Muralidharan wrote:
> Peter Saint-Andre wrote:
>> The old "xmppbis" page [1] had the following note:
>> ***
>> It is unnecessary, potentially confusing, and not recommended to add
>> your own JID to your roster. However, RFC 3921 currently does not talk
>> about how a server should handle such "self roster items" if they exist.
>> The spec should probably specify that a server MUST NOT send presence
>> probes to self roster items, since the server already knows that the
>> entity is online once it receives initial presence from a specific
>> resource. Thus a resource should never receive presence information
>> about itself from its own server, although it will receive presence
>> information about other available resources for that entity as currently
>> specified in RFC 3921.
>> ***
>> This conflates two issues: (1) adding yourself to your roster and (2)
>> receiving presence from your "self" resource.
>> IIRC we had list consensus that (1) is something we want to discourage.
> 2.3.2 talks specifically not allowing user to add his own bare jid to
> the roster (as a MUST).

You don't add yourself to your roster, but still you get presence from
your other available resources. Roster and presence are separate things.

>> But (2) seems OK. When you send presence to your server, your server
>> delivers that presence to all of your available resources. Consider a
>> user with two resources ("foo" and "bar") who then comes online with a
>> third resource ("baz").
>> <presence from='user at example.com/baz'/>
>> [ ... to "foo" resource ... ]
>> <presence from='user at example.com/baz'
>>           to='user at example.com'/>
>> [ ... to "bar" resource ... ]
>> <presence from='user at example.com/baz'
>>           to='user at example.com'/>
>> [ ... to "baz" resource ... ]
>> <presence from='user at example.com/baz'
>>           to='user at example.com'/>
> Why should an entity need to get its own presence ack'ed from the server
> ? What is there a usecase for this ? Or is this a nice to have
> modification just to make things easier ?

I don't think it's a modification, just a clarification.

> There are way too many client and server deployments which already use
> the existing behavior - that is presence is not sent to the publisher,
> so we might want to weight against that when modifying this : since the
> bis spec compliant client should be able to interop with existing servers.

Yet note that in PEP, the publisher does receive the published item. Why
should the special "pubsub-like" data called network availability be any
different? The special-casing here seems odd.

>> Is it harmful for the "baz" resource to receive its self-presence? I
>> don't see a particular reason why the server needs to avoid sending
>> that. Would it confuse the client?
>> /psa
> bis compliant clients will 'expect' this behavior - and so will break


> when they talk to older servers (assuming they do something with this
> presence status).

As far as I know, they don't.

> Reverse might also be the case - of existing clients breaking when they
> get presence for their own jid (will they treat it as conflict ?)

We have a lot of speculation here from server developers. But the client
developers who have posted say "this is fine, we like it better". So why
all the worrying?


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/5643b786/attachment.bin>

More information about the Standards mailing list