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

Peter Saint-Andre stpeter at jabber.org
Fri May 18 16:21:49 UTC 2007

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 Saint-Andre
XMPP Standards Foundation

-------------- 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/20070518/1f1f426f/attachment.bin>

More information about the Standards mailing list