moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

0.23

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1570 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-01-11 22:42:55 +00:00
parent 0ab49d3b52
commit 364d8530e8
1 changed files with 33 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
xep-0166.xml
View File

@ -26,6 +26,12 @@
&robmcqueen;
&seanegan;
&hildjj;
<revision>
<version>0.23</version>
<date>2008-01-11</date>
<initials>psa</initials>
<remark><p>Removed content-accept after content-remove; removed errors for unsupported-content and unsupported-transports since they are handled via session-terminate; clarified handling of responder attribute.</p></remark>
</revision>
<revision>
<version>0.22</version>
<date>2007-12-06</date>
@ -460,7 +466,7 @@ PENDING o---------------------+ |
</tr>
<tr>
<td>content-accept</td>
<td>Accept a content-add, content-modify, or content-remove action received from another party.</td>
<td>Accept a content-add or content-modify action received from another party.</td>
</tr>
<tr>
<td>content-add</td>
@ -472,7 +478,7 @@ PENDING o---------------------+ |
</tr>
<tr>
<td>content-remove</td>
<td>Remove one or more content types from the session. The sender MUST specify only the removed content-type(s), not the removed content-type(s) plus the remaining content-type(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content type definition. <note>A client MUST NOT return an error upon receipt of a 'content-remove' action for a content type that is received after a 'content-remove' action has been sent but before the action has been acknowledged by the peer.</note> <note>If the content-remove results in zero content types for the session, the entity that receives the content-remove SHOULD send a session-terminate action to the other party (since a session with no content types is void).</note></td>
<td>Remove one or more content types from the session. The sender MUST specify only the removed content-type(s), not the removed content-type(s) plus the remaining content-type(s). Therefore it is the responsibility of the recipient to maintain a local copy of the current content type definition. <note>The recipient SHOULD NOT send a content-accept with the new content type definition after receiving a content-remove.</note> <note>A client MUST NOT return an error upon receipt of a 'content-remove' action for a content type that is received after a 'content-remove' action has been sent but before the action has been acknowledged by the peer.</note> <note>If the content-remove results in zero content types for the session, the entity that receives the content-remove SHOULD send a session-terminate action to the other party (since a session with no content types is void).</note></td>
</tr>
<tr>
<td>session-accept</td>
@ -506,6 +512,17 @@ PENDING o---------------------+ |
<p>Once the initiator has discovered which of the responder's XMPP resources is ideal for the desired application format, it sends a session initiation request to the responder. This request is an IQ-set containing a &JINGLE; element qualified by the 'http://www.xmpp.org/extensions/xep-0166.html#ns' namespace &NSNOTE;, where the value of the 'action' attribute is "session-initiate" and where the &JINGLE; element contains one or more &CONTENT; elements. Each &CONTENT; element defines a content type to be transferred during the session, and each &CONTENT; element in turn contains one &DESCRIPTION; child element that specifies a desired application format and one &TRANSPORT; child element that specifies a potential transport method. If either party wishes to propose the use of multiple transport methods for the same application format, it must send multiple &CONTENT; elements.</p>
<p>Note: The syntax and semantics of the &DESCRIPTION; and &TRANSPORT; elements are out of scope for this specification, since they are defined in related specifications. The syntax and semantics of the &JINGLE; and &CONTENT; elements are specified in this document under <link url='#def'>Formal Definition</link>.</p>
<p>Note: In order to expedite session establishment, the initiator MAY send transport candidates (e.g., for negotiation of the ICE transport) immediately after sending the "session-initiate" message and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be PENDING even before receiving acknowledgement). Given in-order delivery, the responder should receive such "transport-info" messages after receiving the "session-initiate" message (if not, it is appropriate for the responder to return &lt;unknown-session/&gt; errors since according to its state machine the session does not exist).</p>
<example caption="Receiver returns unknown-session error"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='jingle1'
to='romeo@montague.lit/orchard'
type='error'>
<error type='cancel'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unknown-session xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns-errors'/>
</error>
</iq>
]]></example>
</section2>
<section2 topic='Receiver Response' anchor='protocol-response'>
<section3 topic='Acknowledgement' anchor='protocol-response-ack'>
@ -599,7 +616,7 @@ PENDING o---------------------+ |
</section2>
<section2 topic='Acceptance' anchor='session-acceptance'>
<p>If (after negotiation of transport methods and application formats as well as checking of transport candidates) the responder determines that it will be able to establish a connection, it sends a definitive acceptance to the initiator.</p>
<p>Note: In the accept stanza, the &JINGLE; element MUST contain one or more &lt;content/&gt; elements, each of which MUST contain one &lt;description/&gt; element and one &lt;transport/&gt; element. The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity, and the initiator SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute.</p>
<p>Note: In the session-accept stanza, the &JINGLE; element MUST contain one or more &lt;content/&gt; elements, each of which MUST contain one &lt;description/&gt; element and one &lt;transport/&gt; element. The &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the responding entity; after sending acknowledgement of the session-accept, the initiator SHOULD send all future commmunications about this Jingle session to the JID provided in the 'responder' attribute and note the new JID in the user interface.</p>
<p>The initiator then acknowledges the responder's definitive acceptance, after which the parties can exchange media over the negotiated connection.</p>
<p>If one of the parties cannot find a suitable transport method or candidate, it SHOULD terminate the session as described below.</p>
</section2>
@ -674,6 +691,17 @@ PENDING o---------------------+ |
<section2 topic='Informational Messages' anchor='session-info'>
<p>At any point after initiation of a Jingle session, either entity MAY send an informational message to the other party, for example to change a transport method, inform the other party that a device is ringing or that a scheduled event has occurred or will occur, etc.</p>
<p>An informational message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info" or "transport-info"; the &JINGLE; element MUST further contain a payload child element (specific to the session or to a transport method) that specifies the information being communicated. If the party that receives an informational message does not understand the payload, it MUST return a &feature; error with a Jingle-specific error condition of &lt;unsupported-info/&gt;.</p>
<example caption="Receiver returns unsupported-info error"><![CDATA[
<iq from='juliet@capulet.lit/balcony'
id='info1'
to='romeo@montague.lit/orchard'
type='error'>
<error type='modify'>
<feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unsupported-info xmlns='http://www.xmpp.org/extensions/xep-0166.html#ns-errors'/>
</error>
</iq>
]]></example>
<p>If either party receives an empty "session-info" message for an active session, it MUST send an empty IQ result; this way, an empty "session-info" message may be used as a "ping" to determine session vitality.</p>
<p>Informational messages are specific to a particular application type or transport method and therefore are described in specifications other than this one.</p>
</section2>
@ -755,7 +783,7 @@ PENDING o---------------------+ |
<section1 topic='Error Handling' anchor='errors'>
<p>The Jingle-specific error conditions are as follows. These condition elements are qualified by the 'http://www.xmpp.org/extensions/xep-0166.html#ns-errors' namespace &NSNOTE;.</p>
<table caption='Other Error Conditions'>
<table caption='Error Conditions'>
<tr>
<th>Jingle Condition</th>
<th>XMPP Condition</th>
@ -771,21 +799,11 @@ PENDING o---------------------+ |
<td>&badrequest;</td>
<td>The 'sid' attribute specifies a session that is unknown to the recipient (e.g., no longer live according to the recipient's state machine because the recipient previously terminated the session).</td>
</tr>
<tr>
<td>&lt;unsupported-content/&gt;</td>
<td>&notacceptable;</td>
<td>The recipient does not support any of the desired application formats.</td>
</tr>
<tr>
<td>&lt;unsupported-info/&gt;</td>
<td>&feature;</td>
<td>The recipient does not support the informational payload of a session-info message.</td>
</tr>
<tr>
<td>&lt;unsupported-transports/&gt;</td>
<td>&notacceptable;</td>
<td>The recipient does not support any of the desired transport methods.</td>
</tr>
</table>
</section1>
@ -1039,6 +1057,7 @@ PENDING o---------------------+ |
<xs:element name='out-of-order' type='empty'/>
<xs:element name='unknown-session' type='empty'/>
<xs:element name='unsupported-info' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>