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='[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).
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
