1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00

XEP-0106: Update RFC 2822 reference to RFC 5322

This commit is contained in:
Sam Whited 2016-07-20 14:19:01 -05:00
parent d3e38e0426
commit 7cacdba6df

View File

@ -96,7 +96,7 @@
<li>U+0040 (@)</li> <li>U+0040 (@)</li>
</ul> </ul>
<p>Furthermore, since localparts use the UsernameCaseMapped profile (&rfc7613;) of PRECIS any space character disallowed by category N (section 9.14) of the &rfc7564; IdentifierClass is also forbidden.</p> <p>Furthermore, since localparts use the UsernameCaseMapped profile (&rfc7613;) of PRECIS any space character disallowed by category N (section 9.14) of the &rfc7564; IdentifierClass is also forbidden.</p>
<p>This restriction is an inconvenience for users who have one or more of these "disallowed characters" in their desired usernames, particularly in the case of the apostrophe character, which is common in names like O'Hara and D'Artagnan. The restriction is a positive hardship if existing email addresses are mapped to JIDs, since some of the disallowed characters are allowed in the username portion of an email address (specifically, the characters &amp; ' / as described in Sections 3.2.4 and 3.2.5 of &rfc2822;).</p> <p>This restriction is an inconvenience for users who have one or more of these "disallowed characters" in their desired usernames, particularly in the case of the apostrophe character, which is common in names like O'Hara and D'Artagnan. The restriction is a positive hardship if existing email addresses are mapped to JIDs, since some of the disallowed characters are allowed in the username portion of an email address (specifically, the characters &amp; ' / as described in Sections 3.2.3 and 3.2.4 of &rfc5322;).</p>
<p>To overcome this restriction, we define a way to escape the disallowed characters in JIDs. An escaped JID contains none of the disallowed characters and therefore can be transported by native XMPP implementations without modification (e.g., existing XMPP servers do not require modification in order to handle escaped JIDs). The escaped JID is unescaped only for presentation to a human user (typically by an XMPP client) or for gatewaying to a non-XMPP system (such as an LDAP database or a messaging system that does not use XMPP).</p> <p>To overcome this restriction, we define a way to escape the disallowed characters in JIDs. An escaped JID contains none of the disallowed characters and therefore can be transported by native XMPP implementations without modification (e.g., existing XMPP servers do not require modification in order to handle escaped JIDs). The escaped JID is unescaped only for presentation to a human user (typically by an XMPP client) or for gatewaying to a non-XMPP system (such as an LDAP database or a messaging system that does not use XMPP).</p>
</section1> </section1>
@ -246,8 +246,8 @@
</table> </table>
</section2> </section2>
<section2 topic='Email Addresses' anchor='examples-email'> <section2 topic='Email Addresses' anchor='examples-email'>
<p>The address format for an Internet mailbox is specified in <cite>RFC 2822</cite>. The identifier of interest in this context is the "addr-spec" address and more particularly the "dot-atom-text" rule specified in Section 3.2.4, i.e., the email address shorn of angle brackets, display names, comments, quoted strings, and the like. Because some deployments of XMPP messaging systems may want to re-use existing email addresses as JIDs, it is helpful to define how to transform an email address into a JID.</p> <p>The address format for an Internet mailbox is specified in <cite>RFC 5322</cite>. The identifier of interest in this context is the "addr-spec" address and more particularly the "dot-atom-text" rule specified in Section 3.2.3, i.e., the email address shorn of angle brackets, display names, comments, quoted strings, and the like. Because some deployments of XMPP messaging systems may want to re-use existing email addresses as JIDs, it is helpful to define how to transform an email address into a JID.</p>
<p>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. <note>This specification does not cover recent efforts to define internationalized email addresses.</note> 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 &amp; ' / as described in Sections 3.2.4 and 3.2.5 of <cite>RFC 2822</cite>. In order to transform these characters, a compliant implementation MUST use the methods specified herein.</p> <p>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. <note>This specification does not cover recent efforts to define internationalized email addresses.</note> 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 &amp; ' / as described in Sections 3.2.3 and 3.2.4 of <cite>RFC 5322</cite>. In order to transform these characters, a compliant implementation MUST use the methods specified herein.</p>
<example caption='An Email Address Containing JID-Disallowed Characters'><![CDATA[ <example caption='An Email Address Containing JID-Disallowed Characters'><![CDATA[
here's_a_wild_&_/cr%zy/_address@example.com here's_a_wild_&_/cr%zy/_address@example.com
]]></example> ]]></example>
@ -311,7 +311,7 @@ sip:here%27s_a_wild_%26_%2Fcr%zy%2F_address@example.com
]]></example> ]]></example>
</section2> </section2>
<section2 topic='IM and Presence Addresses' anchor='examples-im'> <section2 topic='IM and Presence Addresses' anchor='examples-im'>
<p>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 <cite>RFC 2822</cite>) 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 &amp; ' / allowed in an email address but disallowed in an XMPP localpart are also allowed in a basic IM or PRES address).</p> <p>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 <cite>RFC 5322</cite>) 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 &amp; ' / allowed in an email address but disallowed in an XMPP localpart are also allowed in a basic IM or PRES address).</p>
<example caption='A Basic im: URI Containing JID-Disallowed Characters'><![CDATA[ <example caption='A Basic im: URI Containing JID-Disallowed Characters'><![CDATA[
im:here%27s_a_wild_%26_%2Fcr%zy%2F_address@example.com im:here%27s_a_wild_%26_%2Fcr%zy%2F_address@example.com
]]></example> ]]></example>