Subject: [xmpp] 3921bis: probe + unavailable

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jan 2010 14:34:07 -0700

Regarding the server response to an inbound presence probe, Section
4.3.2 of 3921bis currently reads as follows:

******

   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).

******

There are two issues I'd like to bring up:

a. My sense of existing implementations is that people would prefer a
definitive answer to the probe (i.e., <presence type='unavailable'/>).
Therefore I would like to change "SHOULD reply with unavailable but MAY
opt to not reply at all" to "MUST reply with unavailable".

b. Someone poked me offlist about a potential security issue here: what
if the probing user was blocked from receiving the contact's presence at
that time (e.g. via privacy lists)?

Therefore I suggest that the spec shall be modified to read as follows:

******

   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
       SHOULD be empty but (subject to local security policies) MAY
       include the full XML of the last unavailable presence stanza that
       the server received from the contact.

   CS: <presence from=[email-masked]'
                 to=[email-masked]'
                 type='unavailable'/>

******

Objections?

Peter

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

---

From: Dave Cridland <[email-masked]>
Date: Thu, 28 Jan 2010 21:40:28 +0000

> opt to not reply at all" to "MUST reply with unavailable".
I agree - I think it's a change that's sorely needed - but I'd note  
that this will render several servers no longer conformant. So a  
note's needed at minimum to explain that this didn't used to be a  
requirement, and clients (and servers) SHOULD cope with no response  
as meaning unavailable.

> that time (e.g. via privacy lists)?

Right.

>        the server received from the contact.

Replace SHOULD with "will typically be". You can't have SHOULD but  
MAY, I think, and it's not an interop requirement.

Also, you might stamp it with a delay, in which case it's not empty...

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Ben Schumacher <[email-masked]>
Date: Thu, 28 Jan 2010 14:57:53 -0700

> Also, you might stamp it with a delay, in which case it's not empty...

As the person responsible for the offlist poking, I feel I should step 
up and point out that stamping delay constitutes a presence leak. If I 
had a privacy list that blocked you, Dave, from receiving my presence 
while I'm online then I got offline and the server then decides to 
respond to probes that indicate when I was last online, you now know 
that I was online and trying to hide that fact from you.

An empty presence type="unavailable" is the only way to ensure (without 
some really complex heavy lifting on the server) that you're properly 
indicating that the user isn't here right now, and that's all. I would 
further recommend that this unavailable presence MUST be from the bare 
JID (user@host) as the server should be indicating that this Presence 
Entity is unavailable, rather than a session (if you're going to send 
the last unavailable, then the server ought to rewrite the from to this 
effect).

