1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00

fixed STUN RFC number

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2454 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-10-28 16:27:13 +00:00
parent a70c8e74d1
commit 7204a183eb
4 changed files with 4 additions and 4 deletions

View File

@ -522,7 +522,7 @@ INITIATOR RESPONDER
<section2 topic='Connectivity Checks' anchor='protocol-checks'> <section2 topic='Connectivity Checks' anchor='protocol-checks'>
<p>As the initiator and responder receive candidates, they probe the various candidate transports for connectivity. In performing these connectivity checks, each party SHOULD follow the procedure specified in Section 7 of &icecore;. The following business rules apply:</p> <p>As the initiator and responder receive candidates, they probe the various candidate transports for connectivity. In performing these connectivity checks, each party SHOULD follow the procedure specified in Section 7 of &icecore;. The following business rules apply:</p>
<ol> <ol>
<li>Each party sends a STUN Binding Request (see &rfc5489;) from each local candidate it generated to each remote candidate it received.</li> <li>Each party sends a STUN Binding Request (see &rfc5389;) from each local candidate it generated to each remote candidate it received.</li>
<li>In accordance with &icecore;, the STUN Binding Request MUST include the PRIORITY attribute (computed according to Section 7.1.1.1. of &icecore;).</li> <li>In accordance with &icecore;, the STUN Binding Request MUST include the PRIORITY attribute (computed according to Section 7.1.1.1. of &icecore;).</li>
<li>For the purposes of the Jingle ICE-UDP Transport Method, both parties are full ICE implementations and therefore the controlling role MUST be assumed by the initiator and the controlled role MUST be assumed by the responder.</li> <li>For the purposes of the Jingle ICE-UDP Transport Method, both parties are full ICE implementations and therefore the controlling role MUST be assumed by the initiator and the controlled role MUST be assumed by the responder.</li>
<li>The STUN Binding Requests generated by the initiator MAY include the USE-CANDIDATE attribute to indicate that the initiator wishes to cease checks for this component.</li> <li>The STUN Binding Requests generated by the initiator MAY include the USE-CANDIDATE attribute to indicate that the initiator wishes to cease checks for this component.</li>

View File

@ -199,7 +199,7 @@ INITIATOR RESPONDER
</tr> </tr>
<tr> <tr>
<td>Permissive</td> <td>Permissive</td>
<td>Server reflexive or peer reflexive candidate discovered via STUN (see &rfc5489;)</td> <td>Server reflexive or peer reflexive candidate discovered via STUN (see &rfc5389;)</td>
</tr> </tr>
</table> </table>
</section2> </section2>

View File

@ -73,7 +73,7 @@
</header> </header>
<section1 topic='Introduction' anchor='intro'> <section1 topic='Introduction' anchor='intro'>
<p>An XMPP client or other entity may need to discover services external to the XMPP network in order to complete certain XMPP-related use cases. One example is the discovery of STUN servers (see &rfc5489;) and STUN relays (see &turn;) for the sake of negotiating media exchanges via &xep0176;. <note>The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service for discovery of STUN servers, as documented at &lt;<link url='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>&gt;, but has been broadened in scope to address additional use cases if desired.</note> An XMPP entity can already discover such external services in several ways, including:</p> <p>An XMPP client or other entity may need to discover services external to the XMPP network in order to complete certain XMPP-related use cases. One example is the discovery of STUN servers (see &rfc5389;) and STUN relays (see &turn;) for the sake of negotiating media exchanges via &xep0176;. <note>The protocol specified herein is functionally equivalent to the protocol currently used in the Google Talk service for discovery of STUN servers, as documented at &lt;<link url='http://code.google.com/apis/talk/jep_extensions/jingleinfo.html'>http://code.google.com/apis/talk/jep_extensions/jingleinfo.html</link>&gt;, but has been broadened in scope to address additional use cases if desired.</note> An XMPP entity can already discover such external services in several ways, including:</p>
<ol> <ol>
<li>The service is specified in the application's default settings.</li> <li>The service is specified in the application's default settings.</li>
<li>The service is manually added into the application's configuration by a human user.</li> <li>The service is manually added into the application's configuration by a human user.</li>

View File

@ -543,7 +543,7 @@ THE SOFTWARE.
<!ENTITY rfc5054 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5054'>RFC 5054</link></span> <note>RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication &lt;<link url='http://tools.ietf.org/html/rfc5054'>http://tools.ietf.org/html/rfc5054</link>&gt;.</note>" > <!ENTITY rfc5054 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5054'>RFC 5054</link></span> <note>RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication &lt;<link url='http://tools.ietf.org/html/rfc5054'>http://tools.ietf.org/html/rfc5054</link>&gt;.</note>" >
<!ENTITY rfc5081 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5081'>RFC 5081</link></span> <note>RFC 5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication &lt;<link url='http://tools.ietf.org/html/rfc5081'>http://tools.ietf.org/html/rfc5081</link>&gt;.</note>" > <!ENTITY rfc5081 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5081'>RFC 5081</link></span> <note>RFC 5081: Using OpenPGP Keys for Transport Layer Security (TLS) Authentication &lt;<link url='http://tools.ietf.org/html/rfc5081'>http://tools.ietf.org/html/rfc5081</link>&gt;.</note>" >
<!ENTITY rfc5122 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5122'>RFC 5122</link></span> <note>RFC 5122: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://tools.ietf.org/html/rfc5122'>http://tools.ietf.org/html/rfc5122</link>&gt;.</note>" > <!ENTITY rfc5122 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5122'>RFC 5122</link></span> <note>RFC 5122: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://tools.ietf.org/html/rfc5122'>http://tools.ietf.org/html/rfc5122</link>&gt;.</note>" >
<!ENTITY rfc5489 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5489'>RFC 5489</link></span> <note>RFC 5489: Session Traversal Utilities for NAT (STUN) &lt;<link url='http://tools.ietf.org/html/rfc5489'>http://tools.ietf.org/html/rfc5489</link>&gt;.</note>" > <!ENTITY rfc5389 "<span class='ref'><link url='http://tools.ietf.org/html/rfc5389'>RFC 5389</link></span> <note>RFC 5389: Session Traversal Utilities for NAT (STUN) &lt;<link url='http://tools.ietf.org/html/rfc5389'>http://tools.ietf.org/html/rfc5389</link>&gt;.</note>" >
<!-- Internet-Drafts --> <!-- Internet-Drafts -->