--On Sunday, July 15, 2007 7:25 PM +0200 "Peter J. Holzer"
<hjp-ietf-smtp(_at_)hjp(_dot_)at> wrote:
On 2007-07-14 22:25:43 -0700, SM wrote:
Note that the draft-04 mentions that "Server implementations"
should support both VRFY and EXPN and leaves it to local
installations to disable them if need be. By dropping them,
we are removing functionality that is useful for debugging.
They could be moved to an extension. EXPN is already optional
and while VRFY must be supported it can be (and is frequently)
turned off - so in practice you can't rely on it. The only
difference to other extensions is that they are specified in
the core SMTP spec instead of in a separate RFC.
Moving them to a separate RFC would reflect current practice.
However, this may be too large a change for the transition
from proposed to draft standard.
In my opinion, they cannot be moved to an extension for the
procedural reason that RFC 1123 requires their support. The
dancing around about servers being required to support them but
installations taking them out --and how that was supposed to be
done/reflected down to specific reply codes-- was a DRUMS
decision reflecting that 1123 requirement. Despite some other
tuning, 2821bis has not changed that part of the specification
in any substantive way.
That is probably just another way of saying what Peter suggests
above: this is too big a change for proposed-> draft just
because, although the rules in 2026 and its successors are much
better designed for new specifications rather than updating old
(full)standards, the baseline here is presumably the 821/ 1123
requirements, not the clean slate of a new proposed standard.
That said, I could see doing something else if there was general
consensus that it would be worthwhile. Partially because of the
circumlocutions and security consideration issues, there is a
lot of text about VRFY and EXPN in 2821bis. I may regret saying
this but, without looking at the spec, I think I could separate
that material out into a separate document called "SMTP VRFY and
EXPN Commands" or words to that effect. This would not change
the basic specification or requirements at all, but would
shorten the SMTP spec itself, keeping text that that did not
have any VRFY/EXPN details.
The arguments against doing that are that any major textual
change risks getting things wrong and it would require that the
now-long-overdue ABNF revision project break the ABNF up for two
separate documents.
Again, just my personal views.
john