moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 09:42:20 -05:00
Code Issues Releases Wiki Activity

1.1rc1

Browse Source
This commit is contained in:
Peter Saint-Andre 2012-06-19 09:31:08 -06:00
parent 22fbcf2c4b
commit 3a0c66b240
1 changed files with 15 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
xep-0144.xml
View File

@ -11,6 +11,7 @@
&LEGALNOTICE; &LEGALNOTICE;
<number>0144</number> <number>0144</number>
<status>Draft</status> <status>Draft</status>
<interim/>
<type>Standards Track</type> <type>Standards Track</type>
<sig>Standards</sig> <sig>Standards</sig>
<dependencies> <dependencies>
@ -26,6 +27,12 @@
<url>http://www.xmpp.org/schemas/rosterx.xsd</url> <url>http://www.xmpp.org/schemas/rosterx.xsd</url>
</schemaloc> </schemaloc>
&stpeter; &stpeter;
<revision>
<version>1.1rc1</version>
<date>in progress, last updated 2012-06-19</date>
<initials>psa</initials>
<remark>Clarified use of message vs. IQ and full JID vs. bare JID; removed IQ handling rules, which are specified in RFC 6120.</remark>
</revision>
<revision> <revision>
<version>1.0</version> <version>1.0</version>
<date>2005-08-26</date> <date>2005-08-26</date>
@ -201,24 +208,14 @@
</iq> </iq>
]]></example> ]]></example>
</section1> </section1>
<section1 topic='Recommended Stanza Type' anchor='stanza'> <section1 topic='Stanza Types' anchor='stanza'>
<p>If the sending entity has knowledge (e.g., via presence or an active chat conversation) that the receiving entity is online and available, it SHOULD: <note>If the receiving entity has more than one available resource, the sending application SHOULD communicate with the "most available" resource according its best estimation (e.g., the resource with the highest priority).</note></p> <p>Roster item exchanges can be sent in any of the four following ways:</p>
<ol> <ul>
<li>Discover if the receiving entity supports the protocol defined herein (see the <link url='#disco'>Service Discovery</link> section of this document).</li> <li><p>In an &IQ; stanza to a full JID &LOCALFULL;. This is appropriate if the sender has knowledge (e.g., via presence and &xep0115;) that a particular resource associated with the recipient is online and supports this protocol.</p></li>
<li>If so, send its roster item exchange stanza to a particular resource (user@host/resource) of the receiving entity using an &IQ; stanza rather than a &MESSAGE; stanza.</li> <li><p>In an &IQ; stanza to a bare JID &LOCALFULL;. This can be appropriate if the sender wants the roster item to be processed by the server on behalf of the recipient (e.g., if the sender is a trusted component of the server).</p></li>
</ol> <li><p>In a &MESSAGE; stanza to a bare JID &LOCALBARE;. This can be appropriate if the sender wants the roster item to be delivered to all of the recipient's online resources (e.g., because the sender does to have presence or capabilities information about particular resources).</p></li>
<p>If the sending entity does not know that the receiving entity is online and available, it MUST send a &MESSAGE; stanza to the receiving entity's "bare JID" (user@host) rather than an &IQ; stanza to a particular resource.</p> <li><p>In a &MESSAGE; stanza to a full JID &LOCALFULL;. This is generally undesirable, since it is better to se an &IQ; stanza when sending to a full JID (e.g., IQ stanzas are automatically acknowledged).</p></li>
<section2 topic='IQ Semantics' anchor='stanza-iq'> </ul>
<p>If the sending entity uses &IQ; stanzas to communicate its roster item exchange suggestions, the receiving entity MUST adhere to the IQ semantics defined in &xmppcore;. Specifically:</p>
<ol>
<li>If the receiving entity successfully processes the suggested action(s) (which may include ignoring certain suggestions), the receiving entity MUST return an empty IQ result to the sending entity.</li>
<li>If the receiving entity does not understand the roster item exchange namespace, the receiving entity MUST return an error to the sending entity, which error SHOULD be &unavailable;.</li>
<li>If the receiving entity will not process the suggested action(s) because the receiving entity is not registered with the sending entity, the receiving entity MUST return an error to the sending entity, which error SHOULD be &registration;.</li>
<li>If the receiving entity will not process the suggested action(s) because the sending entity is not in the receiving entity's roster, the receiving entity MUST return an error to the sending entity, which error SHOULD be &notauthorized;.</li>
<li>If the receiving entity will not process the suggested action(s) because the sending entity is not trusted (see <link url='#security-trust'>Trusted Entities</link>), the receiving entity MUST return an error to the sending entity, which error SHOULD be &forbidden;.</li>
</ol>
<p>Naturally, other IQ errors may be more appropriate; however, if the receiving entity will not or cannot process the suggested action(s), it MUST return an error to the sending entity.</p>
</section2>
</section1> </section1>
<section1 topic='Business Rules' anchor='bizrules'> <section1 topic='Business Rules' anchor='bizrules'>
<ol> <ol>