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

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@985 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-06-20 17:59:31 +00:00
parent 80404104ee
commit 523ddd9785
1 changed files with 14 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
xep-0166.xml
View File

@ -26,6 +26,12 @@
&robmcqueen;
&seanegan;
&hildjj;
<revision>
<version>0.16</version>
<date>2007-06-20</date>
<initials>psa</initials>
<remark><p>Added &lt;unsupported-info/&gt; error.</p></remark>
</revision>
<revision>
<version>0.16</version>
<date>2007-06-06</date>
@ -576,7 +582,9 @@ PENDING o---------------------+ |
<p>Unfortunately, not all sessions end gracefully. In applications of Jingle that also involve the exchange of presence information, receipt of &UNAVAILABLE; from the other party MAY be a considered session-ending event. However, in this case there is nothing for the party to acknowledge.</p>
</section2>
<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 content transport method or content description format parameter, inform the other party that a session initiation request is queued, that a device is ringing, or that a scheduled event has occurred or will occur. An information message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info", "description-info", or "transport-info"; the &JINGLE; element MUST further contain a payload child element (speciific to the session, content description format, or content transport method) that specifies the information being communicated. 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. (A future version of this specification may define payloads related to the "session-info" action.)</p>
<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 content transport method or content description format parameter, inform the other party that a session initiation request is queued, that a device is ringing, or that a scheduled event has occurred or will occur.</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>
<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>
</section2>
</section1>
@ -603,6 +611,11 @@ PENDING o---------------------+ |
<td>&notacceptable;</td>
<td>The recipient does not support any of the desired content description 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>