moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-28 04:02:20 -05:00
Code Issues Releases Wiki Activity

oops

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@163 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson 2006-11-02 22:27:43 +00:00
parent 5c5304c4f1
commit 029e762985
1 changed files with 17 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
xep-0155.xml
View File

@ -7,7 +7,7 @@
<xep> <xep>
<header> <header>
<title>Chat Session Negotiation</title> <title>Chat Session Negotiation</title>
<abstract>This document specifies a feature negotiation profile for initiating a one-to-one chat session.</abstract> <abstract>This document specifies a feature negotiation profile for initiating a one-to-one XMPP chat session.</abstract>
&LEGALNOTICE; &LEGALNOTICE;
<number>0155</number> <number>0155</number>
<status>Experimental</status> <status>Experimental</status>
@ -472,16 +472,6 @@
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Mapping to SIP' anchor='sip'>
<p>When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.</p>
<p>In addition, the following mappings apply to chat session negotiation:</p>
<ul>
<li>Initiation of a negotiated chat session maps to the semantics of the SIP INVITE method.</li>
<li>Renegotiation of a negotiated chat session also maps to the semantics of the SIP INVITE method.</li>
<li>Termination of a negotiated chat session maps to the semantics of the SIP BYE method.</li>
<li>The XMPP &THREAD; value maps to the semantics of the SIP Call-ID attribute.</li>
</ul>
</section1>
<section1 topic='Implementation Notes' anchor='impl'> <section1 topic='Implementation Notes' anchor='impl'>
<section2 topic='Auto Accept or Reject' anchor='impl-auto'> <section2 topic='Auto Accept or Reject' anchor='impl-auto'>
<p>A client MAY require a human user to approve each chat session negotiation request, however it is RECOMMENDED that it accepts or rejects automatically as many requests as possible, based on a set of user-configurable policies (see <link url='#secure-leak'>Presence Leaks</link>).</p> <p>A client MAY require a human user to approve each chat session negotiation request, however it is RECOMMENDED that it accepts or rejects automatically as many requests as possible, based on a set of user-configurable policies (see <link url='#secure-leak'>Presence Leaks</link>).</p>
@ -493,6 +483,16 @@
<p>If a party receives an XMPP presence stanza of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages).</p> <p>If a party receives an XMPP presence stanza of type "unavailable" from the full JID (&FULLJID;) of the other party (i.e., the resource with which it has had an active session) during a chat session, the receiving party SHOULD assume that the other client will still be able to continue the session (perhaps it simply became "invisible", or it is persisting the state of the negotiated chat until it reconnects and receives "offline" messages).</p>
<p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Chat</link>) - since its assumption could be incorrect. If after terminating the session the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, then it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p> <p>However, the receiving party MAY assume that the other client will <em>not</em> be able to continue the session. <note>In general, if a party is not subscribing to the other party's presence then it will never assume the other party is is unable to continue a session.</note> In that case it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Chat</link>) - since its assumption could be incorrect. If after terminating the session the receiving party later receives presence of type "available" from that same resource or another resource associated with the other party and the receiving party desires to restart the chat session, then it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party. It MUST NOT renegotiate parameters for the terminated session. (Note: This is consistent with the handling of chat states as specified in <cite>XEP-0085</cite>.)</p>
</section2> </section2>
<section2 topic='Mapping to SIP' anchor='impl-sip'>
<p>When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.</p>
<p>In addition, the following mappings apply to chat session negotiation:</p>
<ul>
<li>Initiation of a negotiated chat session maps to the semantics of the SIP INVITE method.</li>
<li>Renegotiation of a negotiated chat session also maps to the semantics of the SIP INVITE method.</li>
<li>Termination of a negotiated chat session maps to the semantics of the SIP BYE method.</li>
<li>The XMPP &THREAD; value maps to the semantics of the SIP Call-ID attribute.</li>
</ul>
</section2>
</section1> </section1>
<section1 topic='Security Considerations' anchor='security'> <section1 topic='Security Considerations' anchor='security'>
<section2 topic='Presence Leaks' anchor='secure-leak'> <section2 topic='Presence Leaks' anchor='secure-leak'>
@ -559,7 +559,9 @@
<field <field
var='language' var='language'
type='list-single' type='list-single'
label='Primary written language of the chat (each value appears in order of preference and conforms to RFC 4646 and the IANA registry)'/> label='Primary written language of the chat (each
value appears in order of preference and
conforms to RFC 4646 and the IANA registry)'/>
<field <field
var='otr' var='otr'
type='list-single' type='list-single'
@ -567,7 +569,9 @@
<option label='Allow message logging'> <option label='Allow message logging'>
<value>false</value> <value>false</value>
</option> </option>
<option label='Disable absolutely all message logging including automatic archiving - see XEP-0136'> <option label='Disable absolutely all message logging
including automatic archiving - see
XEP-0136'>
<value>true</value> <value>true</value>
</option> </option>
</field> </field>