Peter Saint-Andre wrote:
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.
Yes, I was referring to (1) above, not (2).
(1) would be a MUST violation.
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='[EMAIL PROTECTED]/baz'/>
[ ... to "foo" resource ... ]
<presence from='[EMAIL PROTECTED]/baz'
to='[EMAIL PROTECTED]'/>
[ ... to "bar" resource ... ]
<presence from='[EMAIL PROTECTED]/baz'
to='[EMAIL PROTECTED]'/>
[ ... to "baz" resource ... ]
<presence from='[EMAIL PROTECTED]/baz'
to='[EMAIL PROTECTED]'/>
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).
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).
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.
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 ? :-)
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).
This is not the behavior for atleast a few servers (including our own)
right now.
Mridul
Peter
