[Standards] rfc3921bis: self-presence

Mridul Muralidharan mridul at sun.com
Wed Aug 29 22:40:47 UTC 2007

Peter Saint-Andre wrote:
> Mridul Muralidharan wrote:
>> Peter Saint-Andre wrote:
>>> Mridul Muralidharan wrote:
>>>> Peter Saint-Andre wrote:
>>>>> 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.
>> As Rachel Blackman mentioned, this is a change of behavior between the
>> rfc's, and any client depending on this behavior will not be able to
>> work properly with existing servers - unless it adds the special case
>> (which is required currently).
> As far as we know, no clients depends on this behavior.
>>>> 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.
>> If we were doing 3921 now, it might make sense to not special case it -
>> though imo it is useless to ack it back, since the server is expected
>> not to modify the presence in any way (unlike pubsub where you might
>> have other filters/server side processing in place).
> Really? Section 7 of XEP-0115 shows otherwise:
>    A server that is managing an entity's presence session MAY choose
>    to optimize traffic through the server. In this case, the server
>    MAY strip off redundant capabilities annotations. Because of this,
>    receivers of annotations MUST NOT expect an annotation on every
>    presence packet they receive.
> Which to me is argument enough that you want to receive your own presence.

I dont think capabilities getting stripped is relevant to this 
discussion - definitions of which, just like resource presence, is 
already known to the publisher.
So that particular change server effects might not be very relevant imo.

>>>>> 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
>>> How?
>> Assuming 'own presence' is used by bis-client (like showing itself as
>> online, etc), it will not do so unless server ack's the presence - which
>> will never happen for pre-bis servers.
> But bis-clients can presumably be written in a smarter way. That's not
> breakage. Breakage means older software doesn't work.

If the intention is to get bis clients to continue to work with pre-bis 
servers (thereby requiring them not to depend on this clarification), 
then I guess there wont be any issues.

>>>> when they talk to older servers (assuming they do something with this
>>>> presence status).
>>> As far as I know, they don't.
>> If they dont, then why should we do this change ? :-)
> It's not a change, it's a clarification!

I will need to change server to comply with this - server will be 
sending, and component/client receiving stanza's it was not used to.
Also, the server versions prior to this wont be doing any of this.

So the clarification results in server behavior, testcase and code 
change :-)

>> Actually in our client, we used to always special case this (when user
>> was in his roster - long story of how jid got there).
>>>> 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?
>> The problem is essentially because the bis compliant clients will have
>> issues with 3920/3921 servers if they expect server to ack presence for
>> same entity - if they depend on it (if they dont, then whether server
>> ack's or not is redundent).
> Don't depend on it.
> Peter

So essentially you are proposing something like this :
bis server's should send presence of presence to all resources 
(publisher included) - but publisher should depend on recieving its own 
presence since it could be a pre-bis server ?

That should be fine I guess ...

What happens for privacy list/block list enforcement btw ? Will the 
publisher expect to get an unavailable now ? (I dont recall if it 
already does).

- Mridul

More information about the Standards mailing list