Implementation questions (digressing from...)

[Vint Cerf]

If we were to recommend choice (4), which seems to capture the spirit  
of IDNA2008 most closely, could the previous behavior be captured by  
zone operators through the use of CNAME entries that explicitly  
bundle "ss" and "esszet" for those instances where it was the case  
under IDNA2003 that "esszet" was mapped into "ss" at registration and  
lookup time?

Plainly this requires notice to or at least notice by "registrants"  
that the introduction of "esszet" without automatic mapping  
"requires" them to bundle both if it is desired to maintain the  
behavior that had been induced by mapping under IDNA2003.



Vint Cerf
Google
1818 Library Street, Suite 400
Reston, VA 20190
202-370-5637
vint at google.com




On Dec 24, 2008, at 10:24 AM, Erik van der Poel wrote:

> On Tue, Dec 23, 2008 at 6:19 PM, Shawn Steele
> <Shawn.Steele at microsoft.com> wrote:
>> I think that if the A-Label is in the HTML, then the browser would  
>> need
>> to be able to round-trip it through Unicode.
>
> That does seem like a nice-to-have. But is it a must-have?
>
>> Additionally, it seems that
>> if an HTML author could make it look like ß, then it would be likely
>> that a user would enter a ß, so I don't think that'd help much.
>
> I agree that the UI problem is still there. This is where I
> distinguish between local and global pre-processing. If a user is
> typing a domain name character by character, the implementation can
> ask the user whether they intend to go to the eszett site or the ss
> site. If a user is providing the domain name in one fell swoop (e.g.
> clicking on a link, copying and pasting into the address bar), then
> there is no way to know the intention of the author of that domain
> name, so the implementation should apply the global pre-processing
> rules (and under my proposal, eszett would be mapped to ss).
>
> Some might consider this solution to be worse than the problem it is
> solving (two DNS lookups for a single domain name in HTML hrefs).
>
> But let me step back for a moment and outline some alternatives,
> starting with "strict" and gradually getting more "lenient":
>
> (1) HTML hrefs must use A-labels and LDH-labels. One advantage is that
> this works in MSIE6, which may be hard to upgrade. One disadvantage is
> that this does not work with MSIE7, unless it is upgraded, which might
> be easier.
>
> (2) In HTML hrefs, eszett is always mapped to ss and the only way to
> include eszett is via IDNA2008 A-labels. One advantage is that we
> don't need to do two DNS lookups. One disadvantage is that eszett
> cannot be typed directly into HTML hrefs.
>
> (3) In HTML hrefs, eszett can be typed directly, and the browser tries
> both IDNA2003 (ss) and IDNA2008 (A-label). One advantage is that
> eszett can be typed directly. One disadvantage is that two DNS lookups
> are required.
>
> For completeness, I should add the following, because the current
> IDNA2008 Protocol draft says "It is important to note that the intent
> of these specifications is that labels in application protocols,
> files, or links are intended to be in U-label or A-label form." Note
> that this one is not more lenient than the previous one, breaking the
> above pattern of "strict" to "lenient".
>
> (4) In HTML hrefs, only U-labels and A-labels are accepted, and
> U-labels containing eszett are converted to the corresponding A-labels
> before DNS lookup. One advantage of this approach is that it is
> conceptually clean and simple. One disadvantage is that it disregards
> migration issues for IDNA2003 pre-processors.
>
> Erik
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081224/d5a80250/attachment.htm