Re: [xmpp] i18n summary

[Bernard Aboba <[e-mail]>]

On Thu, Dec 23, 2010 at 6:52 AM, Bernard Aboba <[e-mail]>wrote:

>
>
> On Tue, Dec 21, 2010 at 7:55 AM, Peter Saint-Andre <[e-mail]>wrote:
>
>>
>> 2. Migration
>>
>>
>> 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.
>>
>
>
> [BA] From what I can tell, on a number of platforms "upgrading" from IDNA
> 2003
> to 2008 will occur by upgrading libraries.  Therefore, at least with
> respect to the
> domainpart, a client calling upgraded libraries will not necessarily know
> the
> difference.
>
>
>> 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).
>
>
> [BA] While some of the wording has changed, I don't believe that this
> requires
> a change in client application architecture (at least with respect to
> handling of the
> domainpart).  As noted above, on some platforms it probably will not
> require changes
> in client code.
>
> On the server side, substantial changes are required within "domain name
> registrars"
> (e.g. DNS servers and in some architectures closely allied components such
> as LDAP
> servers).  However, it's not clear to me that XMPP servers need necessarily
> worry about
> those changes, in terms of their handling of the domainpart.
>
>
>> 4. Desire for Change
>>
>> Alexey seemed to be questioning whether the XMPP community wants to
>> upgrade from IDNA2003 to IDNA2008... there is no desire to ignore IDNA
>> 2008.
>
>
> [BA] To the extent that the upgrade from IDNA 2003 to IDNA 2008 occurs via
> library upgrades that don't affect applications, the domainpart upgrade
> could
> turn out to be relatively painless.  So ignoring the IDNA 2003/2008
> transition
> (for domainparts) could turn out to be quite a viable transition strategy.
>
>
>
>> 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)
>
>
>
> [BA] Overall, there is a high degree of variance in the quality of i18n
> implementations
> within applications.  This is because correct handling of i18n is quite
> difficult at present.
>
> 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.
>
>
> [BA] As noted earlier, ignorance on the part of application developers
> isn't necessarily
> a bad strategy for the domainpart, assuming that platform and library
> developers do
> their job to make the migration as painless as possible.  Time will tell if
> such a strategy
> is feasible for localparts. However, at least at the developer level, I
> think we've learned
> that any migration strategy which requires large scale changes within
> applications will
> face resistance.
>
>
>> 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.
>>
>
> [BA] Yes, that would be unfortunate.
>
>
>>
>> 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.
>>
>
> [BA] Judging by the variance in i18n implementations within XMPP clients,
> that
> could be quite helpful.
>