On 11/30/2019 11:07 AM, John C Klensin wrote:
While, as you know, I've never been a huge fan of parts of 5598,
I have personal disagreements with parts of it, too. So what? It
represents community consensus, not personal opinion.
So how is a personal attitude relevant to the role of a consensus
document, especially one that had extensive community review and input
over an extended time and gets cited a fair amount?(*)
no I don't think moving it to historic would be helpful. I do
think that things have gotten more complicated (or at least
different) in the decade since it was published.
The statistics of some practices have changed. The architecture hasn't.
To the extent that you feel otherwise, please document specifics.
I also note
that it, particularly its Section 5.3, appears to say that
* all mailing list redistribution activity occurs at MUA level
(that is inconsistent with 5321, which came earlier and which
5598 does not claim to update or otherwise supercede)
The 'came earlier' perspective is fascinating. It opens an exciting
door for dismissing all sorts of later work in the IETF, including work
that explicitly and obviously is meant to provide improvements on that
earlier work.
As for the lack of a claim to update, sure, let's focus on process
rather than substance.
But to that end, an errata entry has been submitted:
https://www.rfc-editor.org/errata/eid5925
* RFC5322.From: should remain as set by the original author
(inconsistent with current practice on many lists and part of
where this thread started)
The words 'should' and 'may' do not appear in RFC 5598. As I recall,
that was intentional. The use of should here is significantly off the
mark, not as editorial nit-picking but as misplaced interpretation.
The document sought to describe existing practice. I assume your
reference to the document's stance on RFC5322.From is based on:
"Names and email addresses for the original Author of the
message content are retained."
which describes common behavior, not required behavior. But yes, an
adjustment in that language to acknowledge other behaviors would be helpful.
(fwiw, to be bit formally picky, note that even with rewriting of that
field, most systems do 'retain' the original information; they simply
add more.)
Also note that the document's Section 2.14, Mediator says:
"A Mediator attempts to preserve the original Author's information in
the message it reformulates but is permitted to make meaningful
changes to the message content or envelope."
This underscores that the altered statistics on mailing list treatment
of the rfc5322.From field does /not/ represent a change in architecture.
IMO, the inconsistencies between the first bullet and 5321 and
between the second and tampering with "From:" to work around the
difficulties between DMARC and mailing lists are evidence of
precisely what I described as a gray area.
The deeper issue is that SMTP is rife with layer violations and that
this has never been fixed. The biggest error Postel and I made with the
original documents was not making layer issues clearer and not enforcing
a rule that a normative technical detail is specified in exactly one
document.
To be fair, though, even the basics of UA/MTA distinction were extremely
new at the time and discussions in terms of layering were not yet common
in the community. (That's not a defense, merely an observation.)
I don't have an
opinion at the moment as to whether 5598 should be revised (or,
in principle, retired) as part of whatever the ADs think should
be addressed in a 2019/2020 email review and update.
This appears to espouse the view that major technical work is chosen by
ADs, rather than the community. Historically, a top-down model for
formulating work in the IETF -- in the absence of extensive community
activity and support -- has a remarkably poor outcome.
d/
(*) https://www.arkko.com/tools/allstats/citations-rfc5598.html
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp