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

[Justin Karneges <[e-mail]>]

On Monday 01 February 2010 13:31:18 Peter Saint-Andre wrote:
> On 2/1/10 2:09 PM, Peter Saint-Andre wrote:
> > On 2/1/10 12:56 PM, Ben Schumacher wrote:
> >> On 02/01/2010 12:29 PM, Justin Karneges wrote:
> >>> 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.
> >>
> >> 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.
> >
> > 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.
>
> 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).

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