diff --git a/xep-0155.xml b/xep-0155.xml index 6567e39d..9c9ec40a 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -7,7 +7,7 @@
Chat Session Negotiation - This document specifies a feature negotiation profile for initiating a one-to-one chat session. + This document specifies a feature negotiation profile for initiating a one-to-one XMPP chat session. &LEGALNOTICE; 0155 Experimental @@ -472,16 +472,6 @@ ]]> - -

When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.

-

In addition, the following mappings apply to chat session negotiation:

-
    -
  • Initiation of a negotiated chat session maps to the semantics of the SIP INVITE method.
  • -
  • Renegotiation of a negotiated chat session also maps to the semantics of the SIP INVITE method.
  • -
  • Termination of a negotiated chat session maps to the semantics of the SIP BYE method.
  • -
  • The XMPP &THREAD; value maps to the semantics of the SIP Call-ID attribute.
  • -
-

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

@@ -493,6 +483,16 @@

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

However, the receiving party MAY assume that the other client will not be able to continue the session. 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. In that case 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.)

+ +

When mapping instant messaging flows to SIP, implementations SHOULD adhere to &xmppsimple;.

+

In addition, the following mappings apply to chat session negotiation:

+
    +
  • Initiation of a negotiated chat session maps to the semantics of the SIP INVITE method.
  • +
  • Renegotiation of a negotiated chat session also maps to the semantics of the SIP INVITE method.
  • +
  • Termination of a negotiated chat session maps to the semantics of the SIP BYE method.
  • +
  • The XMPP &THREAD; value maps to the semantics of the SIP Call-ID attribute.
  • +
+
@@ -559,7 +559,9 @@ + label='Primary written language of the chat (each + value appears in order of preference and + conforms to RFC 4646 and the IANA registry)'/> false -