moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
Code Issues Releases Wiki Activity

0.38

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3179 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-05-28 02:30:34 +00:00
parent 021652967a
commit e5fa993d83
1 changed files with 13 additions and 14 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
xep-0166.xml
View File

@ -27,6 +27,12 @@
&robmcqueen;
&seanegan;
&hildjj;
<revision>
<version>0.38</version>
<date>2009-05-27</date>
<initials>psa</initials>
<remark><p>Clarified and tightened handling of the initiator, responder, creator, and senders attributes.</p></remark>
</revision>
<revision>
<version>0.37</version>
<date>2009-04-20</date>
@ -406,7 +412,6 @@ Romeo Juliet
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-accept'
initiator='romeo@montague.lit/orchard'
responder='juliet@capulet.lit/balcony'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='this-is-a-stub'>
@ -425,7 +430,6 @@ Romeo Juliet
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-terminate'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<reason>
<success/>
@ -498,7 +502,6 @@ Romeo Juliet
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-accept'
initiator='romeo@montague.lit/orchard'
responder='juliet@capulet.lit/balcony'
sid='a73sjjvkla37jfea'>
<content creator='initiator' name='voice'>
@ -538,7 +541,6 @@ Romeo Juliet
type='set'>
<jingle xmlns='urn:xmpp:jingle:1'
action='session-terminate'
initiator='romeo@montague.lit/orchard'
sid='a73sjjvkla37jfea'>
<reason>
<success/>
@ -1132,13 +1134,13 @@ PENDING o-----------------------+ |
</tr>
<tr>
<td>initiator*</td>
<td>The full JID of the entity that has initiated the session flow. This can be different from the 'from' address on the IQ-set of the session-initiate message (e.g., to handle certain interactions involving call managers, soft switches, and media relays); however, if the 'initiator' and 'from' values are different then the responder MUST NOT interact with the 'initiator' JID unless it trusts the 'initiator' JID or trusts the 'from' JID to authorize the 'initiator' JID to act on its behalf.</td>
<td>REQUIRED</td>
<td>The full JID of the entity that has initiated the session flow. When the Jingle action is "session-initiate", the &JINGLE; element SHOULD possess an 'initiator' attribute that explicitly specifies the full JID of the initiating entity; for all other actions, the &JINGLE; element SHOULD NOT possess an 'initiator' attribute and the recipient of the message SHOULD ignore the value if provided. The value of the 'initiator' attribute MAY be different from the 'from' address on the IQ-set of the session-initiate message (e.g., to handle certain interactions involving call managers, soft switches, and media relays). This usage shall be defined in other specifications, for example, in &xep0251;. However, in all cases if the 'initiator' and 'from' values differ then the responder MUST NOT interact with the 'initiator' JID unless it trusts the 'initiator' JID or trusts that the 'from' JID is allowed authorize the 'initiator' JID to act on the 'from' JID's behalf. In the absence of explicit rules for handling this case, the responder SHOULD simply ignore the 'initiator' attribute and treat the 'from' JID as the initiating entity. After sending acknowledgement of the session-initiate message, the responder MUST send all future commmunications about the Jingle session to initiator (whether the initiator is considered the 'from' JID or the 'initiator' JID).</td>
<td>RECOMMENDED for session-initiate, NOT RECOMMENDED otherwise</td>
</tr>
<tr>
<td>responder*</td>
<td>The full JID of the entity that has replied to the initiation, which can be different from the 'to' address on the IQ-set.</td>
<td>RECOMMENDED</td>
<td>The full JID of the entity that has replied to the initiation, which can be different from the 'to' address on the IQ-set. When the Jingle action is "session-accept", the &JINGLE; element SHOULD possess a 'responder' attribute that explicitly specifies the full JID of the initiating entity; for all other actions, the &JINGLE; element SHOULD NOT possess a 'responder' attribute and the recipient of the message SHOULD ignore the value if provided. The value of the 'responder' attribute MAY be different from the 'from' address on the IQ-set of the session-accept message, where the logic for handling any difference between the 'responder' JID and the 'from' JID follows the same logic as for session-initiate messages (see below). After sending acknowledgement of the session-accept message, the initiator MUST send all future commmunications about this Jingle session to the responder (whether the responder is considered the 'from' JID or the 'responder' JID).</td>
<td>RECOMMENDED for session-accept, NOT RECOMMENDED otherwise</td>
</tr>
<tr>
<td>sid</td>
@ -1146,7 +1148,6 @@ PENDING o-----------------------+ |
<td>REQUIRED</td>
</tr>
</table>
<p class='box'>* Note: In the absence of explicit handling for the 'initiator' and 'responder' attributes (for example, as described in &xep0251;), a Jingle application MAY simply ignore these attributes if their values are different from the 'from' and 'to' attributes of the session-initiate message. For further descriptions of the 'initiator' and 'responder' attributes, see also the definitions of the <link url='#def-action-session-initiate'>session-initiate</link> and <link url='#def-action-session-accept'>session-accept</link> actions respectively.</p>
</section2>
<section2 topic='Action Attribute' anchor='def-action'>
<p>The value of the 'action' attribute MUST be one of the following. If an entity receives a value not defined here, it MUST ignore the attribute and MUST return a &badrequest; error to the sender. There is no default value for the 'action' attribute.</p>
@ -1176,14 +1177,12 @@ PENDING o-----------------------+ |
<section3 topic='session-accept' anchor='def-action-session-accept'>
<p>The <strong>session-accept</strong> action is used to definitively accept a session negotiation (implicitly this action also serves as a content-accept). A session-accept action indicates a willingness to proceed with the session (which might necessitate further negotiation before media can be exchanged). The session-accept action indicates acceptance <em>only</em> of the content definition(s) whose disposition type is "session" (the default value of the &CONTENT; element's 'disposition' attribute), not any content definition(s) whose disposition type is something other than "session" (e.g., "early-session" for early media).</p>
<p>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.</p>
<p>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>
</section3>
<section3 topic='session-info' anchor='def-action-session-info'>
<p>The <strong>session-info</strong> action is used to send session-level information, such as a session ping or (for Jingle RTP sessions) a ringing message.</p>
</section3>
<section3 topic='session-initiate' anchor='def-action-session-initiate'>
<p>The <strong>session-initiate</strong> action is used to request negotiation of a new Jingle session. When sending a session-initiate with one &CONTENT; element, the value of the &CONTENT; element's 'disposition' attribute MUST be "session" (if there are multiple &CONTENT; elements then at least one MUST have a disposition of "session"); if this rule is violated, the responder MUST return a &badrequest; error to the initiator.</p>
<p>The &JINGLE; element SHOULD possess an 'initiator' attribute that explicitly specifies the full JID of the initiating entity; after sending acknowledgement of the session-initiate message, the responder SHOULD send all future commmunications about this Jingle session to the JID provided in the 'initiator' attribute and note the new JID in the user interface.</p>
</section3>
<section3 topic='session-terminate' anchor='def-action-session-terminate'>
<p>The <strong>session-terminate</strong> action is used to end an existing session.</p>
@ -1237,7 +1236,7 @@ PENDING o-----------------------+ |
<tr>
<td>creator</td>
<td>Which party originally generated the content type (used to prevent race conditions regarding modifications); the defined values are "initiator" and "responder" (where the default is "initiator"). The value of the 'creator' attribute for a given content type MUST always match the party that originally generated the content type, even for Jingle actions that are sent by the other party in relation to that content type (e.g., subsequent content-modify or transport-info messages).</td>
<td>REQUIRED</td>
<td>REQUIRED when offering a new content-type via session-initiate or content-add; otherwise OPTIONAL</td>
</tr>
<tr>
<td>disposition</td>
@ -1252,7 +1251,7 @@ PENDING o-----------------------+ |
<tr>
<td>senders</td>
<td>Which parties in the session will be generating content; the allowable values are "initiator", "none", "responder", and "both" (where the default is "both").</td>
<td>RECOMMENDED</td>
<td>REQUIRED when sending content-modify; otherwise OPTIONAL</td>
</tr>
</table>
</section2>
@ -1603,7 +1602,7 @@ PENDING o-----------------------+ |
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='initiator' type='xs:string' use='required'/>
<xs:attribute name='initiator' type='xs:string' use='optional'/>
<xs:attribute name='responder' type='xs:string' use='optional'/>
<xs:attribute name='sid' type='xs:NMTOKEN' use='required'/>
</xs:complexType>