From bdb31e5acd0e6d1cb47b4a9f5b3e452338207152 Mon Sep 17 00:00:00 2001 From: Ian Paterson Date: Fri, 20 Oct 2006 08:57:43 +0000 Subject: [PATCH] enhanced implementation notes git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@116 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0155.xml | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/xep-0155.xml b/xep-0155.xml index 5aed61cb..8dbb0efb 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -25,9 +25,15 @@ chatneg &stpeter; &ianpaterson; + + 0.10 + 2006-10-20 + ip +

Enhanced implementation notes.

 + 0.9 - 2006-10-05 + 2006-10-08 ip

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.

 @@ -394,12 +400,16 @@ -

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.

-

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 not be able to continue the session, then it MUST explicitly terminate the session (see Terminating a Chat) - 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 XEP-0085.)

+ +

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 Security Considerations).

+ + +

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

+

However, if the receiving party assumes that the other client will not be able to continue the session, then it MUST explicitly terminate the session (see Terminating a Chat) - 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 XEP-0085.)

+ -

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 automatically (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.

+

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 automatically (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.

This document requires no interaction with &IANA;.