moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

enhanced implementation notes 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@116 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Ian Paterson 2006-10-20 08:57:43 +00:00
parent 45361ac7be
commit bdb31e5acd
1 changed files with 15 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
xep-0155.xml
View File

@ -25,9 +25,15 @@
<shortname>chatneg</shortname>
&stpeter;
&ianpaterson;
<revision>
<version>0.10</version>
<date>2006-10-20</date>
<initials>ip</initials>
<remark><p>Enhanced implementation notes.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2006-10-05</date>
<date>2006-10-08</date>
<initials>ip</initials>
<remark><p>Added language field; replaced secure field with security field; changed type of otr, XHTML and Chat State fields from boolean to list-single; added not-acceptable error; several clarifications.</p></remark>
</revision>
@ -394,12 +400,16 @@
</ul>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>A client MAY require a human user to approve each chat session negotiation request or MAY auto-accept and auto-reject requests based on some user-configurable policy.</p>
<p>If a party receives XMPP presence 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 MAY assume that the other client will still be unable 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).
However, if the receiving party assumes that the other client will <em>not</em> be able to continue the session, then it MUST explicitly terminate the session (see <link url='#terminate'>Terminating a Chat</link>) - since its assumption could be incorrect. If 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, it MUST initiate a new chat session (including a newly-generated ThreadID) with the other party rather than 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 topic='Auto Accept or Reject' anchor='impl-auto'>
<p>A client MAY require a human user to approve each chat session negotiation request or MAY auto-accept and auto-reject requests based on some user-configurable policy (see <link url='#security'>Security Considerations</link>).</p>
</section2>
<section2 topic='Unavailable Presence' anchor='impl-unavail'>
<p>If a party receives XMPP presence 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 MAY 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, if the receiving party assumes that the other client will <em>not</em> be able to continue the session, then 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>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>If a contact accepts a user's request or returns an error to the user, the user will effectively discover the contact's presence (at least the presence of one of the contact's resources). Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT <em>automatically</em> (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Furthermore, the contact's client MUST NOT take either action if the user is in the contact's block list.</p>
<p>If a contact accepts a user's chat session negotiation request or returns an error to the user, the user will effectively discover the presence of the contact's resource. Due care must therefore be exercised in determining whether to accept the request or return an error. For examples, the contact's client SHOULD NOT <em>automatically</em> (i.e. without first asking the contact) either accept the user's request or return an error to the user unless the user is subscribing to the contact's presence (and the contact's presence is not currently "invisible" to the user). Note: There should be no need for the contact's client to consult the contact's block list, since if the user is on the list then the contact would not receive any request messages from the user anyway.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>