Re: draft-klensin-rfc2821bis-04: VRFY and EXPN syntax

[John C Klensin <[e-mail]>]

--On Sunday, July 15, 2007 7:25 PM +0200 "Peter J. Holzer" 
<[e-mail]> 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