On 7/23/2020 1:34 PM, Keith Moore wrote:
On 7/23/20 1:14 PM, Michael Peddemors wrote:
If you limit to SMTP and MIME, this isn't really 'email core'.
Including IMAP and possibly others, should be encouraged.
I disagree, and for what it's worth, that's not what I had understood
the intent of the group to be.
If it's necessary to change the name of the group to minimize
confusion, so be it.
I believe that a tight focus is essential for most working groups, and
especially so for a group that's tasked with moving a set of mature
documents to Full Standard. I don't think such a group should be
used to bless potentially every email protocol in use, as IMO they
vary a great deal in both quality and long-term applicability. I
think such a group could easily slide down a slippery slope into a
But it does seem like a scope discussion might be a good use of BOF
time, assuming the ADs are willing at all to entertain the idea of
making EMAILCORE wider in scope than just SMTP and MIME.
+1 on all points.
The term "EmailCore" would inherently suggest a wider scope for the
Applicability statement covering modern electronic mail. It would
suggest all the protocols which are part of the "Email-Core" including
SMTP, POP3, IMAP, NNTP (for legacy purposes, how is it used today) and
"JMAP" which seems to be blowing pass by SMTP.
This would be the "Perry's Handbook For Mail Engineers" I personally
believe would help the "total integrated" framework moving forward for
the next wave of mail engineers.
HOWEVER, this "handbook" would definitely be too much when the
original intent, I thought, was to 2020 codifying SMTP with RFC5322bis
and RFC5321bis, preparing it for STD status. Klensin, the world,
deserves these documents to get to STD.
We also have the email-core conflicts of different mail streams,
namely, 1::1 direct mail and 1::MANY distribution streams. The
conflict has been highlighted by DKIM and its augmented security
protocols. How this fits with the "email-core' are the proposals and
discussion in the DMARC group to lower the RFC5322.From persistent
field status to a mutable one.
ietf-smtp mailing list