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

1.2pre1 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1394 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-11-19 22:19:57 +00:00
parent 535ae14637
commit e9dbdab3ef
1 changed files with 17 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

24
xep-0155.xml
View File

@ -25,6 +25,12 @@
<shortname>ssn</shortname>
&ianpaterson;
&stpeter;
<revision>
<version>1.2pre1</version>
<date>in progress, last updated 2007-11-13</date>
<initials>psa</initials>
<remark><p>Specified that IM message bodies must not be included.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2007-03-15</date>
@ -278,7 +284,7 @@ PENDING o---------------+
</section2>
<section2 topic='Accepting a Session' anchor='new-accept'>
<p>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 <em>immediate</em> 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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>In the example below we assume that Juliet accepts the session and specifies that she prefers to speak Italian with Romeo:</p>
<example caption="Contact accepts session and specifies parameters"><![CDATA[
@ -310,7 +316,7 @@ PENDING o---------------+
</section2>
<section2 topic='Rejecting a Session' anchor='new-reject'>
<p>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 <link url='#secure-leak'>Presence Leaks</link>). 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.</p>
<p>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:</p>
<p>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.</p>
<example caption="Contact declines offer and specifies reason"><![CDATA[
<message type='normal'
from='juliet@capulet.com/balcony'
@ -322,9 +328,11 @@ PENDING o---------------+
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>0</value></field>
<field var='reason'>
<value>Sorry, can't chat now! How about tonight?</value>
</field>
</x>
</feature>
<body>Sorry, can't chat now! How about tonight?</body>
</message>
]]></example>
<p>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:</p>
@ -392,7 +400,7 @@ PENDING o---------------+
]]></example>
</section2>
<section2 topic='Completing or Canceling the Negotiation' anchor='new-complete'>
<p>If the contact accepted the session (see <link url='#new-accept'>Accepting a Session</link>) 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. <note>See <cite>Encrypted Session Negotiation</cite> for example of other instances where the user might find the values submitted by the contact unacceptable.</note> 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:</p>
<p>If the contact accepted the session (see <link url='#new-accept'>Accepting a Session</link>) 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. <note>See <cite>Encrypted Session Negotiation</cite> for example of other instances where the user might find the values submitted by the contact unacceptable.</note> 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.</p>
<example caption="User completes negotiation and confirms session is open"><![CDATA[
<message type='normal'
from='romeo@montague.net/orchard'
@ -404,9 +412,11 @@ PENDING o---------------+
<value>urn:xmpp:ssn</value>
</field>
<field var='accept'><value>true</value></field>
<field var='reason'>
<value>I forgot what I wanted to say!</value>
</field>
</x>
</feature>
<body>I forgot what I wanted to say!</body>
</message>
]]></example>
<p>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":</p>
@ -464,7 +474,7 @@ PENDING o---------------+
<p>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.</p>
</section1>
<section1 topic='Renegotiating a Session' anchor='renegotiate'>
<p>At any time during an existing session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in <link url='#new'>Negotiating a New Session</link>. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the <em>same</em> 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.</p>
<p>At any time during an existing session, either party MAY attempt to renegotiate the parameters of the session using the protocol described in <link url='#new'>Negotiating a New Session</link>. The requesting party does this by sending a new &MESSAGE; stanza containing a feature negotiation form and a &THREAD; element with the <em>same</em> 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.</p>
<example caption="One party requests renegotiation"><![CDATA[
<message type='normal'
from='juliet@capulet.com/balcony'
@ -531,7 +541,7 @@ PENDING o---------------+
<p>If the other party's client does not support one or more of the <em>required</em> features, it SHOULD return a &feature; error. If the other party's client supports <em>none</em> of the options for one or more <em>required</em> fields, it SHOULD return a &notacceptable; error (see <link url='#new-reject'>Rejecting a Session</link>). 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 <link url='#terminate'>Terminating a Session</link>.</p>
</section1>
<section1 topic='Terminating a Session' anchor='terminate'>
<p>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".</p>
<p>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".</p>
<example caption="One party terminates session"><![CDATA[
<message type='normal'
from='juliet@capulet.com/balcony'