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

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


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.

Regards,
Mridul



More information about the Standards mailing list