Subject: [xmpp] IDNA2003 versa IDNA2008 (was Re: stringprep: full, partial, none)

From: Alexey Melnikov <[email-masked]>
Date: Sun, 05 Dec 2010 18:29:42 +0000

Hi Joe,
I've deferred IESG discussions of xmpp-address document for 2 weeks in 
order to have a bit more time to discuss this issue.

Joe Hildebrand wrote:

>As an individual, not chair:
>
>The domainpart is often user-entered in our world, and has always been
>written down on business cards and the like with the expectation that it
>would be case-folded before comparison or DNS lookup.  Switching to the
>dangerously incomplete IDNA2008, which does not specify any canonicalization
>is not an option for us, in my opinion.
>
What about RFC 5895?

>We would also have to specify
>something nameprep-like, and I'd much rather wait on the output of the
>Précis working group.
>  
>
Unfortunately the Précis working group is not currently planning to work 
on a nameprep replacement, not because there is strong opposition to the 
work, but because nobody has asked for it. If RFC 5895 is not sufficient 
and the Précis Working Group agrees to take on this work, then I would 
be Ok with letting XMPP-address just reference IDNA2003 for now.

>I also don't want to hold up 3920bis and 3921bis waiting for that uncertain
>future.  If the IESG didn't want us to keep using nameprep, they should have
>forced the IDNA2008 team to complete their work, coming up with a
>replacement.
>
Unfortunately IESG is not all powerful: it can't force consensus where 
there is none. And claiming consensus where there is none is against the 
spirit of IETF. IDNABIS WG just couldn't agree on details of a single 
mapping.

>In the meantime, I think sticking with nodeprep/nameprep/resourceprep for
>the short term is the best of what are all bad options.
>  
>
Here is my dilemma as an Apps AD: as an AD I think I should be enforcing 
consistent policies regarding IDNA. There are currently 3 different 
unrelated documents in IESG review which originally predate IDNA2008. 
Two of them just points to IDNA2003 and ignores IDNA2008, another one 
says that IDNA2008 is a SHOULD implement, with Unicode TR46 or RFC 5895 
being MAY implement, and IDNA2003 is MUST implement if IDNA2008 is not 
implemented. While the last one might not be perfect, I think it is 
doing a better job at trying to encourage people to migrate to IDNA2008.

My biggest concern so far is allowing XMPP to just keep using IDNA2003 
and create a precedent that other protocols will use.

Regards,
Alexey

