On 2/12/2019 6:13 AM, Alessandro Vesely wrote:
On Fri 08/Feb/2019 19:15:12 +0100 John C Klensin wrote:
FWIW, I personally believe that it would be a good idea to completely
reorganize and rewrite 5321 because the process by which we folded 821, some
topics covered by 1123, and the extensions work together created a document
that is hard to follow as well as being too long.
It's here that I find it difficult to follow your reasoning. Yeah, it would be
a fascinating idea, but would it also be a practical task to pursue?
I think so.
RFC1123 was my "holy bible" for internet hosting. It was an extremely
useful consolidated guide at the time for the early internet
integrated hosting servers developers of FTP, TELNET and SMTP.
I think we need something like it again, at least for SMTP. Take a
look at RFC1123 section 5.4. SMTP REQUIREMENTS SUMMARY and similar
tables for the other protocols. These were so unbelievable helpful as
a quick reference guide. We need another modern summary like this
again. I think most seasoned developers just want to know the
"protocol rules" and not waste time with historical design reasoning
notes. Implementators trust the cogs, who help write/mold the specs,
are doing the right (IETF) engineering thing so just give us the MAY,
SHOULD and MUST protocol product design rules.
RFC5321+ could be a reduced technical reference guide with straight
forward state machine protocol and prototyping notes for both pure
SMTP and ESMTP with add-ons such as ESMTP AUTH, STARTTLS, 8BITMIME,
etc Summary (Extended) Requirements/BCP Tables would be very helpful.
I wouldn't want to add anything new unless we wanted to add a section
on "Mail Filtering and Load Controls" concepts which has probably been
the biggest things since 2003 done with SMTP as developers began to
add these features to their implementations in order to help customers
were were getting hit hard with the unprotected return path spoofs and
unsolicited spam. Add-ons like GreyListing, SPF, DKIM and DKIM-based
Domain Policy methods would be part of such a section discussion of
the filters available. The biggest thing here would be the shift of
real-time processing to the DATA state which had added significant
session time overhead. But improved hardware has trumped those early
performance concerns, so in general, we can do more with E/SMTP today
than ever before.
I also agree that RFC5322+ should maybe be done at the same time, but
not necessarily as a show stopper if IETF WG work for only RFC5321+
can be allocated.
--
HLS
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp