[Standards] rfc3921bis: self-presence
mridul at sun.com
Wed Sep 5 18:15:30 UTC 2007
Peter Saint-Andre wrote:
> Mridul wrote:
>> Curtis King wrote:
>>> On Aug 29, 2007, at 6:20 PM, Mridul Muralidharan wrote:
>>>> 3921.Section 5.1.1 - "In addition, the user's server MUST broadcast
>>>> initial presence from the user's new available resource to any of the
>>>> user's existing available resources (if any)."
>>>> I think this is pretty clear in stating that presence is to be sent to
>>>> existing resources 'if any' (and not the 'new available resource').
>>> It's not clear because what does "existing available resources" mean?
>> Explicit use of 'new available resource' and 'if any' should clarify that ?
>> If someone wants to mis-read it on purpose, sure that is possible
>> through out the rfc's - it is after all an engineering document !
>> imo, it is not ambiguous - nor is it bugprone or problematic.
>> So I hope the change being affected is not in the name of clarifying it
>> - iirc, this is the expected behavior from all servers today, ditto for
>> clients (who use this).
> Mridul, if you would like, we can call this a change.
> The question is: what is the best behavior? Here are some considerations:
> 1. Clients are now performing contortions if they want self-presence, as
> described by several client developers who have posted to this thread.
> Sending to all resources simplifies client code.
> 2. It is less complicated for servers to send to all resources without
> exception than to special-case the self-resource.
> 3. Sending to all resources without exception is consistent with how we
> do things in pubsub/PEP.
> 4. Receiving self-presence enables the client to determine if the server
> has modified what the client sent.
> 5. Currently no clients depend on *not* receiving self-presence, so
> sending to all resources without exception will not break deployed software.
> So it seems that sending to all resources without exception simplifies
> both client and server code, is more consistent with the pubsub model
> (which could lead to code re-use), enables the client to check up on the
> server's presence processing, and doesn't break anything. Furthermore we
> seem to have list consensus that this is a reasonable approach.
> Therefore, unless more people come forward with objections to this
> approach, I will conclude that we have rough consensus on this point and
> suggest that we move on with our lives.
> Naturally, you are free to bring up the matter during IETF Last Call if
> you so desire.
My main concern has been already voiced - bis compliant clients becoming
dependent on self-presence being ack'ed, and failing to function while
talking to pre-bis servers : and considering the reasons why clients
seem to want this added, this will be a problem.
Currently - we do not have presence broadcast resulting in error's,
neither do we have server modifying presence data (only transformation -
like stripping of caps) - unlike pubsub, muc, etc.
Are we planning to add support for either of these for presence ? If
yes, a case can be made imo.
At the end of the day, so as long as we are aware of the potential
incompatibilities and interop issues that will crop up, it is fine I guess.
(1) sounds strange, I did take a look at our client, and it was just a
few lines of code for the above mentioned contortion ;-)
(2) above is not really relevant, it just depends on server
implementation imo - and there are so few servers anyway as compared to
libraries/clients :-) In our case, it is an explicit addition if
condition preventing self-presence ack.
More information about the Standards