>On 11/22/10 12:27 PM, "Peter Saint-Andre" <[email-masked]> wrote:  
>
>>Here is the main issue that concerns the XMPP WG.
>>
>>IIRC the group did not consider "partial stringprep" (switch to IDNA2008
>>but keep using nodeprep and resourceprep), only "full stringprep" (keep
>>using IDNA2003 along with nodeprep and resourceprep) and "no stringprep"
>>(wait until the PRECIS WG finishes its work, then switch to IDNA2008 and
>>whatever replaces nodeprep and resourceprep).
>>
>>/psa
>>
>>#######################################################################
>>
>>-------- Original Message --------
>>Subject: Re: Alexey Melnikov's DISCUSS and COMMENT on
>>draft-ietf-xmpp-address-07
>>Date: Mon, 22 Nov 2010 09:25:30 -0700
>>From: Peter Saint-Andre <[email-masked]>
>>To: Alexey Melnikov <[email-masked]>
>>CC: [email-masked], [email-masked],
>>The IESG <[email-masked]>
>>
>>On 11/22/10 8:39 AM, Alexey Melnikov wrote:
>>    
>>
>>>Hi Peter,
>>>
>>>Peter Saint-Andre wrote:
>>>
>>>      
>>>
>>>>On 11/19/10 5:20 AM, Alexey Melnikov wrote:
>>>> 
>>>>
>>>>        
>>>>
>>>[...]
>>>      
>>>
>>>>>4). DISCUSS DISCUSS: Should domainpart be migrated to IDNA2008 now?
>>>>>Apps Area is pretty much requiring use of IDNA2008 in all documents.
>>>>>  
>>>>>          
>>>>>
>>>>This spec documents the legacy usage as a placeholder while the XMPP
>>>>community contributes to the PRECIS WG in its work on a replacement for
>>>>stringprep. I think the XMPP WG agreed that it would move away from
>>>>stringprep for all parts of a JID at the same time -- not temporarily
>>>>replace IDNA2003 with IDNA2008 for the domainpart but keep using
>>>>stringprep for the localpart and resourcepart pending the output of the
>>>>PRECIS WG, and then switch the localpart and resourcepart over to a
>>>>non-stringprep approach once the PRECIS WG is done.
>>>> 
>>>>
>>>>        
>>>>
>>>Firstly, I think a statement on this should be made in the document.
>>>      
>>>
>>We tried to say that in the introduction.
>>
>>    
>>
>>>Secondly, there is no "temporary replace IDNA2003 with IDNA2008" ;-).
>>>IDNA2003 is gone.
>>>      
>>>
>>By temporary I meant:
>>
>>1. do IDNA2008 + nodeprep + resourceprep for a while (part-stringprep)
>>
>>2. then do IDNA2008 + precis-based solutions for nodeprep and
>>resourceprep (no-stringprep)
>>
>>vs.
>>
>>1a. do IDNA2003 + nodeprep + resourceprep for a while more (full
>>stringprep), until we can do #2
>>
>>    
>>
>>>If IDNA2008 has issues, than it needs to be fixed.
>>>      
>>>
>>I see no issues with IDNA2008.
>>    
>>
>>>I am also concerned about the possibility of Precis WG failing to
>>>deliver a Stringprep-bis, or doing it very slowly.      
>>>
>>One solution is to push forward as fast as possible with PRECIS. :)
>>    
>>
>>>I suspect soon
>>>registries will start allowing registrations of domains with Unicode
>>>characters that map differently under IDNA2008 and IDNA2003 and that
>>>would cause an interop issue.
>>>      
>>>
>>Yes, that is a concern.
>>
>>I think we want to move to IDNA2008 with all due speed. The alternatives
>>listed above (1=>2 vs. 1a=>2) were not explicitly presented to the XMPP
>>WG, so that would need to happen. If I recall correctly, most people
>>seemed to be thinking that the alternatives were all-stringprep or
>>no-stringprep, not part-stringrep for a while and then no-stringprep.
>>
>>#######################################################################
>>    
>>

---

From: Joe Hildebrand <[email-masked]>
Date: Mon, 13 Dec 2010 14:34:53 -0700

>From Section 3:

"""If you are implementing a mapping for an application or operating
   system by using exactly the four steps in Section 2, the authors of
   this document have a request: please don't.  We mean it."""

:)

Seriously, I don't think there's enough there for us to use as a reference.

> be Ok with letting XMPP-address just reference IDNA2003 for now.

Let's take that up with Précis.  I believe we'll have support for taking on
this work, assuming we can come up with an approach that works for other
protocol elements.

> spirit of IETF. IDNABIS WG just couldn't agree on details of a single

Understood.  Nevertheless, it was frustrating that functionality was
deprecated without a replacement.

> doing a better job at trying to encourage people to migrate to IDNA2008.

My suggestion would be for each of these documents to split out their piece
of work into a separate draft along the lines of draft-ietf-xmpp-address,
and get a strong commitment from each to a) help push Précis along faster
and b) obsolete the address spec as soon as the output of Précis is
available.

As stated above, RFC 5895 is not terribly helpful, and I'd be surprised
there was a place where it could be used in a protocol.

> and create a precedent that other protocols will use.

If that precedent is to collaborate together with others who care about the
issues, with the absolute intent to get to the long-term correct solution as
soon as possible, I'm not sure why you would have a problem with setting it.

The larger issue is domains that are invalid in IDNA2003 and valid in
IDNA2008 or vice-versa.  I would be totally fine with adding language that
warns folks who are deploying against choosing any of those domain names
until we're done with the Précis work.

-- 
Joe Hildebrand

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 15 Dec 2010 09:04:26 +0000

To the WG:
Does anybody else care and/or understand the issue? I would like to hear 
somebody other than Joe commenting on this.

Hi Joe,

>   this document have a request: please don't.  We mean it."""
Well yes. I can can chat some day why the text is there. But it 
shouldn't stop people from using the document.

