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

Mridul Muralidharan mridul at sun.com
Fri May 18 17:57:49 UTC 2007

Peter Saint-Andre wrote:
> Peter Saint-Andre wrote:
>> On Fri, May 18, 2007 at 04:53:44AM +0530, Mridul Muralidharan wrote:
>>> Mridul Muralidharan wrote:
>>> 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).
>> Ah, I see what you're saying, the server would simply swap the from and
>> to, and the original sender would not know the difference.
>>> 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.
>> Right. We'll clean that up before XEP-0199 goes for a vote.
> How is this for text in the Security Considerations?
> ******
> If a server receives a ping request directed to a full JID 
> (<node at domain.tld/resource>) associated with a registered account but 
> there is no connected resource matching the 'to' address, it MUST reply 
> with a <service-unavailable/> error and set the 'from' address of the 
> IQ-error to the full JID provided in the 'to' address of the ping 
> request. If a connected resource receives a ping request but it does not 
> want to reveal its network availability to the sender for any reason 
> (e.g., because the sender is not authorized to know the connected 
> resource's availability), then it too MUST reply with a 
> <service-unavailable/> error. This consistency between the server 
> response and the client response helps to prevent presence leaks.
> ******
> Peter

Perfect !

A small queey - If the ping comes to a user's bare jid - what is the 
server expected to do ? Can we disallow that since pings are e2e ?


More information about the Standards mailing list