[Standards] [Fwd: [Council] meeting minutes, 2007-05-16]

Mridul Muralidharan mridul at sun.com
Thu May 17 23:23:44 UTC 2007

Mridul Muralidharan wrote:
> Peter Saint-Andre wrote:
>> Mridul Muralidharan wrote:
>>> About 199 handling of IQ's from proposal and log.
>>> That is a problem we are hitting time and again - different specs 
>>> seem to be doing different things regarding iq responses for requests 
>>> which they dont want to handle.
>>> The response for an entity which does not exist, that is not 
>>> available, which has blocked sender, which does not support that 
>>> service (does not understand request/namespace), which does not want 
>>> to respond so as to avoid privacy leaks - for different set of 
>>> usecases, each of these would result in a different error code back.
>>> So, careful monitoring of responses can actually be used to leak 
>>> presence of a user (assuming he uses a well known resource and not 
>>> random resource).
>>> Which ever way we handle it - I am not at all comfortable with 
>>> server/component/client ignoring iq packets and not responding to them.
>>> It would be better if we fix this and get the client to respond back 
>>> to sender appropriately such that there is no presence leak and yet 
>>> sender does not know if the server/client is responding back with an 
>>> error.
>> How can a client respond without revealing its resource? Does it tell 
>> its server "please send back service-unavailable from my bare JID"?
>> Peter
> Response can have 'from' set to bare jid so that requester cant make out 
> if this is the contact's server or contact sending the response.

This need not work.
I hit send a bit too fast :-)

> Regards,
> Mridul

Client could just send with response with 'from' set to the full jid - 
the server would do the same if the recepient was unavailable, was 
blocking, etc.
The 'presence' of the full jid will not be revealed in this case 
(request was for a full jid anyway).

The conflicting responses (error code, etc) is what will reveal if the 
server is sending a response, server blocked on behalf of client, client 
blocked (so as not to reveal presence), etc.


More information about the Standards mailing list