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

[Alexey Melnikov <[e-mail]>]

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" <[e-mail]> 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 <[e-mail]>
>>To: Alexey Melnikov <[e-mail]>
>>CC: [e-mail], [e-mail],
>>The IESG <[e-mail]>
>>
>>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.
>>
>>#######################################################################
>>    
>>