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

corrected examples 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3966 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2010-02-22 04:23:33 +00:00
parent 89502bf9bf
commit a498e49806
1 changed files with 0 additions and 18 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
xep-0078.xml
View File

@ -181,17 +181,6 @@
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='User Authenticates with Server' anchor='usecases-auth'>
<p>In order to determine which fields are required for authentication with a server, a client SHOULD first send an IQ get to the server. A client SHOULD NOT attempt to guess at the required fields, since the nature of the required data is subject to service provisioning.</p>
<example caption='Client Opens Stream to Server'><![CDATA[
<stream:stream to='shakespeare.lit'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
]]></example>
<example caption='Server Opens Streams to Client'><![CDATA[
<stream:stream from='shakespeare.lit'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='3EE948B0'>
]]></example>
<example caption='Client Requests Authentication Fields from Server'><![CDATA[
<iq type='get' to='shakespeare.lit' id='auth1'>
<query xmlns='jabber:iq:auth'/>
@ -275,19 +264,12 @@
<section1 topic='Stream Feature' anchor='streamfeature'>
<p><cite>RFC 3920</cite> defines methods for advertising feature support during stream negotiation. It may be desirable for a server to advertise support for non-SASL authentication as a stream feature. The namespace for reporting support within &lt;stream:features/&gt; is "http://jabber.org/features/iq-auth". Upon receiving a stream header qualified by the 'jabber:client' namespace, a server that returns stream features SHOULD also announce support for non-SASL authentication by including the relevant stream feature. Exactly when a server advertises the iq-auth stream feature is up to the implementation or deployment (e.g., a server MAY advertise this feature only after successful TLS negotiation or if the channel is encrypted via the older SSL method). Obviously, this does not apply to servers that do not support stream features (e.g., older servers that do not comply with XMPP 1.0).</p>
<example caption='Advertising non-SASL authentication as a stream feature'><![CDATA[
<?xml version='1.0' encoding='utf-8'?>
<stream:stream xmlns:stream='http://etherx.jabber.org/streams/'
xmlns='jabber:client'
from='somedomain'
version='1.0'>
<stream:features>
...
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
<auth xmlns='http://jabber.org/features/iq-auth'/>
...
</stream:features>
]]></example>
<p>A server SHOULD NOT advertise non-SASL authentication to another server (i.e., if the initial stream header was qualified by the 'jabber:server' namespace).</p>