1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00

changed receiver to responder

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@1888 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-05-29 17:17:48 +00:00
parent 02462c6e4c
commit 8fc7507024

View File

@ -308,7 +308,7 @@ Romeo Juliet
]]></example>
<p>The parties would then attempt to negotiate use of the SOCKS5 Bytestreams transport method, as described in <cite>XEP-0065</cite>.</p>
<p>Once the file transfer succeeds, one of the parties terminates the session.</p>
<example caption="Receiver terminates the session"><![CDATA[
<example caption="Responder terminates the session"><![CDATA[
<iq from='laertes@shakespeare.lit/castle'
id='term1'
to='kingclaudius@shakespeare.lit/castle'
@ -531,7 +531,7 @@ PENDING o---------------------+ |
]]></example>
<p>Note: The syntax and semantics of the &DESCRIPTION; and &TRANSPORT; elements are out of scope for this specification, since they are defined in related specifications. The syntax and semantics of the &JINGLE; and &CONTENT; elements are specified in this document under <link url='#def'>Formal Definition</link>.</p>
<p>Note: In order to expedite session establishment, the initiator MAY send transport candidates (e.g., for negotiation of the ICE transport) immediately after sending the session-initiate action and before receiving acknowledgement from the responder (i.e., the initiator MUST consider the session to be PENDING even before receiving acknowledgement). Given in-order delivery, the responder should receive such transport-info actions after receiving the session-initiate action (if not, it is appropriate for the responder to return &lt;unknown-session/&gt; errors since according to its state machine the session does not exist).</p>
<example caption="Receiver returns unknown-session error"><![CDATA[
<example caption="Responder returns unknown-session error"><![CDATA[
<iq from='laertes@shakespeare.lit/castle'
id='jingle1'
to='kingclaudius@shakespeare.lit/castle'
@ -543,10 +543,10 @@ PENDING o---------------------+ |
</iq>
]]></example>
</section2>
<section2 topic='Receiver Response' anchor='protocol-response'>
<section2 topic='Responder Response' anchor='protocol-response'>
<section3 topic='Acknowledgement' anchor='protocol-response-ack'>
<p>Unless one of the following errors occurs, the responder SHOULD acknowledge receipt of the initiation request.</p>
<example caption="Receiver acknowledges session-initiate"><![CDATA[
<example caption="Responder acknowledges session-initiate"><![CDATA[
<iq from='laertes@shakespeare.lit/castle'
id='jingle1'
to='kingclaudius@shakespeare.lit/castle'
@ -576,7 +576,7 @@ PENDING o---------------------+ |
</iq>
]]></example>
<p>If the responder does not support Jingle, it MUST return a &unavailable; error.</p>
<example caption="Receiver does not support Jingle"><![CDATA[
<example caption="Responder does not support Jingle"><![CDATA[
<iq from='laertes@shakespeare.lit/castle'
id='jingle1'
to='kingclaudius@shakespeare.lit/castle'
@ -587,7 +587,7 @@ PENDING o---------------------+ |
</iq>
]]></example>
<p>If the responder wishes to redirect the request to another address, it SHOULD return a &redirect; error.</p>
<example caption="Receiver redirection"><![CDATA[
<example caption="Responder redirection"><![CDATA[
<iq from='laertes@shakespeare.lit/castle'
id='jingle1'
to='kingclaudius@shakespeare.lit/castle'
@ -600,7 +600,7 @@ PENDING o---------------------+ |
</iq>
]]></example>
<p>If the responder does not have sufficient resources to participate in a session, it SHOULD return a &constraint; error.</p>
<example caption="Receiver has insufficent resources"><![CDATA[
<example caption="Responder has insufficent resources"><![CDATA[
<iq from='laertes@shakespeare.lit/castle'
id='jingle1'
to='kingclaudius@shakespeare.lit/castle'
@ -748,7 +748,7 @@ PENDING o---------------------+ |
</iq>
]]></example>
<p>An informational message MUST be an IQ-set containing a &JINGLE; element whose 'action' attribute is set to a value of "session-info" or "transport-info"; the &JINGLE; element MUST further contain a payload child element (specific to the session or to a transport method) that specifies the information being communicated. If the party that receives an informational message does not understand the payload, it MUST return a &feature; error with a Jingle-specific error condition of &lt;unsupported-info/&gt;.</p>
<example caption="Receiver returns unsupported-info error"><![CDATA[
<example caption="Responder returns unsupported-info error"><![CDATA[
<iq from='laertes@shakespeare.lit/castle'
id='info1'
to='kingclaudius@shakespeare.lit/castle'