[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmpp] 3921bis: probe + unavailable



Peter's new proposal sounds good to me.

A few more comments inline below:

On Tue, Feb 2, 2010 at 2:03 AM, Justin Karneges <justin at affinix.com> wrote:
> On Monday 01 February 2010 12:46:52 Peter Saint-Andre wrote:
>> 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.
>
> A large benefit is to prevent a jabber:iq:last storm.  We don't want there to
> be any reason for a client to poll its entire roster.
>
> I can see why a mobile client might not be interested in having that
> information pushed at it on login, to reduce resource usage.  Jonas'
> suggestion of making this a client-controlled option is probably best, but I
> don't know what the default behavior should be.

I wouldn't want to change the default behavior in a way that breaks
the user experience on clients that work well today.

> Also, there has been discussion in the past about sending presence only of
> certain contacts, groups, etc, when mobile, so the solution for filtering out
> unavailable presence might fit right in with that maybe.
>
> Another thing: this issue is actually two-part: 1) should remote servers reply
> to probes if the contact is unavailable?  and 2) should the local server send
> unavailable presence to contacts that just logged in?  Both of these have
> resource usage implications, but only the second one impacts the client.

I'd prefer continuing to treat these as one in the spec to keep it
simple. I also would not want it to be a MUST for (1).

> -Justin
> _______________________________________________
> xmpp mailing list
> xmpp at ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp
>

Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.