Re: [xmpp] Unicode Version Interop Concerns in JIDs

[Alexey Melnikov <[e-mail]>]

Hi Ralph,

On 10/09/2019 15:38, Ralph Meijer 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
> [e-mail]/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?

I agree this is a problem and as you demonstrate above there might not
be any simple solution for it. I think this issue deserve a document to
be written (an Internet Draft or an XSF document).

My personal inclination is that clients/servers should be liberal with
unassigned codepoints in JIDs that they don't control (i.e. servers can
be strict with local JIDs, but should be liberal with remote JIDs),
which I think is either case a) or an extension of it.

Best Regards,
Alexey

> [1] <xmpp:[e-mail]>
> [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>
>