Finally, (and this isn't RFC related) the privacy list XEP(s?) should be 
updated to indicate that the same behavior should be followed.

Cheers,
Ben

---

From: Dave Cridland <[email-masked]>
Date: Thu, 28 Jan 2010 22:08:13 +0000

On Thu Jan 28 21:57:53 2010, Ben Schumacher wrote:
> As the person responsible for the offlist poking, I feel I should  
> step up and point out that stamping delay constitutes a presence  
> leak. If I had a privacy list that blocked you, Dave, from  
> receiving my presence while I'm online then I got offline and the  
> server then decides to respond to probes that indicate when I was  
> last online, you now know that I was online and trying to hide that  
> fact from you.
> 
> 
Yuck. Yes, and if you just noted that sometimes the server did  
include useful data, and sometimes it didn't, then you'd know whether  
the contact had been (or still is) online with a privacy list active.

How horrible that we need to throw away a perfectly good bit of  
functionality to satisfy privacy lists.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jan 2010 15:09:07 -0700

On 1/28/10 3:08 PM, Dave Cridland wrote:
> Yuck. Yes, and if you just noted that sometimes the server did include
> useful data, and sometimes it didn't, then you'd know whether the
> contact had been (or still is) online with a privacy list active.
> 

Well, you'll still know that the contact is offline, you just won't know
all the juicy details.

Peter

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

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 29 Jan 2010 15:37:56 +0500

> opt to not reply at all" to "MUST reply with unavailable".
+1.

There's another thing I was wondering about:

For presence probes, "The value of the 'from' address MUST be the full JID
<user@domain/resource> of the user and the value of the 'to' address MUST be
the bare JID <contact@domain> of the contact to which the user is
subscribed."

Why MUST those JIDs be that way? I can think of valid cases where a bare JID
may wish to probe the presence of a full JID.

--
Waqas Hussain

---

From: Jonathan Schleifer <[email-masked]>
Date: Fri, 29 Jan 2010 13:39:14 +0100

> Objections?

This change sounds totally sane and fixes a lot of confusion.

+1

--
Jonathan

---

From: Jonathan Schleifer <[email-masked]>
Date: Fri, 29 Jan 2010 13:41:28 +0100

Am 28.01.2010 um 22:40 schrieb Dave Cridland:

> So a note's needed at minimum to explain that this didn't used to be  
> a requirement, and clients (and servers) SHOULD cope with no  
> response as meaning unavailable.

The problem with that is: How do you figure out if you don't get a  
response or if you are just still waiting for it? We should define a  
sane timeout here, I guess, to prevent incompatibilities. This also  
means we need to figure out a sane value that even works with bad  
connections.

--
Jonathan

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Jan 2010 07:58:22 -0700

On 1/29/10 5:41 AM, Jonathan Schleifer wrote:
>> So a note's needed at minimum to explain that this didn't used to be a
>> requirement, and clients (and servers) SHOULD cope with no response as
>> meaning unavailable.

The default is always unavailable. If you receive positive <presence/>
then you have some clue that the contact is online. If not, not. If you
receive a definitive answer that the contact is offline, that's even
better, but you can never assume that the contact is online.

> means we need to figure out a sane value that even works with bad

I don't see a good reason to go down that path, which introduces more
complexity into clients.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Jan 2010 08:03:25 -0700

On 1/29/10 3:37 AM, Waqas Hussain wrote:

> For presence probes, "The value of the 'from' address MUST be the full
> JID <user@domain/resource> of the user and the value of the 'to' address
> MUST be the bare JID <contact@domain> of the contact to which the user
> is subscribed."
> 
> Why MUST those JIDs be that way? I can think of valid cases where a bare
> JID may wish to probe the presence of a full JID.

The original reasoning was that a user comes online with a particular
resource and my server sends a probe to the user's contacts (bare JID)
on behalf of that resource (full JID). I don't know what your use cases
are, so I'm not sure why we would change the logic we've had since 1999.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 29 Jan 2010 16:08:57 +0100

> are, so I'm not sure why we would change the logic we've had since 1999.

jabberd sends from the bare jid. And it does that at least since 2003.

philipp

---

From: Waqas Hussain <[email-masked]>
Date: Fri, 29 Jan 2010 20:16:38 +0500

> are, so I'm not sure why we would change the logic we've had since 1999.
I was concerned about presentities which are not users. If
component.example.com wishes to probe [email-masked], MUST it send the
probe from
component.example.com/someresourcewhichisntactuallyusedforanythingelse?

And there are valid cases where sending to a full JID would be the optimal
solution. A MUC can use it to detect ghosts. And no, it doesn't have to poll
every minute. If it has information about S2S for example, a smart
implementation could just poll when it has detected that the remote server
reconnected, restarted, etc, which is better than no ghost detection. The
usual way to test for a ghost is to detect remote-host-not-found errors. And
if you missed that (e.g., you didn't send any stanzas while the remote host
rebooted), then is there any other way to detect ghosts which works with
existing clients?

My only objection is that MUST is too forceful.

--
Waqas Hussain

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Jan 2010 08:33:55 -0700

On 1/29/10 8:16 AM, Waqas Hussain wrote:
> On Fri, Jan 29, 2010 at 8:03 PM, Peter Saint-Andre <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> component.example.com <http://component.example.com> wishes to probe
> [email-masked] <mailto:[email-masked]>, MUST it send the probe from
> component.example.com/someresourcewhichisntactuallyusedforanythingelse
> <http://component.example.com/someresourcewhichisntactuallyusedforanythingelse>?
> 
> And there are valid cases where sending to a full JID would be the
> optimal solution. A MUC can use it to detect ghosts. And no, it doesn't
> have to poll every minute. If it has information about S2S for example,
> a smart implementation could just poll when it has detected that the
> remote server reconnected, restarted, etc, which is better than no ghost
> detection. The usual way to test for a ghost is to detect
> remote-host-not-found errors. And if you missed that (e.g., you didn't
> send any stanzas while the remote host rebooted), then is there any
> other way to detect ghosts which works with existing clients?
> 

Yes. In fact we probably don't need to say anything at all, other than
that the probe must come from the JID of the entity on whose behalf
presence is being requested.

Peter

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

---

From: Jonathan Schleifer <[email-masked]>
Date: Fri, 29 Jan 2010 22:13:26 +0100

> I don't see a good reason to go down that path, which introduces more

So you suggest to assume all presences you already received as invalid  
when you send a presence probe and only take those into account that  
you got after the probe? Sounds like a solution, but a dirty one, IMO.

I think that sending back an unavailable a MUST is a good idea, as  
then you have a definite answer whether the user is online or not,  
whereas without, it could just be a laggy connection etc.

--
Jonathan

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Jan 2010 15:26:36 -0700

On 1/29/10 2:13 PM, Jonathan Schleifer wrote:
> when you send a presence probe and only take those into account that you
> got after the probe? Sounds like a solution, but a dirty one, IMO.
> 
> I think that sending back an unavailable a MUST is a good idea, as then
> you have a definite answer whether the user is online or not, whereas
> without, it could just be a laggy connection etc.

I suggested making it a MUST to return unavailable.

Peter

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

---

From: Jonathan Schleifer <[email-masked]>
Date: Sat, 30 Jan 2010 01:42:10 +0100

> I suggested making it a MUST to return unavailable.

Yeah, that was what I was suggesting, too, however, it seems I was too  
tired to formulate it in an understandable way / write a sentence  
which makes sense.

Therefore: +1

--
Jonathan

---

From: Jonas Lindberg <[email-masked]>
Date: Sat, 30 Jan 2010 23:29:06 +0100

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

On Sat, Jan 30, 2010 at 1:42 AM, Jonathan Schleifer
<[email-masked]>wrote:

> tired to formulate it in an understandable way / write a sentence which
> makes sense.
>
> Therefore: +1
>
>
> --
> Jonathan
>
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Jonathan Schleifer <[email-masked]>
Date: Sun, 31 Jan 2010 02:41:54 +0100

Am 30.01.2010 um 23:29 schrieb Jonas Lindberg:

> 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.

I think you got something wrong here: We are not talking about what  
happens when you connect. We are talking about presence probes sent  
from one client to a server. A mobile client would not get any  
unavailable presence more than it would get now, expect it requests it  
by doing a probe.

--
Jonathan