On 1/1/2020 9:19 AM, John R Levine wrote:
It's somewhere between a profile and a BCP. The profile would be of
5321 or 5321bis, a set of commands and features it needs to support,
e.g., EHLO with 8BITMIME and STARTTLS and PIPELINING.
"Profile" turns out to have two, competing meanings.
There's a basic difference between creatinga larger, all-encompassing
spec and then defining a subset that is useful, versus defining a small,
common core and adding options to suit specific needs.
The former is what lots of classic 'profile' efforts do,notably from the
telecom industry. The base is complex and cumbersome, with the profile
intended to define a streamlined, useful subset. The latter is what the
Internet work historically has done, though perhaps less so, recently.
What your second sentence, above, cites sounds more like the latter,
which isn't a profile of 5321 per se, but rather is a combination of all
of 5321 plus a set of additional options, made mandatory. I assume the
intent is something like a Exterior MTA Profile.(*)
The goal for 5321bis should be to make it as streamlined as possible, so
that it defines a core, highly interoperable engine, that contains only
the essentials, needed across all uses, and without touching topics that
are extraneous to that core. It's simpler to implement and use, and
it's simpler to maintain the spec.
The current RFC has material that made sense to include in 1982. It
arguably should have been removed from RFC 2821, but in any event is
clearly out of scope now and that material is substantially out of step.
ps. In distinguishing relaying within an enterprise from relaying across
the open Internet, it finally occurred to me that we could replicate the
language used for routing protocols and refer to Interior MTA and
ietf-smtp mailing list