----- Original Message -----
From: "John C Klensin" <john+smtp(_at_)jck(_dot_)com>
Hi.
The wind seems to be blowing in the direction of removing the
term "bounce" from 2821bis. Different people have different
reasons, but I don't think I've detected anyone who has claimed
that there is value in leaving it in.
If I don't hear a coherent argument for retaining it within the
next few days, it will be removed from 2821bis-01.
Huh? Geez and here I was learning to avoid IETF incoherent discussions.
If you are going to remove the term bounce, you are going to have to roll up
your sleeves and make an extremely clear distinction of the two different
type of "rejection notification." Is it dynamic? Delayed? 2821 based or
2822 based? Is it transaction rejection or a payload rejection?
I don't know what you have on your mind, but "Rejection" is a more generic
term that covers two forms:
- non-2822 based rejection notiication (SMTP level)
- 2822 based rejection notification (accept-bounce, DSN, etc)
What term are you thinking to replace the x822 form of a Rejection aka
BOUNCE? Non-Delivery Message? DSN?
I know you "wrote" the book, so you an do what you want, but a bounce a long
time clearly understood term. I don't see the logic to remove what has been
a very clear concept when it specifically relates to a well understood
process. When a customer calls up and says "my mail is being rejected" we
have to make sure whether its a MUA notification indicating failure to
complete a SMTP session (SMTP server rejected the transaction) or a 2822
based bounce notification. The MUA notification is not a bounce message. It
is a dynamic on the spot "popup" or notifier. This can only happen with a
dynamic SMTP level rejection.
I am all seeing cleaned up specs and reducing ambiguity, John, but I think
in this case eliminating the term BOUNCE will create more ambiguity. It is
clear, concise, specific and coherent.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com