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

John,

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.

--
Sincerely

Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


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