On Wed, Feb 25, 2015 at 02:01:38PM -0500, Paul Wouters wrote: > On Wed, 25 Feb 2015, Viktor Dukhovni wrote: > > >Once the client is making two queries, why accept collisions? Are > >we (after all these years) finally defining RFC-822/2822/5322 local > >parts to be case-insensitive? (Price of progress and all that?) > > > >Is a CNAME per-user really a major burden? > > It's not one CNAME, it is many CNAMEs. You'll be hashing paul, Paul > paul.wouters, Paul.Wouters, etc. I'd be better of with a wilcard :P
One CNAME per case-insensitive name (if the preferred form is mixed or upper case). Those other names you're mentioning if they all share the same underlying keys would be CNAMEs you'd have to create with or without my proposal for a mechanism to publish case-insensitive names. > The client needs smart logic anyway, and the client at least has a user > it can interact with. It can ask "A key for [email protected] does not > exist but there is a key for [email protected]". Why ask the user, when the server can just publish the fact that all upper/mixed-case veriants of "paul" are the same mailbox. > Needing to roll out between 2 and 4 different capitalizations for > different [Ff]irstname.[Ll]astname makes everything more errorprone > and the client still needs its logic and user interaction. The I don't how you get to "4". You can publish exactly one owner for each case-insensitive "LocalPart", no CNAMEs required if you are willing to accept clients making two queries to find keys in your domain (space/time trade-off): SHA2-224(localpart@lowercase) IN <RDATA> Optionally, for faster queries, if the mailbox has a preferred form: SHA2-224(LocalPart) IN <RDATA> SHA2-224(localpart@lowercase) IN CNAME SHA2-224(LocalPart) If there's also a "Local.Part" and "local.part" to go with it, that it is completely separate from my proposal which deals only with handling case-insensitive matching. The overhead of supporting case-insensitive matching is at most a second (CNAME) record for each record that would be there in the absence of the proposal. -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
