Scott Kitterman wrote:
On Saturday 09 February 2008 15:29, WebMaster(_at_)commerco(_dot_)net wrote:
Scott,
At 12:33 PM 2/9/2008, you wrote:
On Saturday 09 February 2008 13:41, David MacQuigg wrote:
At 11:59 PM 2/6/2008 -0500, Scott K wrote:
Are we calling forwarders, forwarders yet or are you still changing
existing terminology?
we are using the term "forwarding" in a more limited way
Any approach that takes the view "We are using words you are used to, but
to mean different things." is doomed to fail.
I appreciate the spirit of your statement and tend to agree with it,
but I don't think that is what Dave is doing or talking about here.
So far every time I read these suggestions I find words are meant to mean
something other than what I think they mean.
"Forwarder" an "forwarding" are not really jargon terms outside of these
threads. "Relay" is the proper term. When we say "forwarder" we don't mean
an MSA, for example. In that respect, we limit its meaning.
As long as we make acceptable limitations to the natural language terms, I
think it should be acceptable.
There is a clear distinction between relaying and forwarding (rcpt to doesn't
change in relaying). Trying to conflate them just adds to the confusion.
Rcpt MAY change in relaying: That's the generic wording, e.g. from rfc2821:
any further (forwarding, gateway, or relay) systems MAY remove the
return path and rebuild the MAIL command as needed
In facts, if a relay didn't change the RCPT, messages would just jump from
sender's MSA to the MX destination host, possibly via backup MXes. That's
what forwarding is all about. BTW, the latter argument also leads to the
conclusion that there is a unique boundary along the message path, between
MON and MRN.
IMHO, the confusion stems from the IETF having apparently lost its ability
to specify standards. One may wonder why rfc2821 explains relaying with
examples grabbed from the email museum, like so:
For example, mail received at relay host xyz.com with envelope
commands
MAIL FROM:<userx(_at_)y(_dot_)foo(_dot_)org>
RCPT TO:<@hosta.int,@jkl.org:userc(_at_)d(_dot_)bar(_dot_)org>
will normally be sent directly on to host d.bar.org with envelope
commands
MAIL FROM:<userx(_at_)y(_dot_)foo(_dot_)org>
RCPT TO:<userc(_at_)d(_dot_)bar(_dot_)org>
As provided in appendix C, xyz.com MAY also choose to relay the
message to hosta.int, using the envelope commands
MAIL FROM:<userx(_at_)y(_dot_)foo(_dot_)org>
RCPT TO:<@hosta.int,@jkl.org:userc(_at_)d(_dot_)bar(_dot_)org>
or to jkl.org, using the envelope commands
MAIL FROM:<userx(_at_)y(_dot_)foo(_dot_)org>
RCPT TO:<@jkl.org:userc(_at_)d(_dot_)bar(_dot_)org>
Of course, since hosts are not required to relay mail at all, xyz.com
may also reject the message entirely when the RCPT command is
received, using a 550 code (since this is a "policy reason").
Is the IETF becoming the Internet Museum?
It's impossible for me to tell without clear language. I get very nervous
about threads entitled last call when the language isn't at all clear.
That was also David's concern. However, all language terms are final when
they are dead. I tend to understand "last call" as obviously implying the
last one *thus far*.
After we have gone through the process, we can revisit the
terminology, if needed.
I agree, and that should be focused on specific terms.
I take the opposite view. Any solution written in impenetrable jargon that
no one outside the group of jargon developers can understand is no solution
at all.
I also agree. Our private jargon is good for internal discussions and
documents. Any writing meant to be comprehensible to a wider public has to
include the definition of any term whose meaning we will consider relevant
or useful for clear writing. For some writings, we can use circumlocutions
that would annoy ourselves if used every day.
-------------------------------------------
Sender Policy Framework: http://www.openspf.org
Archives: http://v2.listbox.com/member/archive/735/=now
RSS Feed: http://v2.listbox.com/member/archive/rss/735/
Modify Your Subscription:
http://v2.listbox.com/member/?member_id=2183229&id_secret=93480809-37ff06
Powered by Listbox: http://www.listbox.com