Subject: [xmpp] 3921bis: probe to full JID?

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jan 2010 16:04:12 -0700

While reviewing the text on presence probdes just now in Section 4.3 of
3921bis, I noticed that we say a presence probe MUST be addressed to a
bare JID. However, in Section 8 there is no text about how to handle a
presence probe that (in contravention of the spec) is addressed to a
full JID. Therefore I think we need to do one of the following:

1. Continue to disallow probes to full JIDs but add rules for handling
such probes to Sections 8.2.1 and 8.2.2 (e.g., return a <bad-request/>
error or silently ignore the probe).

2. Allow probes to full JIDs and add rules for handling such probes to
Section 4.3.2.

I have heard arguments in favor of probing full JIDs (e.g., to help
prevent ghost occupants in chatrooms), but I think there are better ways
to solve the problems driving those arguments than to probe full JIDs.
Furthermore, currently we say that a presence subscription request MUST
be addressed to a bare JID, and that seems consistent with specifying
that probes are associated with subscriptions (not with directed
presence and the temporary presence sharing that results from directed
presence). Thus I favor Option #1 above. However, I didn't want to gloss
over this issue in case anyone has strong opinions in the matter.

As to the rules for handling probes to full JIDs if we decide to proceed
with Option #1, I suggest that the receiving server shall return a
<bad-request/> error. (We need to specify how the receiving server shall
handle subscription requests to full JIDs, and it seems reasonable to
return a <bad-request/> error in that case, too.)

Peter

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

---

From: Justin Karneges <[email-masked]>
Date: Thu, 28 Jan 2010 18:43:40 -0800

> to solve the problems driving those arguments than to probe full JIDs.

What alternative did you have in mind for solving stale directed presence?  
Probes make the most sense to me, as it is the same approach you'd use to fix 
stale normal presence.

Maybe we could come up with something where s2s connection state or XEP-0198 
session state tie into presence validity, but I don't know if we'll end up 
with a solution that is necessarily any more practical.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 28 Jan 2010 20:06:54 -0700

> Probes make the most sense to me, as it is the same approach you'd use to fix 

My concern is that people will start polling for stale directed
presence. For instance, if you're in a chatroom and the chat service
tries to send you a message, it will perhaps receive an error stanza
from your server. Would we rather have the chat service poll your server
every minute to see if you're still online? That doesn't seem like a
good idea.

> with a solution that is necessarily any more practical.

How is directed presence any different from broadcast presence in this
regard? Presence simply isn't reliable, and anyone who wants to make it
so will need to do a lot of work.

Peter

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

---

From: Justin Karneges <[email-masked]>
Date: Thu, 28 Jan 2010 20:22:04 -0800

On Thursday 28 January 2010 19:06:54 Peter Saint-Andre wrote:
> > What alternative did you have in mind for solving stale directed
> > presence? Probes make the most sense to me, as it is the same approach
> > you'd use to fix stale normal presence.
>

Any sent stanza acts as a probe here, at least for discovering s2s connection 
errors.  If enough time passes in a room and nobody has joined, changed 
status, left, or sent a message, then it's probably not unreasonable to 
suggest that all of the participants be sent /something/ to induce a bounce.  
At least in terms of outbound MUC processing and traffic, sending probes is 
not any worse than if a participant simply acted.  Unfortunately there is a 
higher cost in that all the remote servers have to respond to the probe.  It 
might be interesting if there were a way to just send a harmless stanza out 
to all participants without expecting a reply.

That said, discovering s2s trouble is only part of the problem.  If my server 
reboots when I'm in a MUC, then it is entirely possible that the MUC might 
not try to contact me during the 2 minutes the server was down.  Even if the 
MUC were probing on an interval, it may miss this window.  I believe all 
joins, leaves, status changes, and messages will then still be sent to me 
without any error.  Messages might even be stored offline (ick).  One 
solution would be for these stanzas to be bounced by my server, if it does 
not believe the remote entity has my presence.  I think this would be a cool 
privacy solution in general, for pretty much all stanzas.  A probe, however, 
would work regardless of that presence-as-firewall policy.

I agree polling sucks, but I don't think it's any worse here than polling 
broadcast presence, and there's a lot more of that.

-Justin

---

From: Pedro Melo <[email-masked]>
Date: Fri, 29 Jan 2010 11:09:05 +0000

Hi,

> suggest that all of the participants be sent /something/ to induce a bounce.

Agreed, but /something/ need not be a presence probe, given that you
would be asking the wrong question.

