Date: Fri, 24 May 1996 16:04:55 -0400
From: John C Klensin <klensin@mail1.reston.mci.net>
Subject: Re: 821bis outstanding issues list
To: djb@koobera.math.uic.edu (D. J. Bernstein)
Cc: drums@cs.utk.edu
Message-id: <2.2.16.19960524200455.24e7f39a@mail1.reston.mci.net>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7BIT

At 19:41 96.05.24 +0000, D. J. Bernstein wrote:
>> clients MUST preferentially utilize EHLO
>
>Why?

Dan,

Is your question...

"Why bother with the extension mechanism at all, given that no one much
cares about it?"

or

"If the client knows that it isn't going to ask for any extensions, why
should it use EHLO rather than HELO?"

or

"Why should EHLO be attempted first, rather than sending HELO first?"

or

"Why doesn't the draft document explain this statement of preference?"

> [...]

>This is a violation of the as-if principle of interface design. What
>does it mean to require VRFY support if an installation is permitted
>to disable it? Clients can't rely on it.

If we start from the assumption that the "1123 excuse...is bogus", then this
is a non-issue.  But the 1123 excuse, and a lot of experience, has been that
properly implemented VRFY is very handy for debugging.   As a debugging aid,
a working VRFY is very handy.   And, if the installation that disables it
returns a "can't do that here" 4yz or 5yz reply, rather than a bogus answer,
there are all sorts of rational ways for a debugging user to behave and even
a few rational ways for clients trying to use the facility (if any) to react.

I'll leave the other issues you raise for WG discussion and, if not swiftly
resolved, add them to the issues list.

    john