>Seriously, I don't think there's enough there for us to use as a reference.
Can you be more specific? I think the algorithm described is sufficient 
for the nameprep replacement - it talks about input canonicalization.

Regards,
Alexey

---

From: Matthew Wild <[email-masked]>
Date: Wed, 15 Dec 2010 13:10:31 +0000

> somebody other than Joe commenting on this.

I'm far from expert on internationalization, so would appreciate if
someone can give a summary of the issue here (in particular why we
should/shouldn't switch to IDNA2008).

In as much as I do know however, I see two reasons /against/
switching. One is that as far as I know 2003/2008 have different
definitions of what constitutes a valid domain (please correct me if
I'm wrong) and this could cause interop issues on the network.
Granted, they may be relatively few, but there /are/ unicode domains
out there.

Secondly, I don't think either libidn or libicu support IDNA2008, and
most XMPP implementations use one of these libraries. How soon each
could reasonably gain support I have no idea, but it would mean no
implementation I know of could comply with 3920bis in the meantime.
For a document that as far as I know is aiming to mostly document the
state of XMPP as it has advanced since 3920 and to improve problems
we've found from our experience, that's quite a feat.

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Dec 2010 06:28:10 -0700

On 12/15/10 6:10 AM, Matthew Wild wrote:
> I'm far from expert on internationalization, 

At the next XMPP Summit, I plan to present a tutorial I'm working on,
entitled: "Internationalization: A Guide for the Perplexed." Not that
I'm an expert, either, but sometimes the best way to learn is by teaching.

> so would appreciate if

We should switch to IDNA2008. It's just a question of when.

The main reason to switch is that IDNA2003 is hardcoded to use Unicode
3.2, whereas IDNA2008 is agile with regard to versions of Unicode (the
latest version is 6.0).

IIRC, folks in the WG thought that it would be good to make the switch
to the non-stringprep approach of IDNA2008 once we could also make the
switch to a non-stringprep approach for localparts and resourceparts, too.

> Granted, they may be relatively few, but there /are/ unicode domains

No matter what we do, there will be interop / migration issues. One
approach might be to document the issues with remaining at IDNA2003, as
well as with migrating now.

> we've found from our experience, that's quite a feat.

That's another consideration, yes.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Dec 2010 11:03:32 -0700

> for the nameprep replacement - it talks about input canonicalization.

But is the suggested algorithm enough? For example, RFC 5895 says:

   1.  Uppercase characters are mapped to their lowercase equivalents by
       using the algorithm for mapping case in Unicode characters.  This
       step was chosen because the output will behave more like ASCII
       host names behave.

Yet mapping uppercase characters to their lowercase equivalents doesn't
always yield the same results in all locales. One famous example is
Turkish dotless "i"...

In English and other European languages, the following is true of the
lowercasing operation, with the Unicode codepoints in square brackets:

   I [U+0049] => i [U+0069]

In Turkish and some other Turkic languages (e.g., Azerbaijani), the
operation yields:

   I [U+0049] => ı [U+0131]

And these differences can have significant consequences:

http://gizmodo.com/382026/a-cellphones-missing-dot-kills-two-people-puts-three-more-in-jail

There might also be issues with German esszett [U+00DF] and Greek final
sigma [U+03C2], neither of which have uppercase equivalents. As you
recall, those characters loomed large in the IDNABIS discussions.

It seems to me that, at the least, any universal recommendation would
need to specify a preparatory step that takes locale (and perhaps other
context) into account before applying the lowercasing operation. (What
that means on an XMPP server, which doesn't necessarily have such
context, is just one of the messy issues here. Would we need to push the
locale-specific portions of the algorithm, or indeed enforcement of the
entire algorithm, onto XMPP clients?)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 15 Dec 2010 21:20:53 +0000

Hi Peter,
Speaking as an individual in the message (and not as an AD):

>always yield the same results in all locales. One famous example is
But IDNA2003 didn't do "the right thing for Turkish dotless 'i'" anyway, 
so I don't see a reason why IDNA2008+RFC 5895 need to change that.

>recall, those characters loomed large in the IDNABIS discussions.
Does RFC 5895 do a sensible thing for these characters? I think it does, 
as they will not be mapped to anything else, which was the agreed result 
for IDNA2008.

>entire algorithm, onto XMPP clients?)
No, this way lies madness ;-).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 15 Dec 2010 21:28:38 +0000

