moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-22 01:02:17 -05:00
Code Issues Releases Wiki Activity

revised text re: presence leaks

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@313 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-06 02:25:54 +00:00
parent ffc0214666
commit 87b9844afc
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0155.xml
View File

@ -587,7 +587,7 @@ PENDING o---------------+
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<section2 topic='Presence Leaks' anchor='secure-leak'> <section2 topic='Presence Leaks' anchor='secure-leak'>
<p>If a contact accepts a user's chat session negotiation request or returns an error to the user, the user will effectively discover the presence of the contact's resource. Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT <em>automatically</em> (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Note: There should be no need for the contact's client to consult the contact's block list, since if the user is on the list then the contact would not receive any request messages from the user anyway.</p> <p>If a contact does not share its presence information with a user through a presence subscription (see <cite>RFC 3921</cite>) or if it blocks outbound presence notifications to the user (see &xep0016;), then it will effectively expose its presence if it accepts the user's chat session negotiation request or returns an error to the user. Therefore, due care must be exercised in determining whether to accept the request or return an error. The contact's client SHOULD NOT automatically (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribed to the contact's presence and the contact is not blocking outbound presence notifications to the user. Note: There should be no need for the contact's client to consult the contact's block list (see &xep0191;), since if the user is on the block list then the contact would not receive the request from the user in the first place.</p>
</section2> </section2>
<section2 topic='Localization' anchor='secure-local'> <section2 topic='Localization' anchor='secure-local'>
<p>If a client is configured to show a request &lt;form/&gt; to a human user instead of responding automatically, it SHOULD replace the content of the &lt;title/&gt; element and of all label attributes of the known and registered &lt;field/&gt; and &lt;option/&gt; elements with its own localised versions before showing the form to the user -- even if the form already appears to be in the correct language.</p> <p>If a client is configured to show a request &lt;form/&gt; to a human user instead of responding automatically, it SHOULD replace the content of the &lt;title/&gt; element and of all label attributes of the known and registered &lt;field/&gt; and &lt;option/&gt; elements with its own localised versions before showing the form to the user -- even if the form already appears to be in the correct language.</p>