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" <[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