Hi Matthew,

Matthew Wild wrote:

>I'm wrong)
This is correct.

>and this could cause interop issues on the network.
I think the issue is that some IDNA2008 domains are not valid under 
IDNA2003 and some of them are represented differently under IDNA2003 
(due to differing mapping). So I think not using IDNA2008 is going to be 
good for interoperability.

>we've found from our experience, that's quite a feat.
While I have some sympathy to this argument as a developer, as an AD I 
don't think this is a good reason not to upgrade.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Dec 2010 14:53:25 -0700

> so I don't see a reason why IDNA2008+RFC 5895 need to change that.

Because people might die otherwise? :)

> as they will not be mapped to anything else, which was the agreed result

True.

> No, this way lies madness ;-).

So our choices are madness or death. That pretty much wraps up
internationalization in a nutshell, I'd say. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 15 Dec 2010 15:56:36 -0700

>> definitions of what constitutes a valid domain (please correct me if

I think it's important to understand how widely they differ.

1. Allowable characters. In IDNA2008, domain names are now allowed to
contain the following <http://tools.ietf.org/html/rfc5894#section-7.2>:

   German esszett [U+00DF]
   Greek final sigma [U+03C2]
   Zero width joiner [U+200D]
   Zero width non-joiner [U+200C]

Those were disallowed under IDNA2003. So names like επικουρος.gr are
allowed now. Older IDNA2003-compliant software won't be able to resolve
those new domains.

2. Normalization. IDNA2003 used NFKC, IDNA2008 uses NFC. I happen to
think that NFC is superior, but there are transition issues. So names
like ﬁnland.fi would have decomposed to finland.fi under IDNA2003,
whereas now the first character would remain as ﬁ [U+FB01]. Right?

>> Granted, they may be relatively few, but there /are/ unicode domains

I think we've seen very few of those on the XMPP network.

> don't think this is a good reason not to upgrade.

Is it just a question of scrapping libidn/libicu and instead using
whatever version of Unicode is on the system (via some kind of "toLower"
function)? Of course, that might result in different results on
different systems if they have different versions of Unicode on board...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2010 14:52:57 +0000

[...]

>Is it just a question of scrapping libidn/libicu
>
Not necessarily. Another alternative would be to update such libraries 
to support IDNA2008.

>and instead using
I think this is an issue that people have to live with. IDNA2008 makes 
IDNA mostly independent of the version of Unicode used, but this pretty 
much implies that different systems are going to use different version 
of Unicode.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2010 15:01:16 +0000

>allowed now. Older IDNA2003-compliant software won't be able to resolve
Correct.

>whereas now the first character would remain as ﬁ [U+FB01]. Right?
According to <http://tools.ietf.org/html/rfc5894#section-3.1.3> it looks 
like a character like [U+FB01] is disallowed:

   There is provision for exception cases but, in general, characters
   are placed into DISALLOWED if they fall into one or more of the
   following groups:

   o  The character is a compatibility equivalent for another character.
      In slightly more precise Unicode terms, application of
      Normalization Form KC (NFKC) to the character yields some other
      character.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Dec 2010 08:12:20 -0700

>      Normalization Form KC (NFKC) to the character yields some other

That's very interesting. Although IDNA2008 uses NFC, via this rule it
sort of sneaks NFKC in through the back door. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Dec 2010 08:13:44 -0700

> much implies that different systems are going to use different version

Yes. It's not that IDNA2008 promises (or can promise) that things won't
break, it just moves around the source of the breakage. I don't say that
to be critical, either -- it's just the reality of the situation.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Dec 2010 08:16:10 -0700

> No, this way lies madness ;-).

Having thought about this some more, I conclude that this way lies
software that adheres to the principle of least user surprise. However,
that's hard to achieve (and not necessarily a matter for the XMPP WG,
the PRECIS WG, or various IDNA technologies).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Dec 2010 16:50:17 +0000

Peter Saint-Andre wrote:

>software that adheres to the principle of least user surprise.
>
I think this would only work for XMPP clients where user preferences are 
know.

