From 2f0152b2592955ed9ff020c02b2c96bb5ef5288c Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Thu, 21 Jul 2016 08:53:07 -0500 Subject: [PATCH] XEP-0106: Fix example whitespace --- xep-0106.xml | 92 ++++++++++++++++++++++++++-------------------------- 1 file changed, 46 insertions(+), 46 deletions(-) diff --git a/xep-0106.xml b/xep-0106.xml index adfcb49f..2c1ef591 100644 --- a/xep-0106.xml +++ b/xep-0106.xml @@ -142,14 +142,14 @@

* Note: The character sequence \20 MUST NOT be the first or last character of an escaped localpart. For a similar restriction, see Section 2.4 of RFC 2253.

In the following example, Porthos starts a chat with D'Artagnan, typing into his client the string "d'artagnan@musketeers.lit" (which is escaped by his client to "d\27artagnan@musketeers.lit").

- And do you always forget your eyes when you run? - ]]> +]]>

The unescaping transformations are defined in the following table, whereas the rules that define when to apply these transformations are specified in the Business Rules section of this specification. Typically, unescaping is performed only by a client that wants to display JIDs containing escaped characters to a human user, or by a gateway to some external system (e.g., email or LDAP) that needs to generate identifiers for foreign systems.

@@ -167,13 +167,13 @@ \5c\

In the following example, D'Artagnan the elder sends a message through an SMTP mail gateway (the JID is "treville\40musketeers.lit@smtp.gascon.fr" and the destination email address is "treville@musketeers.lit").

- tréville\40musketeers.lit@smtp.gascon.fr I recommend my son to you. - ]]> +]]> @@ -250,118 +250,118 @@

In general, it is straightforward to transform an email address (i.e., a "dot-atom-text") into a JID, since traditional email addresses allow US-ASCII characters only rather than the nearly full range of Unicode code points allowed in a JID. This specification does not cover recent efforts to define internationalized email addresses. However, there are three characters allowed in the localpart of an email address that are not allowed in the localpart portion of a JID: namely, the characters & ' / as described in Sections 3.2.3 and 3.2.4 of RFC 5322. In order to transform these characters, a compliant implementation MUST use the methods specified herein.

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

(Note: Because the backslash character is forbidden in the "dot-atom-text" construction, an email address should not contain a character sequence that corresponds to one of the escaped characters specified in the Transformations section of this document; therefore, no such examples are shown.)

An email address may also exist in the form of a mailto: URI as specified in &rfc2368;. Before transforming a mailto: URI into a JID, it MUST be URL-decoded and all headers MUST be removed, leaving a mailbox identifier, as shown in the following example.

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

The foregoing examples showed how to transform an email address or mailto: URI into a JID. However, it also may be necessary to convert a JID into an email address or mailto: URI, as shown in the following example.

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

As specified in &rfc3261;, a SIP address (i.e., a sip: or sips: URI) can be quite complex if URI parameters or headers are included. However, a basic SIP address (the combination of the optional "userinfo" and required "hostport" constructions) is essentially similar to an email address (e.g., the same characters & ' / allowed in an email address but disallowed in an XMPP localpart are also allowed in a basic SIP address).

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

The foregoing example showed how to transform a sip: or sips: URI into a JID. However, it also may be necessary to convert a JID into a sip: or sips: URI, as shown in the following example.

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

The im: and pres: URI schemes are specified in &rfc3860; and &rfc3859; respectively. With the exception of headers, an im: or pres: URI is simply a mailbox (as specified in RFC 5322) prepended with the im: or pres: scheme. Thus a basic IM or PRES address (not including optional headers) is essentially similar to an email address (e.g., the same characters & ' / allowed in an email address but disallowed in an XMPP localpart are also allowed in a basic IM or PRES address).

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

The foregoing example showed how to transform an im: or pres: URI into a JID. However, it also may be necessary to convert a JID into an im: or pres: URI, as shown in the following example.

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

The Instant Messaging and Presence Service (IMPS) protocol was originally defined by the Wireless Village consortium and is now maintained by the &OMA;. An IMPS address is formatted as a wv: URI, as specified in &wv-csp;. A basic address (not including a private resource) is of the form <wv:user-id@domain> and an address with a private resource is of the form <wv:user-id/resource@domain>.

The "User-ID" construction is either a mobile phone number (beginning with "+1" for international numbers and a digit for national numbers) or an "Internet-Identity". An "Internet-Identity" may contain any US-ASCII character other than / @ + SP TAB and thus may include the following characters that are disallowed in the localpart of a JID: " & ' / : < > (which characters MUST be escaped when transforming an IMPS address into a JID). However, some of those characters are also reserved in URI syntax (namely the & ' / characters) so those characters will be found in escaped form within a wv: URI.

+]]> ("IMPS")@example.com - ]]> +]]> +]]> ("IMPS")@example.com - ]]> +]]>

