On Sun, 21 Jun 2015, A. Schulze wrote:
That's the point: you EXPECT that. But John has the idea that this could
fail.
I don't know all the details about UTF8SMTP or EAI, but I could imagine we
see the world in ASCII.
Most of us have no daily expieriences with chinese or arabian.
And at least I could not deny *THERE* Lee@chinese may be an other Mailbox
then lEE@chinese
because of some strange encoding that may exist.
John brought up three issues.
1) Lowwercase might fail for non-ascii
2) mailbox localpart guessing not allowed
3) mailbox/local part of different case might be different person
His proposal of not doing a lowercase() completely
ignores the problem of casing for ascii (and perhaps
I have asked for confirmation that 3) exists and received no real life
example. 1) could be further narrowed down to those languages where
this is only a problem for. But there is not much point to address that
if we cannot do 2) for dogmatic reasons.
So again, I propose one of:
1) Do the lowercase() in the lookup and figure out non-ascii case
2) Don't do the lowercase() in the lookup and allow the client to
do the request without lowercase() first, then try again with lowercase()
if not found - if possible in the language/encoding used.
If these are not accpetable, we're back at using a hash instead of
base32 split and it won't solve the "guessing" issue which the clients
will have to do.
Paul
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