On the server side, either the server would need to know user 
preferences for each user it is dealing with (which increases user 
management complexity), or the server needs to implement some generic 
algorithm (like RFC 5895). The latter might surprise some users, but 
there is no way around that. I don't even want to think about how to 
implement the former.

>However, that's hard to achieve (and not necessarily a matter for the XMPP WG,
Right.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Dec 2010 12:02:29 -0700

>> On 12/15/10 2:20 PM, Alexey Melnikov wrote:

<snip/>

> there is no way around that. I don't even want to think about how to

That is correct. And it leads me to conclude that, in order for us to do
this right, we need to mandate that the client MUST enforce the rules
whenever placing a JID into a "JID slot" (cf. the concept of a "domain
name slot" in the IDNA2008 specs). I see such slots in at least the
following places within the XMPP protocol stack:

1. stream 'to' and 'from' attributes

2. SASL simple user names (3920bis -- although perhaps SASLprep-bis
supersedes XMPP technologies here??)

3. stanza 'to' and 'from' attributes (3920bis)

4. roster 'jid' attribute (3921bis)

5. privacy list 'value' attribute when type is "jid" (XEP-0016)

6. vCard <JABBERID/> element (XEP-0054)

7. Multi-User Chat administration via 'jid' attribute (XEP-0045)

8. Publish-Subscribe permissions via 'jid' attribute (XEP-0060)

9. Jingle session management, e.g. the 'initiator' attribute (XEP-0166)

... and there are many others (data forms, file transfer, you name it).

The server can't enforce all of those usages, so the client needs to do so.

And *that* is a huge change in the i18n model for XMPP!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Tory Patnoe" <[email-masked]>
Date: Mon, 20 Dec 2010 11:31:29 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peter Saint-Andre
> Sent: Monday, December 20, 2010 12:02
> To: Alexey Melnikov
> Cc: Joe Hildebrand; XMPP
> Subject: Re: [xmpp] IDNA2003 versa IDNA2008 (was Re: stringprep: full,
> partial, none)
> 
> 

And at all these same places clients already have to run through XEP-106 JID Escaping.  There is some precedence for this.

--  Tory <to\[email-masked]>

---

From: Remko Tronçon <[email-masked]>
Date: Mon, 20 Dec 2010 20:37:21 +0100

> And at all these same places clients already have to run through XEP-106 JID Escaping.  There is some precedence for this.

Well, not sure whether this is really true. Most (all?) clients simply
reject JIDs with the characters from XEP-106, since they're invalid.
AFAIK, only transports use JID escaping, because it allows mapping
from legacy usernames to JID nodes in an automated way.

cheers,
Remko

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Dec 2010 12:39:18 -0700

> And at all these same places clients already have to run through XEP-106 JID Escaping.  There is some precedence for this.

For those three clients that support JID Escaping, yes. ;-)

(Well, I'm not aware of how many clients support it, but I don't think
the list is long.)

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 20 Dec 2010 12:50:37 -0700

> from legacy usernames to JID nodes in an automated way.

Some XMPP systems pull their authentication credentials from the same
backend database that was previously set up for email addresses, so your
JID is the same as your email address (this is one reason why the
XEP-0106 examples are things like [email-masked]). Such
deployment aren't necessarily common, but they tend to be big.

But this is off-topic, I suppose. :)

---

From: Ben Campbell <[email-masked]>
Date: Wed, 22 Dec 2010 17:36:01 -0600

Sorry for jumping backwards in the thread, but I wanted to re-mention a point that I suspect Peter and Alexey have already discussed, but just in case:

If I understood the situation correctly (and I was just joining as a new co-chair at the time so it's entirely possible I don't), On or around Anaheim XMPP realized that it was close to done with most of the major issues in 3920bis, but that the IDNA2008 migration was likely to take some time to get right. We split out the address draft with the idea that we would put the i18n issues off for the moment, and get the rest of 3920bis done, then come back with an update of xmpp-address when we felt the time was right.

So the very existence of draft-ietf-xmpp-address was intended as a compromise on this particular problem. The idea was that we could update xmpp-address _soon_ without having to reopen 3920bis. (or 3920ter).

