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

Mridul Muralidharan mridul at sun.com
Wed May 9 17:39:44 UTC 2007

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 ?

>> But that addition 4.6 is what I am caught up about 
> Oh, sorry, I didn't know what you were referring to, which is:
> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3921bis-02.html#presence-directed 
> 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.
Using xmpp ping for this seems to be the right usage - along with 
tightening 'probe' : or is there something I am missing ?

>> - doesn't the example in that section have the same intent as ping - 
>> check for connectivity of the user ? [*] So wont xmpp ping not be a 
>> superset of that directed presence usecase ?
> The only point of those examples is to show that a server should answer 
> a probe in that case (because the user sent directed presence). Whether 
> ping is a better way to check connectivity or availability is another 
> question.

Yes, but why allow probe in the first place from anything other than 
servers ?
 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.
We could entirely drop that section of the bis spec. Hence - no probes 
will be issued at all for any case and that special case handling could 
be removed.
Endpoints wanting to ping would use xmpp ping - and server will use [1] 
for the purpose of notifying directed presence updates when the entity 
disconnects/goes offline.

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).

[1] http://www.xmpp.org/rfcs/rfc3921.html#presence-resp-directed 
(section 5.1.4, point 2).

>> If yes, why not remove that section and recommend use of xmpp ping for 
>> that usecase ? (assuming ping xep becomes draft before 3921 bis).
> We would NOT recommend XEP-0199 there because that's not the focus of 
> that section. But we MIGHT recommend XEP-0199 from XEP-0045. However, 
> the nice thing about presence probes in this case is that they would 
> work today, they don't depend on implementation and deployment of 
> XEP-0199, and in any case room joining and leaving is done with presence 
> right now in MUC so using presence this way seems appropriate. However, 
> that is NOT a matter for rfc3921bis to recommend or not.

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).
That way, we would keep rest of the xep's/rfc's (muc included) agnostic 
to how to go about pinging - if impl's require is, they could use 
xmpp-ping as an impl detail.

> Peter

More information about the Standards mailing list