With a presence probe you are asking "are you still online?", but what
you want is "are you still connected to this room?".

Having said that, I don't see how probing a full JID is more
problematic than probing a bare jid. The risk that Peter mentions of
pooling presence status is present on both cases.

Bye,
-- 
Pedro Melo
http://www.simplicidade.org/
xmpp:[email-masked]
mailto:[email-masked]

---

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

On 1/29/10 4:09 AM, Pedro Melo wrote:
> problematic than probing a bare jid. 

Because no servers do that now and it's not clear to me how they would
handle it.

> The risk that Peter mentions of

Right, your server could always poll on your behalf, although that is
not the way servers work now (and it seems that we might want to
discourage that behavior in the text).

More fundamentally: what is the problem we're trying to solve here? If
it's only MUC ghosts then I think we can address that in XEP-0045, which
is currently being reviewed on the [email-masked] list. If it's a broader
problem with directed presence as such, then let's figure out what the
problem really is. One point about directed presence that came up
recently is the fact that after I send you directed presence, my server
will not send you subsequent presence updates that I generate, it will
send you only my unavailable presence at the end of my presence session.
That means my client needs to directly send you the interim presence
updates. Is that a problem we need to solve? It seems simpler for the
server to send you my interim presence updates, and that might help with
directed presence in general. But I'd like to be clear on the problem
before saying that probing full JIDs is a good idea.

Peter

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

---

From: Pedro Melo <[email-masked]>
Date: Fri, 29 Jan 2010 15:22:21 +0000

Hi,

> Because no servers do that now and it's not clear to me how they would

Yes, I don't see an obvious meaning.

> is currently being reviewed on the [email-masked] list.

+1. As I said above, if this is for MUC, I also agree that it should
be dealt inside 45, not here.

> If it's a broader

How directed presences work (like a one-shot query, or as a
per-session presence subscription) is I think the subject for another
thread.

I don't have a problem with the current text. I don't think we should
allow this to solve the MUC problem.

Bye,

---

From: Justin Karneges <[email-masked]>
Date: Fri, 29 Jan 2010 10:21:51 -0800

On Friday 29 January 2010 03:09:05 you wrote:
> > Any sent stanza acts as a probe here, at least for discovering s2s
> > connection errors.  If enough time passes in a room and nobody has
> > joined, changed status, left, or sent a message, then it's probably not
> > unreasonable to suggest that all of the participants be sent /something/
> > to induce a bounce.
>

Actually the presence probe is the right question.  That is the one which 
asks, "are you still connected to this room?" because it finds out if the 
user's server still believes the MUC is allowed to have the user's presence.

If we want to ask the lesser question: "are you still online?", then I suggest 
the MUC send the user's own presence again to himself.  Maybe this the 
harmless one-way communication we can suggest in XEP-0045?

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 29 Jan 2010 13:43:54 -0700

> harmless one-way communication we can suggest in XEP-0045?

Hmm, it seems that version -03 of 3921bis already contained this text:

   If a server receives a presence probe intended for a full JID
   <contact@domain/resource>, it SHOULD handle it on behalf of the
   connected resource by returning only the presence information for
   that particular resource (and in any case MUST NOT deliver it to the
   resource).

I can't even read my own specs...

Peter

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

---

From: Waqas Hussain <[email-masked]>
Date: Sat, 30 Jan 2010 03:07:26 +0500

> I can't even read my own specs...

FWIW, I didn't remember that being there before this thread started until I
reread that section yesterday. I didn't point it out because I assumed it
was just me. I like that text :)

--
Waqas Hussain

---

From: "Ben Schumacher" <[email-masked]>
Date: Fri, 29 Jan 2010 15:34:21 -0800

> every minute to see if you're still online? That doesn't seem like a

Not to mention that we have the issue of know who's responsible for 
responding to the probes. Typically that's handled by the server -- 
doesn't this mean my local server may need to track which rooms I've 
joined on a remote service? This would be required for authorizing the 
probe, would it not? Seems like a potential DoS to me.

Or shall we forward these probes onto the client? What happens if the 
plug was pulled on my laptop? Or my wireless connection died?

Ben

---

From: Justin Karneges <[email-masked]>
Date: Sun, 31 Jan 2010 12:44:32 -0800

> probe, would it not? Seems like a potential DoS to me.

It already has to do this, so that if the client goes unavailable the server 
can send unavailable presence to all JIDs that have received directed 
presence earlier.

-Justin