[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: comments on draft-gellens-pop3ext-02.txt
On Thu, 12 Mar 1998, Tom Killalea wrote:
> > Note that there is no APOP capability, even though APOP is an
> > optional command in [POP3]. Clients discover server support of
> > APOP by the presence in the greeting banner of an initial challenge
> > enclosed in angle brackets ("<>"). Therefore, an APOP capability
> > would introduce two ways for a server to announce the same thing.
> I think that having two ways to announce the same thing is a lesser sin
> than returning an incomplete list with a dependence on another
> mechanism to complete the list.
I disagree. Having two ways to announce a capability introduces a "Silly
State" (see draft-newman-protocol-design-01.txt). What does an APOP
client do if APOP is in the capability list, but there's no challenge in
the greeting banner? The fact is it can't do anything because APOP isn't
supported. That means looking for "APOP" in the capability list is
meaningless even if we did add it. Human readability comes second to
correct design, and while human readability would dictate a complete list
of capabilities, correct design dictates otherwise.
> Given recent discussion on the GRIP WG list (grip-wg@xxxxxx) arising
> from draft-ietf-grip-hansen-xtnd-00.txt (which despite the name is *not*
> a draft sanctioned by that group) does it make sense to explicitly
> discourage/deprecate XTND XMIT and indicate why it's a bad idea ?
The draft says enough about this in the "Future Extensions to POP3"
section. It makes it quite clear that extensions which duplicate
capabilities supplied by IMAP or SMTP are strongly discouraged. Since
"XTND XMIT" duplicates SMTP functionality (defectively to bat), it
is therefore strongly discouraged and there's no way it could ever be