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

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 06 Mar 2010 20:02:33 -0700

On 2/11/10 3:38 PM, Peter Saint-Andre wrote:
> On 2/4/10 7:23 AM, Jiří Zárevúcky wrote:
>> Peter Saint-Andre píše v St 03. 02. 2010 v 21:10 -0700:
>>> On 2/3/10 7:04 PM, Jiří Zárevúcky wrote:
>>>> 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:
>>>>>
>>>>>> 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?
>>>
>>> Well, that's the identifier for the data generated by the user. I don't
>>> 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.
> 
> 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...

I've attempted to clarify the situation in my working copy by adding the
following note to the section on "Server Processing of Inbound Presence
Probe" (4.3.2):

***

Note: The handling of the 'id' attribute in relation to presence probes
was unspecified in the predecessor to this specification. Although the
pattern of "send a probe and receive a reply" might seem like a
request-response protocol, in fact it is not because the response to a
probe might consist of multiple presence stanzas (one for each available
resource currently active for the contact). For this reason, if the
contact currently has available resources then the contact's server
SHOULD preserve the 'id' attribute of the contact's original presence
stanza (if any) when sending those presence notifications to the probing
entity; however, if the contact currently has no available resources,
the probing entity is not authorized (via presence subscription) to see
the contact's presence, or an error occurs in relation to the proble,
then the contact's server SHOULD mirror the 'id' of the presence probe
when replying to the probing entity.

***

Peter

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