From e9dbdab3efd7fd4164a319de26db865107087805 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 19 Nov 2007 22:19:57 +0000 Subject: [PATCH] 1.2pre1 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1394 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0155.xml | 24 +++++++++++++++++------- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/xep-0155.xml b/xep-0155.xml index de23a31b..853fc342 100644 --- a/xep-0155.xml +++ b/xep-0155.xml @@ -25,6 +25,12 @@ ssn &ianpaterson; &stpeter; + + 1.2pre1 + in progress, last updated 2007-11-13 + psa +

Specified that IM message bodies must not be included.

 + 1.1 2007-03-15 @@ -278,7 +284,7 @@ PENDING o---------------+

If, upon reception of a user's session request, a contact finds that the request had been stored for later delivery, and if the contact is interested only in an immediate session, then it SHOULD initiate a new stanza session negotiation (including a newly-generated ThreadID) instead of responding to the user's request. Note: Sending any response to the user's original request would leak presence information since it would divulge the fact that the contact had been offline rather than just ignoring the user.

-

In any response to the user's request, the contact's client MUST mirror the &THREAD; value so that the user's client can correctly track the response.

+

In any response to the user's request, the contact's client MUST mirror the &THREAD; value so that the user's client can correctly track the response. The &MESSAGE; stanza MUST NOT contain a &BODY; child element.

If the request is accepted then the contact's client MUST include in its response values for all the fields that the request indicated are required. If the contact's client does not support one of the default values or if the contact has disabled its support (as for Chat State Notifications and XHTML formatting in the example below), and the client can still accept the request, then it MUST set that field to a value that it can support.

In the example below we assume that Juliet accepts the session and specifies that she prefers to speak Italian with Romeo:

If the contact does not want to reveal presence to the user for whatever reason then the contact's client SHOULD return no response or error (see Presence Leaks). Also, if the contact is using a legacy client then it MAY not support returning any response or error. In both these cases the user MAY proceed to send stanzas to the contact outside the context of a negotiated session.

-

However, if the contact simply prefers not to start a session then the client SHOULD decline the invitation. The data form MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMMENDED that the form does not contain any other fields even if the request indicated they are required. The client MAY include a reason in the &BODY; child of the &MESSAGE; stanza:

+

However, if the contact simply prefers not to start a session then the client SHOULD decline the invitation. The data form MUST contain the FORM_TYPE field and the "accept" field set to "0" or "false". It is RECOMMENDED that the form does not contain any other fields even if the request indicated they are required. The client MAY include a reason via the "reason" field (which is of type "text-single"). The &MESSAGE; stanza MUST NOT contain a &BODY; child element.

urn:xmpp:ssn 0 + + Sorry, can't chat now! How about tonight? + - Sorry, can't chat now! How about tonight? ]]>

If the contact's client does not support feature negotiation or does not support the "urn:xmpp:ssn" FORM_TYPE, it SHOULD return a &unavailable; error:

@@ -392,7 +400,7 @@ PENDING o---------------+ ]]> -

If the contact accepted the session (see Accepting a Session) then the user MUST either complete or cancel the stanza session negotiation. If the contact chose an option other than the default (prefered) value for one or more of the fields, then instead of having the client accept the session automatically the user may prefer to review the values that the contact selected before confirming that the session is open. See Encrypted Session Negotiation for example of other instances where the user might find the values submitted by the contact unacceptable. In any case the user's client SHOULD verify that the selected values are acceptable before completing the stanza session negotiation -- and confirming that the session is open -- by replying with a form with the form 'type' attribute set to 'result'. The form MUST contain the FORM_TYPE field and the "accept" field set to "1" or "true". The user MAY include other content (e.g., a &BODY; element) in the confirmation stanza:

+

If the contact accepted the session (see Accepting a Session) then the user MUST either complete or cancel the stanza session negotiation. If the contact chose an option other than the default (prefered) value for one or more of the fields, then instead of having the client accept the session automatically the user may prefer to review the values that the contact selected before confirming that the session is open. See Encrypted Session Negotiation for example of other instances where the user might find the values submitted by the contact unacceptable. In any case the user's client SHOULD verify that the selected values are acceptable before completing the stanza session negotiation -- and confirming that the session is open -- by replying with a form with the form 'type' attribute set to 'result'. The form MUST contain the FORM_TYPE field and the "accept" field set to "1" or "true". The user MAY include an explanation or reason via the "reason" field (which is of type "text-single"). The &MESSAGE; stanza MUST NOT contain a &BODY; child element.

urn:xmpp:ssn true + + I forgot what I wanted to say! + - I forgot what I wanted to say! ]]>

Alternatively, if the user decides to cancel the stanza session negotiation then the client MUST reply with a data form containing the FORM_TYPE field and the "accept" field set to "0" or "false":

@@ -464,7 +474,7 @@ PENDING o---------------+

Once the other party has accepted the switch then all stanzas sent within the session MUST be to or from the new resource. Note: Both parties MUST ensure that they comply with all the other stanza session negotiation parameters that were previously agreed for this session.

-

At any time during an existing session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in Negotiating a New Session. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the same value as that of the existing session. Note: The "accept" field MUST NOT be included in a renegotiation form. The other fields MAY be different from the set of fields included in the initial stanza session negotiation form.

+

At any time during an existing session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in Negotiating a New Session. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the same value as that of the existing session. Note: The "accept" field MUST NOT be included in a renegotiation form and the &MESSAGE; stanza MUST NOT contain a &BODY; child element. The other fields MAY be different from the set of fields included in the initial stanza session negotiation form.

If the other party's client does not support one or more of the required features, it SHOULD return a &feature; error. If the other party's client supports none of the options for one or more required fields, it SHOULD return a ¬acceptable; error (see Rejecting a Session). Note: In any of these cases the existing negotiated session parameters are maintained. Either party MAY choose to terminate the session only as specified in the section Terminating a Session.

 -

In order to explicitly terminate a negotiated session, the party that wishes to end the session MUST do so by sending a &MESSAGE; containing a data form of type "submit". The &MESSAGE; stanza MUST contain a &THREAD; element with the same XML character data as the original initiation request. The data form containing a boolean field named "terminate" set to a value of "1" or "true".

+

In order to explicitly terminate a negotiated session, the party that wishes to end the session MUST do so by sending a &MESSAGE; containing a data form of type "submit". The &MESSAGE; stanza MUST contain a &THREAD; element with the same XML character data as the original initiation request. The &MESSAGE; stanza MUST NOT contain a &BODY; child element. The data form containing a boolean field named "terminate" set to a value of "1" or "true".