[Standards] UPDATED: XEP-0199 (XMPP Ping)

Mridul Muralidharan mridul at sun.com
Wed May 9 18:46:26 UTC 2007

Justin Karneges wrote:
> On Wednesday 09 May 2007 10:39 am, Mridul Muralidharan wrote:
>> Peter Saint-Andre wrote:
>>> Mridul Muralidharan wrote:
>>>> Ah, I see that the type=probe is not present in the presence packet :
>>>> my mistake, thanks for clarifiyng !
>>> In fact that's a typo, there should be a type='probe' in one of the
>>> examples.
>> Hmm, in which case aren't we not back to any entity using probe instead
>> of only servers ?
> This example is of a room (or room's server) doing a probe.  Clients are still 
> not supposed to probe.

Any entity != server implies clients, components, etc.
probe is a mechanism for servers to discover presence - I dont see how 
it makes sense for directed presence case.

>>> That shows an example of a server returning presence information in
>>> response to a probe from an entity with which a user has shared directed
>>> presence. I think the SHOULDs there are not necessary (the chat service
>>> SHOULD send a probe blah blah blah, whether that is recommended is a
>>> matter for XEP-0045.)
>> Why use probe for this in the first place ?
>> The room is only interested in a particular full jid - not any/every
>> resource of the bare jid.
> Then probes just the full jid.  The flow should could use some more clarity:
> Client joins room:
> <presence from='romeo at example.net/orchard'
>         to='shakespeare at chat.example.com/RM'>
>   <status>working</status>
> </presence>
> Room (or room's server) probes presence:
> <presence from='shakespeare at chat.example.com/RM'
>         to='romeo at example.net/orchard'/>
> Server responds positively:
> <presence from='romeo at example.net/orchard'
>         to='shakespeare at chat.example.com/RM'>
>   <status>working</status>
> </presence>
> Or not:
> <presence from='romeo at example.net/orchard'
>         to='shakespeare at chat.example.com/RM'
>         type='unavailable'/>

And how is this different from xmpp ping ? Except for being e2e - which 
is just one hop more in this case.
There seems to be no need for introducing this in the rfc when we have 
xep's to handle this corner case.

>>  From what I recall, the primary motivation was for the purpose of
>> discovering if the remote endpoint is mia : and xmpp ping seems to be
>> better suited for this than probe.
> The presence probing is different because it is by hop.
> C1 - S1 - S2 - C2
> If C2 sends directed presence to C1, then S1 could probe S2 periodically about 
> the state of that presence.  C2 would not be resending presence.  A ping 
> would go all the way to C2 (unless we made S2 also respond to pings on behalf 
> of clients, but then I think that might defeat the spirit of pings, which are 
> meant to be e2e).

Why should it periodically probe for status ? probe was not intended for 
this imo.
The rfc already handles the case of user going offline without sending 
(directed) unavailable presence (to contact(s)).

>> Is there any other reason why we need this special casing of probe in
>> face of directed presence ? I cant seem to recall any.
>> (Server's will not normally probe these entities).
> It's not really a special-casing so much as a completing of the protocol.  It 
> allows directed presence to be probed about just like broadcasted presence.  
> It's an un-special-casing. :)

Yes, but why do we need it ?
And since servers wont probes entries - why introduce it ?

>> Only implementations requiring xmpp ping would use it - why do we need
>> similar protocols for the same intent ?
>> Considering how simple xmpp ping is, I am sure it will catch on fast :
>> and the usefulness is really good (unless implementations go overboard
>> with pinging).
> To be honest, I see xmpp ping more as a diagnostic tool or a stopgap.

I think it is useful in tackling ghost users in servers, muc's. and in 
other cases.
As I mentioned to Peter, xep 198 (for s2s) will make sure that servers 
can recover (otherwise) lost stanza's and xmpp ping will make sure that 
user's going mia is detected asap.


> -Justin

More information about the Standards mailing list