[Top] [All Lists]

Re: [ietf-smtp] Possible contribution to moving forward with RFC5321bis SMTP

2020-01-02 15:49:27

--On Thursday, 02 January, 2020 14:28 -0500 Keith Moore
<moore(_at_)network-heretics(_dot_)com> wrote:

Failing to obtain some history covering both of these
questions,  pursuing this topic doesn't seem likely to be
productive, though it  could be wonderfully expensive in time
and frustration.

Some of us remember these things and the references are
potentially useful to those who do.    Are we constrained
to only talk about what we're sure everyone already knows?  
I certainly don't want us to have to revisit the entire
history of email in this discussion (and to have to repeat
that discussion every few years), but I assume that people
seriously involved in email are motivated to do that
anyway.   So I don't think it's wrong to refer to history,
and I think that sometimes it provides valuable context.

I doubt that much, if any, historical discussion should be in
the 5321bis spec(s).   If someone really feels motivated
there could be an informational document but I wouldn't want
it to be a work item for a WG.

Keith (and, to some extent, Dave),

I'm not suggesting a historical description.  I am suggesting a
rationale for any changes we make, one that is persuasive enough
to overcome the natural resistance to making changes for anyone
(and, where relevant, their management) who thinks they have a
system that is working well for them.  Otherwise, while a few
clarifications (including tracking the errata and issues at a
level similar to most of them) may still be in order, it is not
clear to me a major revision of 5321 is likely to be a good use
of time.

As to whether the IETF usually or normally or even sometimes
does an authoritative rationale document like I'm suggesting,
two examples may help.  Many of the "discussion" materials in
RFC 1122 and 1123 do precisely what I'm suggesting -- explain
why a particular recommendation or requirement is being made in
the hope that people will pay attention rather than expecting
them to do something different (and "different" is important)
just because the IETF said so.  And, of course, when IPv6 was
adopted, the reasons for the decision, as well as the alternate
proposals, were published.  Only in part because I don't think
it would take much hair-splitting to argue that one or both
examples don't apply, consider how many application-level
protocols we have that are as old as SMTP and whose basic
assumptions or coverage are still being actively reviewed and
revised.  Telnet is older, but not as heavily used today as it
was 20 or 30 years ago, the basic model has not changed in a
very long time, and the most recent standards-track extension I
can find is the data encryption stuff from 2000.   FTP is also
older, but, the additional of the HOST command in 2014 (for
which I've seen little evidence of wide adoption but may not
have been looking in the right places) notwithstanding, no
changes to the basic model since RFC 959 (and, if we were to
start counting from there, it postdates SMTP).

At least IMO and although I can name exceptions, the IETF has
almost always done better (in terms of quality and wide
adoption) with new protocols, especially ones that fill a
vacuum, than with revisions to long-established ones.  Maybe
that is how it should be but, if we are going to make revisions
to widely-deployed protocols, especially revisions that imply
that people should (or MUST) do things differently, I think
doing something differently than what it is perceived we have
"always" done may be entirely appropriate lest people look at
our work and paraphrase the comment about doing things the same
way multiple times that is attributed to Einstein.


The established terms are actually rather precise and refer to
networking abstraction, not an implementation.

Good luck trying to get everyone to use these or any other
terms, in exactly the way you want them to use them, on any
particular occasion.

As far as I can tell, people use words imprecisely, and to mean
slightly different things in different contexts, because it's so
often useful or necessary for them to do so.  There's nothing
new or odd about this.

If we are going to treat RFC 5598 and/or the discussions that
led up to it as final and normative, or even "as established
terms" and therefore align 5321bis (or any subsequent document)
with what it says (or appears to say), then let's do what my
reading of RFC 2026 requires, which is to put 5321bis aside for
a while and issue a 5598bis as a PS or BCP that makes clear
which sections or terminology of 5321 it is updating or
replacing, then come back to 5321bis.  I think a better
strategy, and more consistent with IETF practices in which no
document is so much the last work on a subject as to make it
never subject to future debate or revision, to treat 5588 as
useful guidance as we undertake 5321bis but with the
understanding that the terminology and models of 5321, 5598, or
even something else may ultimately prevail.  With that approach,
if the answer is not the terminology and model of 5321, then
5321bis should also update whatever is relevant to [re-]achieve
consistency, but that should be no big deal.   YMMD, of course.


ietf-smtp mailing list

<Prev in Thread] Current Thread [Next in Thread>