It seems to me that we are still in that situation. It's pretty clear from the discussion so far (and from Peter's summary of the issues that he sent yesterday)  that moving to IDNA2008 will take some significant work to get right, particularly with the migration issues around the other stringprep usages in XMPP.

Alexey, Peter, and Joe:  is there any way forward that would allow delaying of the i18n problem until after publication of 3920bis? Would it help if XMPP chartered a milestone for IDNA2008 migration and the resulting updates to xmpp-address?

Thanks!

Ben.

On Dec 15, 2010, at 3:04 AM, Alexey Melnikov wrote:

> To the WG:
> Does anybody else care and/or understand the issue? I would like to hear somebody other than Joe commenting on this.
> 
> Hi Joe,
> 
> Joe Hildebrand wrote:
> 
> Well yes. I can can chat some day why the text is there. But it shouldn't stop people from using the document.
> 
> Can you be more specific? I think the algorithm described is sufficient for the nameprep replacement - it talks about input canonicalization.
> 
> Regards,
> Alexey
> 
> 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Dec 2010 07:57:18 -0800

> name slot" in the IDNA2008 specs).

[BA] In general, no such changes should be required to handle the
domainslot.  I don't even think it's necessarily a good idea for the
localpart either, because a client may not necessarily know the
level of internationalization support on the server, nor does it necessarily
need to, other than handling error conditions as it does today (e.g.
NXDOMAIN).

> The server can't enforce all of those usages, so the client needs to do
so.

[BA] Within IDNA 2008  "enforcement" is handled on the domain name
registrar.
This shields the client from having to enforce rules that it may not even
know
about.  So it's not clear to me that either an XMPP client or server
need necessary be responsible for enforcement; this is more of an
administrator
responsibility.

For example, if a server formerly had a user account corresponding to a
localpart,
that account will continue to exist after upgrading from IDNA 2003 to 2008.
Similarly, an upgrade won't by itself change the server FQDN.  Therefore a
client
that decides to "enforce" a change that hasn't taken place on the server
will only
be creating problems for itself.  If and when the server decides to make
changes
(e.g. changing the server FQDN or deleting a user account), the client will
find
out soon enough, through error conditions that already exist.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 23 Dec 2010 16:45:35 +0000

Hi Ben,

>If I understood the situation correctly (and I was just joining as a new co-chair at the time so it's entirely possible I don't), On or around Anaheim XMPP realized that it was close to done with mo…
I frankly don't remember discussing IDNA2008, but I certainly remember 
discussing Stringprep replacement.

Right.

>It seems to me that we are still in that situation. It's pretty clear from the discussion so far (and from Peter's summary of the issues that he sent yesterday)  that moving to IDNA2008 will take so…
Yes.
I am agreeable for letting this WG (or Precis) do more deliberations 
about migration to IDNA2008 without holding up XMPPbis. I just want to 
make sure that that work happens somewhere.

>Alexey, Peter, and Joe:  is there any way forward that would allow delaying of the i18n problem until after publication of 3920bis? Would it help if XMPP chartered a milestone for IDNA2008 migration…
I would certainly like that, but I trust people will work on this 
problem even without rechartering.

---

From: Joe Hildebrand <[email-masked]>
Date: Thu, 23 Dec 2010 10:26:30 -0700

On 12/23/10 9:45 AM, "Alexey Melnikov" <[email-masked]> wrote:

>> Alexey, Peter, and Joe:  is there any way forward that would allow delaying
>> of the i18n problem until after publication of 3920bis? Would it help if XMPP
>> chartered a milestone for IDNA2008 migration and the resulting updates to
>> xmpp-address?
>> 

Ben, that's a fine idea, and a good way to capture our intent.

-- 
Joe Hildebrand

---

From: Sean Turner <[email-masked]>
Date: Thu, 23 Dec 2010 12:58:32 -0500

On 12/13/10 4:34 PM, Joe Hildebrand wrote:
snip
> there was a place where it could be used in a protocol.

I like this way forward...

spt

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 23 Dec 2010 13:05:45 -0800

