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

[Jiří Zárevúcky <zarevucky.jiri at gmail.com>]

Justin Karneges píše v Po 01. 02. 2010 v 16:48 -0800:
> 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.
> 
> [...]

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.

Attachment: signature.asc
Description: Toto je =?UTF-8?Q?digit=C3=A1ln=C4=9B?= =?ISO-8859-1?Q?_podepsan=E1?= =?UTF-8?Q?_=C4=8D=C3=A1st?= =?ISO-8859-1?Q?_zpr=E1vy?=