Re: [xmpp] 3921bis: probe + unavailable

[Peter Saint-Andre <[e-mail]>]

On 2/1/10 12:56 PM, Ben Schumacher wrote:
> On 01/30/2010 03:29 PM, Jonas Lindberg wrote:
>> While I agree this would simplify the protocol a little, I am not
>> convinced it is a change worth making.
>>
>> First of all, not responding to probe when unavailable is a pretty
>> good optimization. A large part of Xmpp traffic is presence. This
>> change would further significantly increase the presence traffic,
>> making scaling more challenging and adding load to c2s and s2s
>> connections. For example, a cell phone xmpp client may be better off
>> not getting potentially thousands of presence unavailable stanzas for
>> offline friends when connecting over gprs.
>>
>> I'm also not convinced this change make it significantly easier to
>> implement xmpp clients/servers. Especially if we are going to
>> recommend that clients and servers SHOULD cope with no response for
>> legacy reasons.
>>
> 
> Jonas-
> 
> I agree with your points -- it would likely result in extra traffic.
> That being said, I much prefer this to the ambiguity (and potential
> presence leak) of the prior language. As it happens, servers and clients
> will *always* have to cope with no response as this is a network'd
> service and packets can get lost, etc, so I'm not sure the language
> should be "SHOULD" re: legacy services, but rather maybe a note that
> indicates that you may not get a response.

Version -03 of 3921bis currently reads:

   2.  Else, if the contact has no available resources, then the server
       SHOULD reply to the presence probe by sending to the user the
       full XML of the last presence stanza of type "unavailable"
       received by the server from the contact (however, the server MAY
       opt to not reply at all).

My working copy of 3921bis proposes:

   2.  Else, if the contact has no available resources, then the server
       MUST reply to the presence probe by sending to the user a
       presence stanza of type "unavailable"; this presence stanza MAY
       include the full XML of the last unavailable presence stanza that
       the server received from the contact, if appropriate in
       accordance with local security policies, otherwise it will
       indicate only that the contact is unavailable.

   CS: <presence from='[e-mail]'
                 to='[e-mail]'
                 type='unavailable'/>

I understand that the MUST here is an imposition on servers. IMHO the
deterministic nature of the unavailable has many benefits, but I can see
why large service providers would prefer to return a stanza to the
probing user only if the contact is online. So I think it's good that we
discuss the tradeoffs here.

Peter

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