moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

1.2rc1: provisional fixes to examples and clarifications to text

Browse Source 
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3927 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2010-02-15 20:34:14 +00:00
parent c12adb4aa4
commit ea40cf9684
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
xep-0106.xml
View File

@ -99,7 +99,7 @@
<ol>
<li><p>The escaping mechanism shall apply to the node identitier portion of a JID only, and MUST NOT be applied to domain identifiers or resource identifiers.</p></li>
<li><p>Escaped JIDs MUST conform to the definition of a Jabber ID as specified in <cite>RFC 3920</cite>, including the Nodeprep profile of stringprep. In particular this means that even after passing through Nodeprep, the JID MUST be valid, with the result that Unicode look-alikes like U+02BC (Modifier Letter Apostrophe) MUST NOT be used.</p></li>
<li><p>It MUST NOT be possible for clients to use this escaping mechanism to avoid the goal of stringprep; namely, that JIDs that look alike should have same character representation after being processed by stringprep. Therefore, this mechanism MUST NOT be applied to any characters other than the disallowed characters. <note>In certain circumstances the escaping character itself ("\") may also be escaped.</note></p></li>
<li><p>It MUST NOT be possible for clients to use this escaping mechanism to avoid the goal of stringprep; namely, that JIDs that look alike should have same character representation after being processed by stringprep. Therefore, this mechanism MUST NOT be applied to any characters other than the disallowed characters (with the exception that, in certain circumstances, the escaping character itself ("\") might also be escaped).</p></li>
<li><p>Existing JIDs that include portions of the escaping mechanism MUST continue to be valid.</p></li>
<li><p>The escaping mechanism MUST NOT break commonly deployed Jabber/XMPP software implementations such as servers, components, gateways, and clients.</p></li>
<li><p>The escaping mechanism SHOULD NOT place undue strain upon server implementations; implementations or deployments that do not need to unescape SHOULD be able to ignore the escaping mechanism.</p></li>
@ -197,10 +197,11 @@
<p>Regarding step three, it is possible for some non-XMPP addresses to contain character sequences that correspond to JID-escaped characters (e.g., "\27"). Consider a Wireless Village address of &lt;wv:\3and\2is\5cool@example.com&gt; -- if that address were directly converted into a JID, the resulting XMPP address would be \3and\2is\5cool@example.com, which could be construed as :nd\2is\ool@example.com if JID escaping logic is applied. Therefore the leading \ character and the \ character before the character sequence 5c MUST be converted to the character sequence "\5c" during the transformation, leading to a JID of \5c3and\2is\5c5cool@example.com (which would be presented to a human user as \3and\2is\5cool@example.com).</p>
</section2>
<section2 topic='Exceptions' anchor='bizrules-exceptions'>
<p>In order to maintain as much backward compatibility as possible, partial escape sequences and escape sequences corresponding to characters not on the list of disallowed characters MUST be ignored.</p>
<p>In order to maintain as much backward compatibility as possible, partial escape sequences and escape sequences corresponding to characters not on the list of disallowed characters MUST be ignored (with the exception of the escaping character '\' itself in the rare case when the source address includes the sequence '\5c').</p>
<example caption='Partial escape sequence'><strong>\2plus\2is\4</strong> is not modified by escaping or unescaping transformations.</example>
<example caption='Invalid escape sequence 1'><strong>foo\bar</strong> is not modified (to <strong>foo&#186;r</strong>) by escaping or unescaping transformations.</example>
<example caption='Invalid escape sequence 2'><strong>foob\41r</strong> is not modified (to <strong>foobAr</strong>) by escaping or unescaping transformations.</example>
<p>However, \5c would be escaped if found in the source address (e.g., a source address of "c:\5commas@example.com" would be escaped to "c\3a\5c5commas@example.com") and unescaped if contained in the JID-on-the-wire (e.g., a JID-on-the-wire of "c\3a\5c5commas@example.com" would be unescaped back to "c:\5commas@example.com").</p>
</section2>
<section2 topic='JID Escaping vs. Older Methods' anchor='bizrules-othermethods'>
<p>When a client attempts to communicate with another entity through a gateway, it needs to know which escaping mechanism to use. A client MUST assume that the gateway does not support the JID escaping mechanism unless it explicitly discovers support for the <strong>jid\20escaping</strong> [sic] feature as described under <link url='#disco'>Determining Support</link>. If there are any errors in the service discovery exchange or if support for JID escaping is not discovered, the client SHOULD proceed as follows:</p>
@ -232,9 +233,9 @@
<tr><td>6</td><td>::foo::@example.com</td><td>\3a\3afoo\3a\3a@example.com</td><td>::foo::@example.com</td></tr>
<tr><td>7</td><td>&lt;foo&gt;@example.com</td><td>\3cfoo\3e@example.com</td><td>&lt;foo&gt;@example.com</td></tr>
<tr><td>8</td><td>user@host@example.com</td><td>user\40host@example.com</td><td>user@host@example.com</td></tr>
<tr><td>9</td><td>c:\net@example.com</td><td>c\3a\5cnet@example.com</td><td>c:\net@example.com</td></tr>
<tr><td>10</td><td>c:\\net@example.com</td><td>c\3a\5c\5cnet@example.com</td><td>c:\\net@example.com</td></tr>
<tr><td>11</td><td>c:\cool stuff@example.com</td><td>c\3a\5ccool\20stuff@example.com</td><td>c:\cool stuff@example.com</td></tr>
<tr><td>9</td><td>c:\net@example.com</td><td>c\3a\net@example.com</td><td>c:\net@example.com</td></tr>
<tr><td>10</td><td>c:\\net@example.com</td><td>c\3a\\net@example.com</td><td>c:\\net@example.com</td></tr>
<tr><td>11</td><td>c:\cool stuff@example.com</td><td>c\3a\cool\20stuff@example.com</td><td>c:\cool stuff@example.com</td></tr>
<tr><td>12</td><td>c:\5commas@example.com</td><td>c\3a\5c5commas@example.com</td><td>c:\5commas@example.com</td></tr>
</table>
</section2>