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

From: Ben Schumacher <[email-masked]>
Date: Mon, 01 Feb 2010 11:57:53 -0700

On 01/31/2010 01:44 PM, Justin Karneges wrote:
>> 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.
>>      
> 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, Matthew-

I'm afraid I wasn't clear enough in my earlier email.

Which presence do you expect the server to send in this condition? The 
most recently sent undirected presence? Seems like a information leak to 
me. When I've sent you directed presence I haven't authorized you to see 
my presence status, I've provided you with a specific picture of my 
presence.

Those are two entirely different things. There's a reason that you're 
required to send presence updates if you change status/show/etc to MUC 
rooms and that the server doesn't do this for you on your behalf.

Cheers,
Ben

---

From: Matthew Wild <[email-masked]>
Date: Mon, 1 Feb 2010 19:03:52 +0000

On 1 February 2010 18:57, Ben Schumacher <[email-masked]> wrote:
> Which presence do you expect the server to send in this condition?

As I said, the unavailable presence:
http://tools.ietf.org/html/draft-ietf-xmpp-3921bis-03#section-4.6.2

Matthew

---

From: Justin Karneges <[email-masked]>
Date: Mon, 1 Feb 2010 11:29:12 -0800

On Monday 01 February 2010 10:57:53 Ben Schumacher wrote:
> > 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, Matthew-
>

Basically, the server should return the most recently sent presence to the JID 
doing the probing, whether directed or undirected.  So, no, if you send me 
directed presence and then I probe you, I would not expect to receive 
your "real" (undirected) presence.

-Justin

---

From: "Ben Schumacher" <[email-masked]>
Date: Mon, 1 Feb 2010 11:56:15 -0800

On 02/01/2010 12:03 PM, Matthew Wild wrote: 

	
	Matthew

Thanks for the URL, but I think you're still missing the point.

I assume your intention is not to suggest that the server should a) always reply "unavailable" -- even when the user is available, or b) have no response in the case that the user is available, but it seems you're forgetting the positive case.

I'll also point out that typically servers only track the folks you've sent presence to as long as your session is active (why would it need to do so after you've logged off?) -- so this isn't really a solution. Consider the following use case:

1.	[email-masked]/Mobile (short handing this as 'user1/Mobile' later) joins the MUC room [email-masked]
2.	flaky-server.com's session manager dutifully tracks that user1/Mobile has sent presence to [email-masked].
3.	An unfortunate deref of NULL in flaky-server.com's S2S causes it to crash.
4.	user1's battery dies -- killing his session in the process.
5.	flaky-server.com's session manager sends the appropriate unavailable, but that S2S instance is still down.
	
6.	flaky-server.com's admin gets the S2S instance back up.
7.	[email-masked] gets some indication that the connection to flaky-server.com comes back online and decides to probe for the "ghost".
8.	flaky-server.com's session manager has no record of [email-masked] in user1/Mobile's roster silently drops the probe. http://tools.ietf.org/html/draft-saintandre-rfc3921bis-08#section-11

Now you could argue that in #8 the server might want to respond, but I personally would err on the side of trying to protect the server from dictionary attacks by not responding.

Cheers,
Ben

---

From: Ben Schumacher <[email-masked]>
Date: Mon, 01 Feb 2010 12:56:54 -0700

> your "real" (undirected) presence.

Therein lies the rub. I do not want to have to shove ever presence sent 
into a DB, DHT, whatever to meet these requirements. Hence the point of 
the recommendation re: probe + unavailable.

Ben

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Feb 2010 14:09:08 -0700

> the recommendation re: probe + unavailable.

Yes, that seems onerous.

Currently, the server needs to keep track of whether another entity is
on the list for receiving unavailable presence for a given resource. The
server will remove an entity from that list if the user sends directed
unavailable presence to the entity. So the server knows if it can send
<presence/> (no details like show or status or priority) to an entity,
and perhaps that is the best thing for it to return to the entity if it
probes the full JID.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 01 Feb 2010 14:31:18 -0700

> and perhaps that is the best thing for it to return to the entity if it

How is this text?

   If the contact's server receives a presence probe addressed to a full
   JID of the contact, the server MUST NOT return presence information
   about any resource except the resource specified by the 'to' address
   of the probe.  Rules #1 and #2 for a bare JID probe apply equally to
   the case of a full JID probe.  If there is a resource matching the
   full JID and (a) the probing entity has authorization via a presence
   subscription to see the contact's presence or (b) the contact has
   sent directed available presence to the probing entity, then the
   server MUST return an available presence notification, which SHOULD
   communicate only the fact that the resource is available (not
   detailed information such as the <show/>, <status/>, <priority/>, or
   presence extensions).

Peter

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

---

From: Justin Karneges <[email-masked]>
Date: Mon, 1 Feb 2010 16:48:39 -0800

>    detailed information such as the <show/>, <status/>, <priority/>, or

Hmm, I'm okay with where you're going with this, but it is strange that the 
presence returned here has a different meaning than it would in normal 
circumstances.  I'm imagining a race condition where someone updates their 
directed presence to you right as you perform a probe on them.  Now when you 
receive their presence, you'll think it is a reply to the probe, meaning that 
the user is still online but you'll otherwise discard the details of the 
presence packet.  Then the probe is received by the contact's server and 
processed, and an empty presence is returned back to you, which you'd then 
process as a typical directed presence update.  Oops.

The simplest solution from a protocol perspective is to always return correct 
presence.  It's what you'd naturally expect, and it makes everything work 
too.  But I understand that some server developers might not want to do that.

I hate to make this seem more complicated by introducing new XML, but one idea 
is to have:
  <presence to="probing_entity">
    <unchanged/>
  </presence>

Then the meaning of received presence is always clear.  It would be at the 
server's option to reply either with <unchanged/> or with the complete 
presence details.

-Justin

---

From: Jiří Zárevúcky <[email-masked]>
Date: Tue, 02 Feb 2010 15:17:02 +0100

Justin Karneges píše v Po 01. 02. 2010 v 16:48 -0800:
> [...]

What about using the 'id' attribute? The spec should perhaps say that if
probe has an id set, response to that probe should mirror it.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Feb 2010 17:38:08 -0700

> probe has an id set, response to that probe should mirror it.

Presence probes are not IQs. :)

