From 92322ca2a1a22c48bdf28de59bdb7b44dc6d14ae Mon Sep 17 00:00:00 2001 From: stpeter Date: Fri, 16 Dec 2011 10:05:04 -0700 Subject: [PATCH] 2.4rc1 --- xep-0077.xml | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/xep-0077.xml b/xep-0077.xml index be3d70eb..9b25a112 100644 --- a/xep-0077.xml +++ b/xep-0077.xml @@ -11,6 +11,7 @@ &LEGALNOTICE; 0077 Final + Standards Track Standards @@ -23,6 +24,12 @@ http://www.xmpp.org/schemas/iq-register.xsd &stpeter; + + 2.4rc1 + 2011-12-16 + psa +

Defined service discovery support.

+
2.3 2009-09-15 @@ -604,6 +611,28 @@

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;.

+ +

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.

+ + + + ]]> + + + + + + ]]> +

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).

+

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.