--On Monday, 21 February, 2005 19:58 -0800 Erik van der Poel <[EMAIL PROTECTED]> wrote:
> I've been wondering whether my email was clear or not. The > kind of reference I'm talking about is the kind that started > this whole IDN spoofing discussion: > > <a href="http://www.paypаl.com/"; > > The above is from: > > http://secunia.com/multiple_browsers_idn_spoofing_test/ Clear enough, unfortunately. I'm still gagging. > As you can see, this HTML snippet is using a "numeric > character reference" (the а) instead of the Punycode > form of the name. Now, you may point out that HTML authors and > editors should use the Punycode form, but the above proves > that it is possible to type IDNs by hand. > > HTML has a long history of allowing users to type it manually, > and, regrettably, the browsers have an equally long history of > *accepting* practically anything that they type, whether it be > well-formed SGML or not. > > This is how we ended up with such a huge mass of garbage. The > Web browsers took the "be liberal in what you accept..." rule > a bit too literally. The browsers were too liberal. But I > digress. > > My point is that if it's possible to type IDNs manually into > HTML, then you might end up with some HTML documents that use > the very characters that you want to ban in the next rev of > nameprep. I am certainly not claiming that there will be very > many of those. All I'm asking is, how do we find out whether > they are going to be a problem? We don't. Even your Google plan (which I assume was at least partially tongue-in-cheek) would be pointless, as there is no way to run a check over the firewall and/or database-protected "dark web". We ultimately need to ask ourselves, and the implementer and, somehow, the user communities whether a more restrictive change is important enough. If it is, we pronounce the words "proposed standard" and "problems that showed up in implementation and deployment experience" and try to get it fixed as quickly as possible, recognizing that there will be links out there that need to be translated forward and back through IDNA2003 to get back links that would work with IDNA2005. If it isn't, we learn to cope. john