While I certainly understand the reticence to hold up the addressing
document for completion of PRECIS, with respect to handling of the
domainpart in way that would be compatible with IDNA 2008, there is actually
very little that would need to be changed in draft-ietf-xmpp-address.  For
example, I believe that with the deletion of two sentences in Section 2.2,
the document can be compatible with both IDNA 2003 and IDNA 2008 with
respect to handling of the domainpart.  Details below:

===========================================================

2.2. Domainpart

   The domainpart of a JID is that portion after the '@' character (if
   any) and before the '/' character (if any); it is the primary
   identifier and is the only REQUIRED element of a JID (a mere
   domainpart is a valid JID).  Typically a domainpart identifies the
   "home" server to which clients connect for XML routing and data
   management functionality.  However, it is not necessary for an XMPP
   domainpart to identify an entity that provides core XMPP server
   functionality (e.g., a domainpart can identify an entity such as a
   multi-user chat service, a publish-subscribe service, or a user
   directory).

   The domainpart for every XMPP service MUST be a fully qualified
   domain name ("FQDN"; see [DNS]), IPv4 address, IPv6 address, or
   unqualifed hostname (i.e., a text label that is resolvable on a local
   network).

      Interoperability Note: Domainparts that are IP addresses might not
      be accepted by other services for the sake of server-to-server
      communication, and domainparts that are unqualified hostnames
      cannot be used on public networks because they are resolvable only
      on a local network.

   If the domainpart includes a final character considered to be a label
   separator (dot) by [IDNA2003] or [DNS], this character MUST be
   stripped from the domainpart before the JID of which it is a part is
   used for the purpose of routing an XML stanza, comparing against
   another JID, or constructing an [XMPP-URI]; in particular, the
   character MUST be stripped before any other canonicalization steps
   are taken, such as application of the [NAMEPREP] profile of
   [STRINGPREP] or completion of the ToASCII operation as described in
   [IDNA2003].

[BA] Since Nameprep doesn't exist in IDNA 2008, why not change this to:

   MUST be stripped before any other canonicalization steps
   are taken, such as completion of the ToASCII operation as described in
   [IDNA2003].

   A domainpart consisting of a fully qualified domain name MUST be an
   "internationalized domain name" as defined in [IDNA2003], that is, it
   MUST be "a domain name in which every label is an internationalized
   label" and MUST follow the rules for construction of
   internationalized domain names specified in [IDNA2003].  When
   preparing a text label (consisting of a sequence of UTF-8 encoded
   Unicode code points) for representation as an internationalized label
   in the process of constructing an XMPP domainpart or comparing two
   XMPP domainparts, an application MUST ensure that for each text label
   it is possible to apply without failing the ToASCII operation
   specified in [IDNA2003] with the UseSTD3ASCIIRules flag set (thus
   forbidding ASCII code points other than letters, digits, and
   hyphens).  If the ToASCII operation can be applied without failing,
   then the label is an internationalized label.  (Note: The ToASCII
   operation includes application of the [NAMEPREP] profile of
   [STRINGPREP] and encoding using the algorithm specified in
   [PUNYCODE]; for details, see [IDNA2003].)

[BA] Under IDNA 2008, the ToASCII operation still exists, but I don't
believe that the characterization above is still valid, so I'd delete
the parenthetical.

   Although XMPP applications
   do not communicate the output of the ToASCII operation (called an
   "ACE label") over the wire, it MUST be possible to apply that
   operation without failing to each internationalized label.  If an
   XMPP application receives as input an ACE label, it SHOULD convert
   that ACE label to an internationalized label using the ToUnicode
   operation (see [IDNA2003]) before including the label in an XMPP
   domainpart that will be communicated over the wire on an XMPP network
   (however, instead of converting the label, there are legitimate
   reasons why an application might instead refuse the input altogether
   and return an error to the entity that provided the offending data).

   A domainpart MUST NOT be zero bytes in length and MUST NOT be more
   than 1023 bytes in length.  This rule is to be enforced after any
   mapping or normalization resulting from application of the Nameprep
   profile of stringprep (e.g., in Nameprep some characters can be
   mapped to nothing, which might result in a string of zero length).
   Naturally, the length limits of [DNS] apply, and nothing in this
   document is to be interpreted as overriding those more fundamental
   limits.

   In the terms of IDNA2008 [IDNA-DEFS], the domainpart of a JID is a
   "domain name slot".