[Standards] rfc3921bis: self-presence

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


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.

>>>> 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.

>>> 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!

> 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

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- 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/904b24a9/attachment.bin>


More information about the Standards mailing list