MUC ghosts (was: Re: [Standards] UPDATED: XEP-0199 (XMPP Ping))

Peter Saint-Andre stpeter at jabber.org
Wed May 9 18:16:43 UTC 2007


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 ?

Yes, any entity MAY probe. That was true in RFC 3920 and so far it is 
true in rfc3920bis. Are you suggesting that we change that? I'm not 
deeply opposed to the idea.

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

Mridul and I had an IM chat about this and I think he's right that this 
directed presence use case is misguided. At least, a MUC service that 
depends on presence information would receive unavailable presence from 
the user's server. Naturally the user's server is responsible for 
figuring out if the user cut a network cable but that is the server's 
problem, not the MUC service's problem.

So I think it would be best to remove this use case from rfc3921bis.

Peter

-- 
Peter Saint-Andre
XMPP Standards Foundation
http://www.xmpp.org/xsf/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070509/ed54e61e/attachment.bin>


More information about the Standards mailing list