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

2.4rc1

This commit is contained in:
stpeter 2011-12-16 10:05:04 -07:00
parent fe8f519fbe
commit 92322ca2a1
1 changed files with 29 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

29
xep-0077.xml
View File

@ -11,6 +11,7 @@
&LEGALNOTICE;
<number>0077</number>
<status>Final</status>
<interim/>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
@ -23,6 +24,12 @@
<url>http://www.xmpp.org/schemas/iq-register.xsd</url>
</schemaloc>
&stpeter;
<revision>
<version>2.4rc1</version>
<date>2011-12-16</date>
<initials>psa</initials>
<remark><p>Defined service discovery support.</p></remark>
</revision>
<revision>
<version>2.3</version>
<date>2009-09-15</date>
@ -604,6 +611,28 @@
<section1 topic='Error Handling' anchor='errors'>
<p>As defined herein, the 'jabber:iq:register' namespace supports both the old (HTTP-style) error codes and the extensible error classes and conditions specified in XMPP Core. A compliant server or service implementation MUST support both old-style and new-style error handling. A compliant client implementation SHOULD support both. For mappings of HTTP-style errors to XMPP-style conditions, refer to &xep0086;.</p>
</section1>
<section1 topic='Determining Support' anchor='disco'>
<p>If an entity supports the protocol defined herein, it SHOULD report that by including a Service Discovery feature of "jabber:iq:register" in response to disco#info requests.</p>
<example caption="Service discovery information request"><![CDATA[
<iq from='marlowe.lit'
id='jzg2d175'
to='shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
]]></example>
<example caption="Service discovery information response"><![CDATA[
<iq from='shakespeare.lit'
id='jzg2d175'
to='marlowe.lit'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='jabber:iq:register'/>
</query>
</iq>
]]></example>
<p>Although connecting clients typically determine support during stream negotiation via the stream feature, the service discovery feature is helpful for server-to-server connections as well as for clients that are already connected (e.g., to determine if password changes are possible in-band).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>In-band registration is usually not included in other messaging protocols (for example, SMTP does not include a method for registering with an email server), often for reasons of security. The registration methods defined herein are known to be insecure and SHOULD NOT be used unless the channel between the registrant and the entity that accepts registration has been secured. For these reasons, the deployment of in-band registration is a policy matter and a given deployment MAY choose to disable in-band registration and password changes. Furthermore, this document should be deprecated as soon as a successor protocol is defined and implemented.</p>
</section1>