[Top] [All Lists]

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

2007-10-15 11:49:21


First, do we have a choice here? I don't think so, so it would be a waste of time to blew against this wind.

But I have two comments:

1) I think this is yet another example of RFC editor vs audience conflict. In my view the RFC document style generally mix two disciplines - technical and functional specifications. IMO, "Bounce" covered all disciplines, including support and end users. In our experience, however, terms like "failure," "Error," and/or "reject" has always typically been expressed or reported by end-users. So if you want to make it more technical, I think you should be aware that may not the best for other disciplines.

2) My only opposition to using exclusively the NDN terminology (because it better matches Moore's document), is the possible notion that Moore's RFC might be interpreted to mean it is now an SMTP requirement which is it not. So as long it doesn't raise any false idea or ambiguity that an NDN reference in 2821bis does not mean a direct support for Moore's RFC, I personally have no problem with the bounce term deprecation in 2821bis.


Hector Santos, CTO

John C Klensin wrote:

--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

        (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.