[xmpp] Unicode Version Interop Concerns in JIDs

[Ralph Meijer <[e-mail]>]

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?

[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>

-- 
ralphm