No subject

operators at all levels of the DNS (not just TLDs) will bundle (or
block) for eszett/ss.

Erik

On Wed, Dec 24, 2008 at 7:42 AM, Vint Cerf <vint at google.com> wrote:
> 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" an=
d
> "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 bun=
dle
> 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 =DF, then it would be likely
> that a user would enter a =DF, 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
>