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.28

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1982 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-06-16 17:45:11 +00:00
parent 80fc3f7284
commit 14c80068ba
1 changed files with 14 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
xep-0166.xml
View File

@ -26,6 +26,12 @@
&robmcqueen;
&seanegan;
&hildjj;
<revision>
<version>0.28</version>
<date>2008-06-16</date>
<initials>psa</initials>
<remark><p>Modified state machine to allow content-replace during PENDING state for more seamless handling of fallback scenarios.</p></remark>
</revision>
<revision>
<version>0.27</version>
<date>2008-06-04</date>
@ -423,8 +429,10 @@ Romeo Juliet
| +-----------------------+
|/ |
PENDING o---------------------+ |
| | content-accept, | |
| | content-modify, | |
| | content-remove, | |
| | content-replace, | |
| | session-info, | |
| | transport-info | |
| +------------------+ |
@ -461,7 +469,7 @@ PENDING o---------------------+ |
</tr>
<tr>
<td>content-accept</td>
<td>Accept a content-add or content-replace action received from another party. This action MUST NOT be sent while the session is in the PENDING state.</td>
<td>Accept a content-add or content-replace action received from another party.</td>
</tr>
<tr>
<td>content-add</td>
@ -477,7 +485,7 @@ PENDING o---------------------+ |
</tr>
<tr>
<td>content-replace</td>
<td>Replace the definition of a content type with a new definition; essentially this functions as a simultaneous content-remove and content-add. The application type MUST NOT change but the definition of the application type MAY be modified (e.g., a file offer may be modified to a file request). The transport method MAY be changed (e.g., from &xep0065; to &xep0047;) or the definition of the existing method MAY be modified. The sender MUST specify only the replaced content-type(s), not any existing content-type that has not been replaced. Therefore it is the responsibility of the recipient to maintain a local copy of the current content type definition. This action MUST NOT be sent while the session is in the PENDING state. When a party sends a content-replace, it MUST ignore any actions received from the other party until it receives acknowledgement of the content-replace. If the recipient wishes to include the replaced content type in the session, it MUST send a content-accept action to the other party. <note>If both parties send content-replace actions at the same time, the content-replace from the session initiator MUST trump the content-replace from the recipient and the initiator SHOULD return an &unexpected; error to the other party.</note></td>
<td>Replace the definition of a content type with a new definition; essentially this functions as a simultaneous content-remove and content-add. The application type MUST NOT change but the definition of the application type MAY be modified (e.g., a file offer may be modified to a file request). In order to handle fallback scenarios, the transport method MAY be changed (e.g., from &xep0065; to &xep0047;) or the definition of the existing method MAY be modified. The sender MUST specify only one replaced content-type, not any existing content-type that shall not been replaced. Therefore it is the responsibility of the recipient to maintain a local copy of the current content type definitions. When a party sends a content-replace, it MUST ignore any content-replace action it may receive from the other party with regard to the same content type until it receives acknowledgement of the content-replace. If the recipient wishes to include the replaced content type in the session, it MUST send a content-accept action to the other party. <note>If both parties send content-replace actions at the same time with regard to the same content type, the content-replace from the session initiator MUST trump the content-replace from the recipient and the initiator SHOULD return an &unexpected; error to the other party.</note></td>
</tr>
<tr>
<td>session-accept</td>
@ -633,11 +641,11 @@ PENDING o---------------------+ |
<p>In general, negotiation will be necessary before the parties can agree on an acceptable set of application formats and transport methods. There are many potential parameter combinations, as defined in the relevant specifications for various application formats and transport methods.</p>
<p>The allowable negotiations (including content-level and transport-level negotiations) are as follows:</p>
<ul>
<li>Adding a content type via the content-add action (not allowed in the PENDING state).</li>
<li>Exchanging particular transport candidates via the transport-info action.</li>
<li>Modifying the communication direction for a content type via the content-modify action.</li>
<li>Removing a content type via the content-remove action.</li>
<li>Changing the definition of a content type via the content-replace action (not allowed in the PENDING state).</li>
<li>Exchanging transport methods via the transport-info action.</li>
<li>Changing the definition of a content type via the content-replace action (e.g., to fall back to a more suitable transport).</li>
<li>Adding a content type via the content-add action (not allowed in the PENDING state).</li>
<li>Removing a content type via the content-remove action (not allowed in the PENDING state).</li>
</ul>
</section2>
<section2 topic='Acceptance' anchor='session-acceptance'>