I agree, and I think there is rough consensus to that effect.<br><br>My biggest concern as far as a transitional appendix is not the Hearts and others, but the cases where IDNA2003 and IDNA2008 produce *divergent* completely valid A-Labels. For that, I think we must have a very good story because of security and interoperability issues.<br>
<br>If we have M-Labels (whether full NFKC-CF-RDI or some subset), then it looks like the sigma and eszett would go away, so that leaves us with only two cases; ZWJ and ZWNJ. In that case the recommended transitional strategy can devolve to:<br>
<ul><li>Lookup with IDNA2008. If it fails, remove any ZWJ/NJ, and try again.</li></ul>Mark<br>
<br><br><div class="gmail_quote">On Thu, Apr 2, 2009 at 10:44, Harald Alvestrand <span dir="ltr"><<a href="mailto:harald@alvestrand.no">harald@alvestrand.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I agree with Paul's points below. Let's bite the bullet and say "they<br>
are invalid under IDNA2008".<br>
<div><div></div><div class="h5"><br>
Paul Hoffman wrote:<br>
> At 12:14 PM -0400 3/31/09, Vint Cerf wrote:<br>
><br>
>> Does the working group agree that the more restricted set of the<br>
>> current IDNA2008 Tables document should apply once IDNA2008 is<br>
>> adopted?<br>
>><br>
><br>
> Yes.<br>
><br>
><br>
>> What should be done about registrations that use characters<br>
>> that would not be allowed under IDNA2008?<br>
>><br>
><br>
> Nothing. They will naturally wither as IDNA2008 is adopted by software, in the same way that older protocols wither and better ones are deployed.<br>
><br>
><br>
>> Should there be a<br>
>> transitional period of finite duration after which these registrations<br>
>> will become invalid?<br>
>><br>
><br>
> No. They will *always* be valid under the old protocol, and they will *never* be valid under the new protocol. There is no reason to blur this distinction.<br>
><br>
><br>
>> Should they be grandfathered somehow?<br>
>><br>
><br>
> No.<br>
><br>
><br>
>> If we<br>
>> believe all future registrations should be restricted, how would such<br>
>> grandfathered registrations be found if the IDNA2008 rules would<br>
>> reject lookups of the disallowed characters?<br>
>><br>
><br>
> They would be found if we promoted confusion, so let's not.<br>
><br>
><br>
>> A two-lookup scheme might solve this problem:<br>
>><br>
>> 1. lookup according to IDNA2008 rules (if disallowed characters are<br>
>> present, go to step 2); if domain name record is found, return the<br>
>> information. If not, go to step 2<br>
>> 2. lookup according to IDNA2003 rules (permitting a broader range of<br>
>> characters in the lookup process). If domain record is found, return<br>
>> it, if not return "no such domain name"<br>
>><br>
><br>
> Of course. And, as others have pointed out, this scheme creates more problems.<br>
> _______________________________________________<br>
> Idna-update mailing list<br>
> <a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
> <a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
><br>
><br>
<br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br>