Re: [xmpp] i18n summary

[Ben Campbell <[e-mail]>]

(As individual)

My understanding of the original reason for splitting out xmpp-address was exactly to allow us to close on the rest of 3920bis and then take the time to handle the IDNA2008 migration right. Hopefully no one takes that to indicate that the group does not care about this. But would it help if we updated the charter milestone list to include a "move xmpp-address to IDNA2008" work item, at a fairly high priority?



On Dec 21, 2010, at 9:55 AM, Peter Saint-Andre wrote:

> Yesterday I had separate chats about internationalization with both
> Alexey Melnikov and Joe Hildebrand. In this message I attempt to
> summarize the issues we face.
> 
> 1. Multiple Stringprep Profiles
> 
> In XMPP, we have multiple stringprep profiles: Nameprep (inherited from
> IDNA2003), Nodeprep, and Resourceprep. In this regard I think that XMPP
> is unique, because as far as I can see all other stringprep customers
> use only one profile (e.g., Nameprep or SASLprep or LDAPprep or a custom
> profile, but never more than one of those) -- see for instance the
> issues logged in the PRECIS WG:
> 
> http://trac.tools.ietf.org/wg/precis/trac/report/6
> 
> 2. Migration
> 
> The fact that we have multiple stringprep profiles means that our
> migration from stringprep-based technologies to non-stringprep-based
> technologies will involve at least two aspects: migration of XMPP
> domainparts from IDNA2003 to IDNA2008 (i.e., for server FQDNs) and
> migration of XMPP localparts from Nodeprep to something new (i.e., for
> registered account names, MUC room names, etc.). I don't think we'll
> need to migrate resourceparts because they are fairly ephemeral, but
> there might be migration issues there, too.
> 
> This implies that *if* we were to legislate an upgrade from IDNA2003 to
> IDNA2008 for domainparts before we have a way to upgrade from Nodeprep
> to something new for localparts, then we would need to complete two
> migrations. IMHO that would be highly sub-optimal. Migration will be a
> lot of work (the scope is yet to be determined, but I think it will be
> fairly large, requiring updates to client and server software, creation
> of migration tools, scrubbing of data at XMPP service providers, etc.).
> Migrating twice would place a significant burden on the XMPP community.
> 
> 3. Preparation and Validation
> 
> One aspect of the move from IDNA2003 to IDNA2008 was a change in the
> "dividing line" between protocol and user interface (see RFC 5895). This
> places more responsibility in the client. In fact, we seem to be coming
> to the conclusion that only the client knows enough about the user's
> intentions, Unicode version, input methods, locale, and other context to
> interpret and prepare strings for sending over the network in the
> various "JID slots" that I mentioned in a previous message ('to' and
> 'from' addresses, roster items, MUC room names, etc.). The server might
> be able to validate some of that input (e.g., because certain Unicode
> codepoints are disallowed), but it doesn't know enough about the user's
> context to prepare the JIDs in every JID slot (indeed, it doesn't even
> have access to many JID slots unless it performs some kind of "deep
> stanza inspection"). This is a major change in the i18n model for XMPP.
> We haven't yet had a chance to think through all the implications of
> that change, nor to define the "dividing line" as it applies to XMPP
> clients and servers (IDNA2008 talks about entities like DNS resolvers
> and domain name registrars, not application clients and servers).
> 
> 4. Desire for Change
> 
> Alexey seemed to be questioning whether the XMPP community wants to
> upgrade from IDNA2003 to IDNA2008. I don't think there is a lack of
> will. To the extent that folks in the XMPP community understand the
> issues (and I don't think they understand i18n all that well, although
> to be fair that's true of most application technologies), they want to
> do the right thing and are not bitterly clinging to their old stringprep
> profiles. Unicode agility is a good thing, and everyone who thinks about
> the topic wants to stay current instead of being tied to Unicode as it
> was defined back in 2002 (i.e., version 3.2). As far as I can see, there
> is no desire in the XMPP community to ignore IDNA2008. We want to move
> forward to a post-stringprep world. The big question is how to make that
> happen, not "if".
> 
> 5. Setting a Precedent
> 
> The IETF community put a lot of work into IDNA2008. If one of the big
> customers of IDNA technology were to ignore IDNA2008, that would set a
> bad precedent and encourage other customers to ignore it, too. But it's
> clear to me that the XMPP community doesn't want to ignore IDNA2008.
> Instead, it simply wants to migrate all of its i18n technologies
> simultaneously, with a full understanding of the implications, and in a
> way that makes sure we get it right this time. There's no precedent
> being set here, because the XMPP community is unique among stringprep
> customers.
> 
> 6. The Address Spec
> 
> If we need to add more text to draft-ietf-xmpp-address explaining the
> situation I've summarized in this email, I would be happy to do that.
> However, given the vast improvement in quality between RFCs 3920/3921
> and 3920bis/3921bis, I would not be happy to have the address spec stuck
> in limbo, thus preventing publication of revised specs for the core
> until 2012 or 2013.
> 
> 7. Making the Transition
> 
> As mentioned, the big question is how to make a successful transition to
> a post-stringprep world. Some members of the XMPP community are actively
> contributing to the PRECIS WG. I'm working on a tutorial for presenting
> at the XMPP Summit in February so that more XMPP developers can
> strengthen their understanding of i18n issues. We need to continue
> discussions in the XMPP WG about the topics that have emerged in recent
> mailing list threads. I encourage the group, and the chairs, to make it
> a priority for us to solve these problems in 2011 -- and I will commit
> to putting significant energy into these efforts.
> 
> In short, we have a lot of work to do, so let's get busy. :)
> 
> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> 
> _______________________________________________
> xmpp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xmpp