--On Saturday, April 25, 2020 14:15 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
[...]
Perhaps this goes to the challenge of a specification's
distinguishing its essential core, versus
desired-but-not-required enhancements.
Completely inapplicable in this case, I'm afraid. One of the
primary goals of
the NOTARY effort, if not the primary goal, was feature parity
with X.400.
And the operational model for X.400 was success receipts as
the default.
So the feature had to be part of the core.
But thinkgs change. X.400 collapsed - a casualty of even more
serious
design errors than success DSNs. Spam became email's biggest
problem,
which made NOTIFY=SUCCESS less desirable. Privacy concerns
also arose that
weren't even on the radar at the time this work was done.
Fail to support all of the core and it's not valid to claim
to support the specification.
It's not a question of support, it's a question of operational
policy. Every
implementation of the DSN extension I've seen has no problem
supporting
NOTIFY=SUCCESS. THe debate has been over whether or not it's
legitimate to have
an operational policy of bouncing messages that ask for it.
Of course there's also the issue of whether or not the
extension, eith
or without NOTIFY=SUCESS, is of sufficient value to enable.
Some people
see little value here, and the NOTIFY=SUCCESS situation is
sufficiently
bothersome to tip the scale to dropping the extension.
The danger of a pick-and-choose free-for-all is that a claim
to support a specification provides little useful information.
Dave, we're talking about having an operational policy of
restricing the use of
exactly one feature which made sense when the standard was
defined but has
issues today. This is hardly a pick-and-choose free-for-all.
Agreed. And FWIW, it seems to me that much, if not most, of
this discussion is not about whether a feature can be
implemented, has been implemented, or interoperates but about a
potentially useful (but so far non-existent, at least in the
IETF) document that says "it would be a good idea to enable
feature A if circumstances and considerations X apply and to not
do so if circumstances and conditions Y apply". Even if either
X or Y exist all the time or are null, that sort of statement
would likely be useful. And that is a suggestion for an
Applicability Statement, one that I hope someone who cares will
start writing, not a fundamental flaw or error in the Technical
Specifications.
Just my opinion, of course.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp