looking up domain names with unassigned code points
james at seng.sg
Mon May 12 06:17:33 CEST 2008
What Patrik proposed makes a lot of sense, that some form of
round-trip stability check should be perform.
I am in the "New compromise camp:" to be exact.
Client is permitted to look up any label that is already in Punycode,
even if it has an unassigned code point encoded inside it, but the
client SHOULD update itself or warn the user when an unassigned code
point is encountered in a label that is not already in Punycode.
but I emphasis the word "SHOULD" because I dont think it is a "MUST"
requirement on the app developer. The reason is because the app
developer may provide warnings in the form of a warning pop-up,
highlighting the dangerous A-URL, send them to a warning page before
proceeding, or something we haven't thought of right now.
On Mon, May 12, 2008 at 11:57 AM, Patrik Fältström <patrik at frobbit.se> wrote:
> In the implementations of IDNA I am writing (more for DNS registration side
> than lookup side) I am definitely doing multiple A-label => U-label =>
> A-label iterations to ensure the string is "stable" and accepted regardless
> of whether the string start with an A-label or U-label. That is the easiest
> way to check that the string is "ok" (programmatically). Instead of having
> different rules depending on how the label "enter the system".
> I would be very very nervous if some document made it "impossible" to do
> such tests.
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update