Unlike the foregoing address types, IMPS addresses are allowed to contain backslashes. This implies that it is possible for an IMPS address to contain a character sequence that corresponds to one of the escaped character representations for code points that are disallowed in XMPP localparts. An example would be the IMPS address <wv:\3and\2is\5cool@example.com>, where the character sequence "\3a" could be interpreted as the : character (and the character sequence "\5c" as "\") if that IMPS address is directly converted into a JID. Therefore, the leading \ character MUST be transformed to "\5c" (and the source character sequence "\5c" to "\5c5c") in order to avoid possible ambiguity. Thus the transformed JID would be <\5c3and\2is\5c5cool@example.com>, which would be presented to a user as <\3and\2is\5cool@example.com>.

If an IMPS address contains a private resource, a gateway between XMPP and IMPS should process the resource and append it to the end of the JID; however, such gateway behavior is out of scope for this document.

The foregoing example showed how to transform a wv: URI into a JID. However, it also may be necessary to convert a JID into a wv: URI, as shown in the following example.

("IMPS")@example.com - ]]> +]]> +]]> +]]>

Within the Lightweight Directory Access Protocol (see &rfc2251;), a "distinguished name" (DN) is a hierarchically-organized string representation that uniquely identifies a user, system, or organization. It is possible that some messaging systems use LDAP distinguished names to identify entities that can communicate using the system (e.g., this is reputed to be the case for certain releases of the Lotus Sametime system sold by IBM), and in any case it may be helpful to transform an LDAP distinguished name into an XMPP address for identification or addressing purposes.

@@ -372,11 +372,11 @@ CN=D'Artagnan Saint-André,O=Example & Company, Inc.,DC=example,DC=com +]]>

This example assumes that the specified user is identified with a gateway running at st.example.com (note that the backslash escaping the , character in the organization name is removed during the transformation).

+]]> CN=D'Artagnan Saint-André,O=Example & Company, Inc.,DC=example,DC=com@st.example.com @@ -384,13 +384,13 @@ CN=D'Artagnan Saint-André,O=Example & Company, Inc.,DC=example,DC=com@s

The foregoing example showed how to transform an LDAP distinguished name into a JID. However, it also may be necessary to convert a JID into an LDAP distinguished name, as shown in the following example.

+]]> +]]> +]]> CN=D'Artagnan Saint-André,O=Example & Company, Inc.,DC=example,DC=com @@ -399,13 +399,13 @@ CN=D'Artagnan Saint-André,O=Example & Company, Inc.,DC=example,DC=com

&rfc2812; defines the address format for Internet Relay Chat (IRC) entities, which can be servers, channels, or users. The "user" portion of an IRC address may contain any octet except NUL, CR, LF, SP, and "@"; this includes the characters " & ' / : < > \ (which are disallowed in XMPP localparts and therefore MUST be escaped when transforming an IRC address into a JID).

\3address@example.com - ]]> +]]> +]]> \3address@example.com - ]]> +]]>

Like IMPS addresses, IRC addresses are allowed to contain backslashes. This implies that it is possible for an IMPS address to contain a character sequence that corresponds to one of the escaped character representations for code points that are disallowed in XMPP localparts. An example is shown above.

 @@ -419,7 +419,7 @@ somenick!user"&'/:<>\3address@example.com id='info1'> - ]]> +]]>

If the queried entity supports JID escaping, it MUST return a jid\20escaping [sic] feature in its reply.

\3address@example.com - ]]> +]]>