Sean, <chair-hat> Thank you for your submission of this draft. The chairs have reviewed this, and we think it is an interesting contribution to the IETF email normalization discussion. BUT while this may help OPENPGP and SMIMA limit the "search" for their record lookups, it is not strictly needed. In your draft there is nothing that is strictly security related, thus it does not fit within our charter, additionally it is outside the expertise of most of its participants. We strongly recommend that you take this work to the APPSAREA where there are more of "The Mail Gods" for discussing this issue. We will not be using this document as justification to meet. If we *do* meet, and there happens to be free time, we may be able to give you some time to discuss it, but simply an an "FYI", not something which DANE might adopt / really discuss Olafur & Warren On Monday, 7 March, 2016 01:20, "Sean Leonard" <[email protected]> said:
> Hello: > > As the chairs graciously requested and got a meeting slot in Buenos > Aires, I would like to request DANE ALPS (Alternative Local-Part > Synthesis) discussion time at IETF 95. > > The Internet-Draft was posted back in October: > http://mailarchive.ietf.org/arch/msg/dane/5oV9mDolVS09UoF_ZCQOWAH1f9k > > https://tools.ietf.org/html/draft-seantek-dane-alps-00 > > There has been discussion about local-part and e-mail address > equivalence issues on other IETF mailing list(s) in the last couple of > months. The Mail Gods say that only the receiving MTA gets to determine > whether different local-parts are "equal". "Equal" means "deliver to the > same mailbox" (a conceptual entity). They are right. The proposed ALPS > protocol does not change anything about this. To the extent people > perceive otherwise, it needs to be clarified and cleared up. > > But the issue is an important one for storing names--particularly e-mail > address-based names--in DANE, for S/MIME, PGP, and other future protocols. > > I suppose that the presentation and discussion time should include not > only ALPS, but a review of other approaches (see, e.g., John Levine's > thread "Encoding local parts in better ways" and associated I-D). It > should also review some of the most common local-part equivalence > constructs, i.e.: > differences solely attributable to case > sub-addressing ( + - and = ) > return-path randomization etc. > UTF-8 (beyond ASCII range) > > Regards, > > Sean > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane >
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
