moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

0.8 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2145 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-08-08 01:35:21 +00:00
parent d56e418e52
commit ad58687c65
1 changed files with 31 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
xep-0231.xml
View File

@ -26,6 +26,12 @@
<shortname>NOT_YET_ASSIGNED</shortname>
&stpeter;
&pavlix;
<revision>
<version>0.8</version>
<date>2008-08-07</date>
<initials>psa/ps</initials>
<remark><p>Added section on determining support.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2008-08-06</date>
@ -219,6 +225,31 @@
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If an entity supports the protocol specified herein, it MUST advertise that fact by returning a feature of "urn:xmpp:tmp:bob" in response to &xep0030; information requests &NSNOTE;.</p>
<example caption="Service discovery information request"><![CDATA[
<iq from='doctor@shakespeare.lit/pda'
id='disco1'
to='ladymacbeth@shakespeare.lit/castle'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service discovery information response"><![CDATA[
<iq from='ladymacbeth@shakespeare.lit/castle'
id='disco1'
to='doctor@shakespeare.lit/pda'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
...
<feature var='urn:xmpp:tmp:bob'/>
...
</query>
</iq>
]]></example>
<p>In order for an application to determine whether an entity supports this protocol, where possible it SHOULD via the dynamic, presence-based profile of service discovery defined in &xep0115;. However, if an application has not received entity capabilities information from an entity, it SHOULD use explicit service discovery instead.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>The ability to include arbitrary binary data implies that it is possible to send scripts, applets, images, and executable code, which may be potentially harmful. To reduce the risk of such exposure, an implementation MAY choose to not display or process such data but instead either completely ignore the data, show only the value of the 'alt' attribute, or prompt a human user for approval (either explicitly via user action or implicitly via a list of approved entities from whom the user will accept binary data without per-event approval).</p>
<p>The recipient MUST cache data based on the sender's JabberID; this helps to avoid data poisoning attacks.</p>