ietf-smtp
[Top] [All Lists]

Re: email-arch: bounce vs... return?

2007-10-15 10:31:08



--On Monday, 15 October, 2007 11:24 -0400 "David F. Skoll"
<dfs(_at_)roaringpenguin(_dot_)com> wrote:

I think we should avoid "bounce" completely.  We should say
"reject with an SMTP failure code" and "generate a failure
notification message" because those phrases are unambiguous.

This is more or less what 2821bis does now.   

The old "bounce" terminology was removed, not because of any
conspiracy, but because, if one read other documents that were
floating around, and other meanings (including the "bounce to
someone else" that you mention), it was clear that the term had
become ambiguous unless the reader read 2821 (or 821) very
carefully and kept their definitions separate from others that
might be floating around.   While I was sorry to see it go for
various historical reasons, ambiguity, even apparent ambiguity
based on sloppy reading, serves no one well.   It is in our
interest to eliminate it when that isn't too painful.

I think Dave (Crocker) is now asking the same question about
email-arch.     I didn't take his note as an invitation for
people to propose new terminology that had not been actively
used before, no matter how attractive that terminology might be.

My only reservation about some of the suggestions is that I
don't think we get ahead by introducing yet more terminology.
As with "bounce" some people will draw some analogies and
decided the meanings for the new terms are obvious.  Others may
find them less obvious, or even that they obviously mean
something else.

Where precision is needed, it seems to me that we have two basic
alternatives:

        (i) Use terminology similar to that suggested above,
        which is very clear, very precise, and avoids trying to
        reify everything down to a single term whose meaning we
        hope is clear.
        
        (ii) Use the established precise terminology when needed
        to talk about addresses, which, for this case, is
        "backward-pointing [envelope] address" or
        "reverse-pointing [envelope] address".  It is clumsy
        but, again, there is no ambiguity.

The main reason I mentioned the new usage in 2821bis is that I
don't think it helps us to introduce terminology in the
architecture document that is inconsistent with the terminology
used in the base specifications.  If the architecture document
uses one term to refer to a given concept, and the base protocol
specifications use a different term, the readers are left
wondering whether there is actually a difference that must be
understood or whether we are just confused and trying to get
them to join us in our confusion.

     john