On Thu, Sep 08, 2005 at 12:39:39PM -0400, John Leslie wrote:
Rationale for 2.2.1: this makes it unambiguously clear that both forms
are discussed and should be interpreted that way.
I'm less clear that Alex has gotten this wording right.
OK. You disagree with the wording. Do you agree with my intention?
Our intent is that any new implementation should not first send HELO;
but new implementations must recognize HELO. Further, we (still) require
compatibility with old clients and servers which do not support EHLO.
Blindly adding an "or HELO" to each EHLO would make it hard to parse
any explanation of that compatibility requirement.
Ack. My point: it isn't clear to everyone that HELO actually _is_ defined
by 2821 (and thus 2821bis).
Right before the change I proposed it is explained that EHLO is prefered
over HELO. The entire paragraph should address your concerns.
The problematic wording seems to be: "this document discusses only EHLO".
Yes, people think the document defines only EHLO when they read that...
I feel its intentions are to say something like: "this document
discusses only EHLO and, if compatibility mode is occuring, the user
can substitute HELO instead in most cases." Do you agree (with my
feeling, not with this wording) ?
Further, if we are serious about _trying_ to deprecate HELO, we should
not be encouraging folks to think about it.
You're not serious, are you? How do you expect implementors to get it
right without thinking about it? I fear that without them thinking about
it, they just let HELO be an alias for EHLO...
I think we'd be better off generally using "EHLO" (or "hello command")
and relegating usage of "HELO" to a single compatibility note.
This is something that could work. This compatibility note should
then discuss extensions to hello, clearly stating it isn't valid when
rfc821-compatibility mode is on.