Re: [dane] Request DANE ALPS discussion time at IETF 95

Okay. Thanks and I respect the decision of the chairs.

(Actually it doesn't actually "limit" the search...it's more like it 
casts a broader net. But anyway.) Since we are moving on and such, there 
is one issue about the local-part that affects 
draft-ietf-dane-openpgpkey and draft-ietf-dane-smime, related to proper 
(un)escaping, which I will comment on in a separate thread.

Sean

On 3/8/2016 3:30 AM, Olafur Gudmundsson wrote:
> 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" <dev+ietf@seantek.com> 
> 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
> > dane@ietf.org
> > https://www.ietf.org/mailman/listinfo/dane
> >
>