Re: [xmpp] Unicode Version Interop Concerns in JIDs

On Tue, Sep 10, 2019 at 10:39 AM Ralph Meijer <ralphm@ik.nu> 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 “XMPP:
> Address Format”, resourceprep (which was fixed to Unicode 3.2) was
> replaced by PRÉCIS processing as discussed in section 3.4. This in turn
> 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 >=9,
> chooses to use the nickname 'I♥🥓' (I love bacon). The MUC service
> assumes everything is fine, and the occupant JID becomes
> room@muc.server.example/I♥🥓. 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:xsf@muc.xmpp.org>
> [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
> xmpp@ietf.org
> 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