John C Klensin wrote:
Hector, in addition to the comments made by others
need to be the same, any use of 1yz requires extensions), I note
that this sort of thing would (i) violate well-established
recommendations about getting (final) responses back quickly to
avoid duplicate messages and (ii) would probably result in
clients disconnecting if the sequence were really
but that isn't the case.
As a sometime SMTP implementer, I'd be pretty horrified if I was
told wait... wait.... wait... try later (wait... wait... "5yz Go
away and don't come back" would be a little more plausible).
As a FULL time SMTP developer, vendor and implementor, horrified or not,
it is possible. The issue apply for FTP servers as well, where it might
have a lengthy (time wise) response where SOCKETS may time out in 30
seconds because of the lack of insight by the author that it MIGHT be
even CONCEIVABLE that the backend may want to pre-process an upload
response is confirmed.
In short, like it or not, HOW will your client react if a SERVER did use
it? You have nothing in the specs that prohibits it and fortunately,
most MUA client I have tested and the few MTA clients I had tested all
honor it. Thats not the say that it warrants or justified it, but if you
are suggesting that clients will break, then that is more the reason
why you should make it very clear how it ought to be used.
You might be able to overcome some of these difficulties in an
extension, but it certainly does not belong in the base spec.
I disagree but I defer to your rules. Thats too bad because I can't help
but feel if someone else would had brought this up, you would take a
more open minded consideration. I am sorry to say that only because I
find it extremely odd that technical clarity in this case is not taken
serious when in reality the less serious nits are being debated else
where. The odds are very good systems you will be confronted with this
ISSUE more so than some of the other issues that essentially have little
to no impact in improving the system.