[Last-Call] Gen-ART Last Call review of draft-ietf-lamps-e2e-mail-guidance-14

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-e2e-mail-guidance-14
Reviewer: Paul Kyzivat
Review Date: 2024-02-17
IETF LC End Date: 2024-02-19
IESG Telechat date: ?

Summary:

This draft is basically ready for publication, but has nits that should be fixed before publication.

NITS: 5

(I also have included some questions at the end that I don't think qualify as issues.)

1) NIT: Section 9.7.2:

In the following:

"If such a proxy handles certificate discovery in inbound messages (see Appendix A.2.1), it will also need to communicate the results of that discovery process to its corresponding proxy for message composition (see Section 9.7.1)."

I think there is a problem here with "... proxy ... communicate ... to ... proxy". Shouldn't it communicate to the MUA?

2) NIT: Section 2.2

s/Implmenters/Implementers/

3) NIT: Section 8.1.1

s/rFC822Name/RFC822Name/

4) NIT: Section 9.5

s/(e.g. and IMAP mailbox)/(e.g. an IMAP mailbox)/

5) NIT: IdNits:

IdNits reports many things, most of them bogus. A couple of them look to me like they deserve consideration:

  -- Obsolete informational reference (is this intentional?): RFC 3501
     (Obsoleted by RFC 9051)

  -- Duplicate reference: draft-ietf-openpgp-crypto-refresh,
     mentioned in 'I-D.ietf-openpgp-crypto-refresh', was also
     mentioned in 'I-D.ietf-openpgp-crypto-refresh-13'.


Other Comments/Questions:

I found this document very informative. I wasn't aware how many issues there are with this feature. The work required to make an MUA comply with this document seems daunting. Is it expected that this will happen for popular MUAs?

Also, do you consider web server based implementations of email clients (such as gmail) to be proxies? If so it might be good to say so explicitly. If not, then should they be discussed separately?

When composing a reply a user may find that desired parts of a replied-to message have not been quoted by the MUA. (Due to the rules in 5.4.) Such user is likely to curse and then simply copy/paste the desired text. Is the MUA expected to detect this behavior and discourage it?

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux