Hi, > That's the point: you EXPECT that. But John has the idea that this > could fail. As I already wrote, I think the important part is that we implement a new form of PGP key lookup, not a mail server. All current mechanisms are case-insensitive, key servers as well as the gpg implementation.
I have to admit I would not see a real reason why we could not allow or better require a lookup to be done in original AND lowercased form, as long as it is defined that the published record should or even must be the lowercase variation. But if we want a clearly defined version, lowercase still is in my opinion the best way. For ASCII localparts. Regarding UTF8: > I don't know all the details about UTF8SMTP or EAI, but I could > imagine we see the world in ASCII. You don't have to go to China, also Europe has many non-ASCII characters. But indeed, international email using UTF8 chars is really really uncommon here. The same goes for Japan, they simply use ASCII. I can't tell much about China, but they don't have upper and lower case characters anyway. I have NEVER seen a PGP key with UTF8 characters in the Cmail address, but I admit, the standard as I understand it allows it. I am pretty sure case insensitive comparision will fail there with the usual locale problems in the usual tools, and people using such addresses are or will have to get used to it and work accordingly. > And at least I could not deny *THERE* Lee@chinese may be an other > Mailbox then lEE@chinese As I said, the chinese don't have lower case characters. But of course european countries like france or germany have, outside ASCII. And UTF8 has other problems - there are multiple different binary representations for basically the same string. Thats why RFC6530 recommends that mail servers expect localparts could be normalized and people are advised to generate their addresses in normalized form in the first place. It's not a MUST though, which means people can do stupid things if they want to. I think very few people have acutal experience with utf8 email, but I would expect in that world, binary equivalence will be the main matching system. So do we want to care for UTF8 in the current form of the draft? If yes, my suggestion would be to clarify that the lowercasing is only to be applied for ASCII addresses. utf8 addresses should be looked up in the original form, and if that original form is not equivalent to the normalized form that SHOULD be looked up additionally. On the domain owners side I would RECOMMEND (as the international mail RFC already does) to use normalized utf8 for the address and thus for the record - if that differs from the form used in correspondence it might be advised to also add a record for that form. Generally people using such addresses should know (as people using other variations like +something) which forms of their address might be used by others, an not only add matching OPENPGPKEY records for those, but also add those forms as User IDs to their keys! I REALLY would advise not to make this a show stopper to advance the DRAFT in its current form, possibly adding some clearifications like those above for handling non-ASCII addresses. UTF8 emails are very uncommon today and it is hard to guess how they will be used, especially how PGP will be used with them. Everything beyond binary match in unified form (and in original form as backup) would be wild guessing - and I really assume, IF utf8 emails will be in broader use somewhere (asia most probably I would guess) people won't enter them manually anyway, so nothing beyond normalization should happen to it. Greetings, Florian -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstrasse 15, 81669 Muenchen Sitz der Gesellschaft: Muenchen, Amtsgericht Muenchen: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
