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

copied note

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1769 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-04-18 16:23:47 +00:00
parent 9398f5e9ed
commit f9dea23f10
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
xep-0166.xml
View File

@ -466,7 +466,7 @@ PENDING o---------------------+ |
</tr>
<tr>
<td>content-replace</td>
<td>Replace the definition of a content type with a new definition. 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.</td>
<td>Replace the definition of a content type with a new definition. 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>
</tr>
<tr>
<td>session-accept</td>