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

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

Peter Saint-Andre píše v St 03. 02. 2010 v 17:38 -0700:
> On 2/2/10 7:17 AM, Jiří Zárevúcky wrote:
> > 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.
> 
> 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
> 

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?

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?=