If I probe for your presence, wouldn't I get back your latest presence
with whatever ID you included in your presence broadcast?

Juliet: <presence id='foo'/>

Romeo: <presence id='bar' to='juliet'/>

Juliet: <presence from='juliet' to='romeo' id='foo'/>

/psa

---

From: Jiří Zárevúcky <[email-masked]>
Date: Thu, 04 Feb 2010 03:04:09 +0100

> Juliet: <presence from='juliet' to='romeo' id='foo'/>

Well, the spec currently says the response must be a full XML that the
contact sent to it's server.

I don't know but I think it is not that good to require resending
strictly everything. How useful is an ID in a probe response?

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Feb 2010 21:04:29 -0700

> process as a typical directed presence update.  Oops.

I hadn't considered that scenario.

> The simplest solution from a protocol perspective is to always return correct 

What is "correct"? I assume you mean that my server needs to keep track
of the current presence state for each entity to which I've sent
directed presence. (RFC 2778 doesn't have a term for such an entity;
I'll coin the term "receiver".)

> It's what you'd naturally expect, and it makes everything work 

Currently, most or even all XMPP servers add each receiver to a list of
entities that need to receive my unavailable presence. But servers don't
keep track of which presence I've sent to which receiver, and adding
that requirement would, I think, be fairly onerous because servers would
need to store each directed presence stanza in a database or somesuch.

> server's option to reply either with <unchanged/> or with the complete 

It's not clear to me how that would help -- the server would still need
to keep track of what it has sent, indeed it wouldn't necessarily know
what the receiver has in fact received so the receiver would need to
send its current idea of the sender's presence along with its probe.
Either that or we'd need "presence versioning". Ick.

I don't love the idea of sending mere available presence in response to
a probe to the full JID. The best I can see is that we could
differentiate between probes from subscribers (send the current
presence) and probes from receivers (send mere available presence).
That's not beautiful, but it would be consistent with all current
implementations. Another option is to let receivers see the real current
presence (not the last directed presence sent from the sender to the
receiver), but that seems like a presence leak to me.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 03 Feb 2010 21:10:40 -0700

> strictly everything. How useful is an ID in a probe response?

Well, that's the identifier for the data generated by the user. I don't
see a good reason to throw that identifier away.

Peter

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

---

From: Jiří Zárevúcky <[email-masked]>
Date: Thu, 04 Feb 2010 15:23:50 +0100

> see a good reason to throw that identifier away.

That you don't see it doesn't mean it doesn't exist. That's why I'm
saying the spec is too restrictive in this regard.
For example, server may want to filter presence extensions based on some
not-yet-written XEP. This isn't specific to ID's.

So, the right question should be: is there a good reason to never allow
it at all? I don't think so.

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 10 Feb 2010 18:27:09 -0700

>    detailed information such as the <show/>, <status/>, <priority/>, or

I know I'm late to the party, and sorry to beat a dead horse, but it's
likely that b) above would break the next-gen MUC stuff that we've been
talking about.  I envision wanting to send different caps to rooms than I
broadcast, and the empty presence might cancel implicit PEP subscriptions
that I got with that differentiated caps.

-- 
Joe Hildebrand
(as individual)

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Feb 2010 21:24:19 -0700

> that I got with that differentiated caps.

So don't probe. :)

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Feb 2010 15:38:00 -0700

> it at all? I don't think so.

I've been thinking about this issue some more, in particular the meaning
of a presence probe.

One reason why people want to a definitive answer to a probe is that it
feels like a request-response protocol: you probe my server for my
presence and you hope to receive either "available" or "unavailable". In
that sense, the following exchange feels right:

<presence from='you' id='foo' to='me' type='probe'/>

<presence from='me' id='foo' to='you'/>

NOT

<presence from='me' id='bar' to='you'/>

(if "bar" was the ID of my last presence stanza)

This seems to be consistent with the handling of probe-related error
such as the one we discussed at XMPP Summit #8 in Brussels over the
weekend (I have changed JIDs so you receive a redirect error):

<presence from=[email-masked]' id='foo' to=[email-masked]'
type='probe'/>

<presence from=[email-masked]' id='foo' to=[email-masked]'
type='error'>
  <error type='modify'>
    <redirect xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
      xmpp:[email-masked]
    </redirect>
  </error>
</presence>

On the other hand, if I send outbound presence with an ID then I might
expect to receive some helpful error handling after it is broadcast to
my contacts:

<presence id='baz'><show>away</show></presence>

[broadcast to everyone in my roster]

<presence from=[email-masked]' id='baz' to=[email-masked]'
type='error'>
  <error type='cancel'>
    <remote-server-not-found
            xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</presence>

The disconnect here seems to be that in the cases we're discussing,
presence is not real-time but store-and-forward (it would be strange to
receive an error stanza related to a notification I generated hours
ago). Furthermore, we don't necessarily expect presence errors to return
to the entity that generated the notification (instead they might be
handled by the entity's server). This gets into issues like "bounce
processing" of presence notifications, which we've never discussed.

Further thought required...

Peter

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