Re: Unicode Version Interop Concerns in JIDs
Waqas Hussain <[email protected]> Mon, 23 Sep 2019 16:11:25 -0400
| Newsgroups | gmane.ietf.xmpp |
|---|---|
| Message-ID | <CALm9TZ8zba_ubSX=WvOSqFib_MMYR5P4jp+_4wc5DeRCU09Q7w@mail.gmail.com> |
--===============7940504763221035747== Content-Type: multipart/alternative; boundary="000000000000e1c9b705933e0667" --000000000000e1c9b705933e0667 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Sep 10, 2019 at 10:39 AM Ralph Meijer <[email protected]> wrote: > Hi, > > Recently, there's been a discussion in the XSF Discussion room [1] about > interop issues in the face of different Unicode versions used for > processing XMPP Addresses, or JIDs. That particular discussion was > mostly focused on nicknames in Multi-User Chat (MUC) rooms, which are > encoded in the resourcepart of a JID, but is a concern for other address > handling. As I suggested giving this topic a wider audience, I write on > behalf of those involved in the initial discussion. > > Ever since RFC 6122 was obsoleted by RFC 7622 [2], both titled =E2=80=9CX= MPP: > Address Format=E2=80=9D, resourceprep (which was fixed to Unicode 3.2) wa= s > replaced by PR=C3=89CIS processing as discussed in section 3.4. This in t= urn > the the resourcepart is a OpaqueString profile of the PRECIS > FreeformClass as defined in RFC 7613 [3], section 4.2 and RFC 7564 [4], > section 4.3 respectively. The idea is that in the face of newer Unicode > versions, application can make use of the new codepoints therein. > > RFC 7622 has extensive texts on JID handling, but there is uncertaintly > over when servers, services like MUC, and clients, should be liberal or > strict when checking JIDs. Different implementations perform their > processing based on differing versions of Unicode, implementations have > install bases still depending on older versions of the software and thus > the Unicode version they check against, and finally, there are > implementations and deployments performing the obsoleted stringprep. > > A particular example is the following. Say a MUC service (including its > server-to-server (s2s) handling) checks against Unicode version 12. One > user, with a client and their server checking against Unicode >=3D9, > chooses to use the nickname 'I=E2=99=A5=F0=9F=A5=93' (I love bacon). The = MUC service > assumes everything is fine, and the occupant JID becomes > [email protected]/I=E2=99=A5=F0=9F=A5=93. Both the BLACK HEART SUIT= (U+2665) and > BACON (U+1F953) are in the Symbols, Other (So) category, and thus valid > for FreeformClass. > > Now another user comes along, using a server that supports Unicode 6.3. > Since BACON wasn't defined before Unicode 9, its code point is > unassigned. When receiving presence from the other user, what should the > receiving server do? > > a) It is liberal in what it accepts from other servers, it passes > incoming remote stanzas on to the client. > > b) It is strict, and sends back a <jid-malformed/>, which likely boots > the recipient from the room. > > c) In case a), if it wants to use private messaging towards the > occupant JID, their own server might reject this with a similar > <jid-malformed/> error. > > The above is just an example. MIX [5] refers to RFC 7700 [6], obsoleted > by RFC 8266, for preparing nicknames, which in turn also depends on > FreeformClass, and thus exhibiting similar concerns, but not on the > routing level. > > Basically the question comes down to: how do we robustly handle > different Unicode Versions in clients, services, and servers? > > [1] <xmpp:[email protected]> > [2] RFC 7622: XMPP: Address Format > <https://tools.ietf.org/html/rfc7622> > [3] RFC 7613: PRECIS Representing Usernames and Passwords > <https://tools.ietf.org/html/rfc7613> > [4] RFC 7564: PRECIS in Application Protocols > <https://tools.ietf.org/html/rfc7564> > [5] XEP-0369: Mediated Information eXchange (MIX) > <https://xmpp.org/extensions/xep-0369.html> > [6] <https://tools.ietf.org/html/rfc7700> > [7] RFC 8266: PRECIS Representing Nicknames > <https://tools.ietf.org/html/rfc8266> > > -- > ralphm > > _______________________________________________ > xmpp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/xmpp There's an old thread on this from 2011 on the IETF list. I don't believe the core compatibility issue ever got resolved. See this message and the connected thread: https://mailarchive.ietf.org/arch/msg/xmpp/A2PT_EpDpR1swKbHC_te0NWwRgs We also lack any form of advertisement of supported unicode version by a remote entity, which is unfortunate. A stream feature and a caps hash may be useful. -- Waqas --000000000000e1c9b705933e0667 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"><div= dir=3D"ltr" class=3D"gmail_attr">On Tue, Sep 10, 2019 at 10:39 AM Ralph Me= ijer <<a href=3D"mailto:[email protected]">[email protected]</a>> wrote:<br></d= iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord= er-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br> <br> Recently, there's been a discussion in the XSF Discussion room [1] abou= t <br> interop issues in the face of different Unicode versions used for <br> processing XMPP Addresses, or JIDs. That particular discussion was <br> mostly focused on nicknames in Multi-User Chat (MUC) rooms, which are <br> encoded in the resourcepart of a JID, but is a concern for other address <b= r> handling. As I suggested giving this topic a wider audience, I write on <br= > behalf of those involved in the initial discussion.<br> <br> Ever since RFC 6122 was obsoleted by RFC 7622 [2], both titled =E2=80=9CXMP= P: <br> Address Format=E2=80=9D, resourceprep (which was fixed to Unicode 3.2) was = <br> replaced by PR=C3=89CIS processing as discussed in section 3.4. This in tur= n <br> the the resourcepart is a OpaqueString profile of the PRECIS <br> FreeformClass as defined in RFC 7613 [3], section 4.2 and RFC 7564 [4], <br= > section 4.3 respectively. The idea is that in the face of newer Unicode <br= > versions, application can make use of the new codepoints therein.<br> <br> RFC 7622 has extensive texts on JID handling, but there is uncertaintly <br= > over when servers, services like MUC, and clients, should be liberal or <br= > strict when checking JIDs. Different implementations perform their <br> processing based on differing versions of Unicode, implementations have <br= > install bases still depending on older versions of the software and thus <b= r> the Unicode version they check against, and finally, there are <br> implementations and deployments performing the obsoleted stringprep.<br> <br> A particular example is the following. Say a MUC service (including its <br= > server-to-server (s2s) handling) checks against Unicode version 12. One <br= > user, with a client and their server checking against Unicode >=3D9, <br= > chooses to use the nickname 'I=E2=99=A5=F0=9F=A5=93' (I love bacon)= .. The MUC service <br> assumes everything is fine, and the occupant JID becomes <br> [email protected]/I=E2=99=A5=F0=9F=A5=93. Both the BLACK HEART SUIT (= U+2665) and <br> BACON (U+1F953) are in the Symbols, Other (So) category, and thus valid <br= > for FreeformClass.<br> <br> Now another user comes along, using a server that supports Unicode 6.3. <br= > Since BACON wasn't defined before Unicode 9, its code point is <br> unassigned. When receiving presence from the other user, what should the <b= r> receiving server do?<br> <br> =C2=A0 a) It is liberal in what it accepts from other servers, it passes <b= r> incoming remote stanzas on to the client.<br> <br> =C2=A0 b) It is strict, and sends back a <jid-malformed/>, which like= ly boots <br> the recipient from the room.<br> <br> =C2=A0 c) In case a), if it wants to use private messaging towards the <br> occupant JID, their own server might reject this with a similar <br> <jid-malformed/> error.<br> <br> The above is just an example. MIX [5] refers to RFC 7700 [6], obsoleted <br= > by RFC 8266, for preparing nicknames, which in turn also depends on <br> FreeformClass, and thus exhibiting similar concerns, but not on the <br> routing level.<br> <br> Basically the question comes down to: how do we robustly handle <br> different Unicode Versions in clients, services, and servers?<br> <br> [1] <<a href=3D"mailto:xmpp%[email protected]" target=3D"_blank">xmpp:x= [email protected]</a>><br> [2] RFC 7622: XMPP: Address Format<br> =C2=A0 =C2=A0 =C2=A0<<a href=3D"https://tools.ietf.org/html/rfc7622" rel= =3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/rfc7622</a>&g= t;<br> [3] RFC 7613: PRECIS Representing Usernames and Passwords<br> =C2=A0 =C2=A0 =C2=A0<<a href=3D"https://tools.ietf.org/html/rfc7613" rel= =3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/rfc7613</a>&g= t;<br> [4] RFC 7564: PRECIS in Application Protocols<br> =C2=A0 =C2=A0 =C2=A0<<a href=3D"https://tools.ietf.org/html/rfc7564" rel= =3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/rfc7564</a>&g= t;<br> [5] XEP-0369: Mediated Information eXchange (MIX)<br> =C2=A0 =C2=A0 =C2=A0<<a href=3D"https://xmpp.org/extensions/xep-0369.htm= l" rel=3D"noreferrer" target=3D"_blank">https://xmpp.org/extensions/xep-036= 9.html</a>><br> [6] <<a href=3D"https://tools.ietf.org/html/rfc7700" rel=3D"noreferrer" = target=3D"_blank">https://tools.ietf.org/html/rfc7700</a>><br> [7] RFC 8266: PRECIS Representing Nicknames<br> =C2=A0 =C2=A0 =C2=A0<<a href=3D"https://tools.ietf.org/html/rfc8266" rel= =3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/rfc8266</a>&g= t;<br> <br> -- <br> ralphm<br> <br> _______________________________________________<br> xmpp mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/xmpp" rel=3D"noreferrer" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/xmpp</a></blockquote= ><div><br></div><div><br></div><div>There's an old thread on this from = 2011 on the IETF list. I don't believe the core compatibility issue eve= r got resolved. See this message and the connected thread:</div><div><br></= div><div><a href=3D"https://mailarchive.ietf.org/arch/msg/xmpp/A2PT_EpDpR1s= wKbHC_te0NWwRgs">https://mailarchive.ietf.org/arch/msg/xmpp/A2PT_EpDpR1swKb= HC_te0NWwRgs</a><br></div><div><br></div><div>We also lack any form of adve= rtisement of supported unicode version by a remote entity, which is unfortu= nate. A stream feature and a caps hash may be useful.</div><div><br></div><= div>--</div><div>Waqas</div><div><br></div></div></div> --000000000000e1c9b705933e0667-- --===============7940504763221035747== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ xmpp mailing list [email protected] https://www.ietf.org/mailman/listinfo/xmpp --===============7940504763221035747==--