After browsing the standards, it seems to me that the whole [EMAIL PROTECTED] string should be sent. Here are some relevant snippets:
Extensible Messaging and Presence Protocol (XMPP): Core http://www.ietf.org/rfc/rfc3920.txt | 3. Addressing Scheme | | 3.5. Determination of Addresses | [...] | After SASL negotiation (Section 6) and, if appropriate, Resource | Binding (Section 7), the receiving entity for a stream MUST determine | the initiating entity's JID. | [...] | For client-to-server communications, the "bare JID" (<[EMAIL PROTECTED]>) | SHOULD be the authorization identity, derived from the authentication | identity, as defined in [SASL], if no authorization identity was | specified during SASL negotiation (Section 6); the resource | identifier portion of the "full JID" (<[EMAIL PROTECTED]/resource>) SHOULD | be the resource identifier negotiated by the client and server during | Resource Binding (Section 7). | | The receiving entity MUST ensure that the resulting JID (including | node identifier, domain identifier, resource identifier, and | separator characters) conforms to the rules and formats defined | earlier in this section; to meet this restriction, the receiving | entity may need to replace the JID sent by the initiating entity with | the canonicalized JID as determined by the receiving entity. | [...] | | 6. Use of SASL | | 6.1. Overview | | XMPP includes a method for authenticating a stream by means of an | XMPP-specific profile of the Simple Authentication and Security Layer | (SASL) protocol [SASL]. SASL provides a generalized method for | adding authentication support to connection-based protocols, and XMPP | uses a generic XML namespace profile for SASL that conforms to the | profiling requirements of [SASL]. | | The following rules apply: | [...] | 7. If the initiating entity wishes to act on behalf of another | entity and the selected SASL mechanism supports transmission of | an authorization identity, the initiating entity MUST provide an | authorization identity during SASL negotiation. If the | initiating entity does not wish to act on behalf of another | entity, it MUST NOT provide an authorization identity. As | specified in [SASL], the initiating entity MUST NOT provide an | authorization identity unless the authorization identity is | different from the default authorization identity derived from | the authentication identity as described in [SASL]. If provided, | the value of the authorization identity MUST be of the form | <domain> (i.e., a domain identifier only) for servers and of the | form <[EMAIL PROTECTED]> (i.e., node identifier and domain identifier) | for clients. | [...] | | 6.2. Narrative | [...] | 3. The initiating entity selects a mechanism by sending an <auth/> | element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' | namespace to the receiving entity and including an appropriate | value for the 'mechanism' attribute. This element MAY contain | XML character data (in SASL terminology, the "initial response") | if the mechanism supports or requires it; if the initiating | entity needs to send a zero-length initial response, it MUST | transmit the response as a single equals sign ("="), which | indicates that the response is present but contains no data. | [...] | | 6.3. SASL Definition | | The profiling requirements of [SASL] require that the following | information be supplied by a protocol definition: | [...] | use of the authorization identity: The authorization identity may be | used by xmpp to denote the non-default <[EMAIL PROTECTED]> of a client | or the sending <domain> of a server. Simple Authentication and Security Layer (SASL) http://tools.ietf.org/html/rfc4422 | 3.4.1. Authorization Identity String | | The authorization identity string is a sequence of zero or more | Unicode [Unicode] characters, excluding the NUL (U+0000) character, | representing the identity to act as. | | If the authorization identity string is absent, the client is | requesting to act as the identity the server associates with the | client's credentials. An empty string is equivalent to an absent | authorization identity. | | A non-empty authorization identity string indicates that the client | wishes to act as the identity represented by the string. In this | case, the form of identity represented by the string, as well as the | precise syntax and semantics of the string, is protocol specific. | | While the character encoding schema used to transfer the | authorization identity string in the authentication exchange is | mechanism specific, mechanisms are expected to be capable of carrying | the entire Unicode repertoire (with the exception of the NUL | character). | | 4. Protocol Requirements | | In order for a protocol to offer SASL services, its specification | MUST supply the following information: | | [...] | | 4) Prescribe the syntax and semantics of non-empty authorization | identity strings (see Section 3.4.1). | | In order to avoid interoperability problems due to differing | normalizations, the protocol specification MUST detail precisely | how and where (client or server) non-empty authorization identity | strings are prepared, including all normalizations, for comparison | and other applicable functions to ensure proper function. | | Specifications are encouraged to prescribe use of existing | authorization identity forms as well as existing string | representations, such as simple user names [RFC4013]. | | Where the specification does not precisely prescribe how | identities in SASL relate to identities used elsewhere in the | protocol, for instance, in access control policy statements, it | may be appropriate for the protocol to provide a facility by which | the client can discover information (such as the representation of | the identity used in making access control decisions) about | established identities for these uses. The PLAIN Simple Authentication and Security Layer (SASL) Mechanism http://www.ietf.org/rfc/rfc4616.txt | 2. PLAIN SASL Mechanism | | The mechanism consists of a single message, a string of [UTF-8] | encoded [Unicode] characters, from the client to the server. The | client presents the authorization identity (identity to act as), | followed by a NUL (U+0000) character, followed by the authentication | identity (identity whose password will be used), followed by a NUL | (U+0000) character, followed by the clear-text password. As with | other SASL mechanisms, the client does not provide an authorization | identity when it wishes the server to derive an identity from the | credentials and use that as the authorization identity. | | [...] | | The authorization identity (authzid), authentication identity | (authcid), password (passwd), and NUL character deliminators SHALL be | transferred as [UTF-8] encoded strings of [Unicode] characters. As | the NUL (U+0000) character is used as a deliminator, the NUL (U+0000) | character MUST NOT appear in authzid, authcid, or passwd productions. | | The form of the authzid production is specific to the application- | level protocol's SASL profile [SASL]. The authcid and passwd | productions are form-free. Use of non-visible characters or | characters that a user may be unable to enter on some keyboards is | discouraged. -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
