The problem arises if an implementation cannot implement discard
without generating a NDN.
Then it hasn't implemented discard; it has implemented reject.
I agree emphatically; thanks for the consise statement.
We seem to be stuck between the following two mutually exclusive positions:
1) Discard is a vital service, and MUST be supported even if it cannot be
supported correctly.
or:
2) A Discard MUST NOT generate a DSN; if the implementation has no way to
silently dispose of a message, than it does not support Discard.
I'm voting for #2. To me it makes no sense for the semantics of discard to
vary in different implementations, no matter how well documented. If I try to
give a SIEVE script to an implementation that always generates a DSN, I *want*
'discard' to return a syntax error.
<csg>