[Standards] rfc3921bis: self-presence
stpeter at stpeter.im
Wed Sep 5 14:55:38 UTC 2007
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards