Re: Last Call: SMTP Service Extension for Content Negotiation toProposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




> > Ah. Using the first round of RCPT TOs as capabilities checks only and sending
> > the RSET unconditionally is really quite cute.

> "cute" is rather opposite of the four-letter word I would have chosen.

> > It still has the added
> > complexity of having multiple commands per recipient, but now it is the same
> > command repeated, which eliminates a bunch of the edge conditions and makes the
> > silly states very silly indeed.

> well, I'll admit I'm curious - how does using the same command in two different
> ways eliminate a bunch of edge conditions?  (if we had only one command in SMTP
> and used it over and over would that eliminate even more edge conditions?)

The edge conditions arise when the responses from the different commands
disagree in some way. And this is likely to happen when there are two commands
and two different code paths. The usual outcome then is that things which
shouldn't make a difference do make a difference, and that then leads to the
time honored whine of "but it works when I do it over there so this stuff here
must be broken".

> really, I don't have a guess as to what you're talking about here, and I am
> curious.

Apparently you managed to miss the round of SMTP clients that did a VRFY prior
to each RCPT TO. Horrible mess, just horrible.

				Ned


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]