On 10.04.2018 15:08, Georg Lukas wrote:
> * Georg Lukas <ge...@op-co.de> [2017-10-04 10:21]:
>> 2. Create a new, explicit am-I-joined IQ that a client can send to the
>> MUC JID.
> This seems to be the winner of the discussion from last October, even
> though it was qualified as a "sticking plaster".
> To keep with the "sticking plaster" qualification, I propose to
> implement it as an XEP-0199 ping to the participant's own full-JID:
> <iq from='jul...@capulet.lit/balcony'
> to='co...@chat.shakespeare.lit/thirdwitch' id='c2s1' type='get'>
> <ping xmlns='urn:xmpp:ping'/>
> (assuming here that Juliet is [impersonating] the third witch in the MUC)
> The MUC would then intercept the <ping/> and respond directly, instead
> of routing the IQ to a random resource of Juliet's. If Juliet is joined
> as 'thirdwitch', the MUC will directly respond with a result IQ.
That's probably fine.
> Juliet is not joined, the MUC will respond with <not-acceptable/>.
I feel like this is missing "or if the ping request does not originate
from Juliet". Or is this intentional?
I personally would probably not re-use xep199 for this, but define new
IQ. That is mostly because I don't know which two code paths you mean here:
> - clients don't need two different code paths depending on a
> 'self-ping-supported' feature
Care to elaborate?
Standards mailing list