On Apr 5, 2015, at 6:56 PM, Lyndon Nerenberg <[email protected]> wrote: > > > On Apr 5, 2015, at 6:22 PM, Paul Hoffman <[email protected]> wrote: > >> Greetings again. The discussion about exact-match and discovery in >> draft-ietf-dane-openpgpkey has been useful for finding out what the use >> cases are, and it's time to settle on a design that works for most people >> (we're never going to make everyone happy). > > How can we possibly do that without real experience in the field?
How can we possibly get real experience in the field unless we get at-least-rough consensus on a direction and publish a document? > I know for a fact the case insensitive hashing rules will break Cyrus, where > foo+Bar@mumble will deliver to mailbox 'inbox.Bar', which is distinct from > foo+bar@mumble, delivering to 'inbox.bar'. Folder names are case sensitive, > so the two addresses are not equivalencies. I'm not sure what "break" means in this context. It means, as I proposed, that Cyrus will not be able to do exact-match lookup of key/cert records, but that doesn't "break" Cyrus any more than the current situation where no lookup is possible. > Ultimately, I don't see a way out of this other than to make a standard for > sub-addressing, with a well defined cut-point delimiter. That's an alternative for the second point I proposed, one that I think would be much harder to get agreement on than "Webfinger to find keys/certs". > But that still doesn't change how the LHS has been defined as case-sensitive > since the dawn of time. If we are to change this, RFC5322 3.4.1 needs a > change in its last paragraph. As things stand, we cannot treat <local-part> > as case-insensitive in any interpretation of the grammar. Nothing in what I proposed (or what has been proposed before now) changes anything about how LHSs are treated. The address in mail messages don't change at all. --Paul Hoffman
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
