[ I apologize for being unable to properly "thread" this reply. My ISP
decided to spend today moving mail to another machine, and broke all
the deliveries for my domain in the process. I'm replying by looking
at the ietf-822 archive from www.imc.org. ]
On 9 Jul 1997, D. J. Bernstein
(djb(_at_)koobera(_dot_)math(_dot_)uic(_dot_)edu) wrote:
}
} ... you aren't paying attention. Here's Keith's proposal:
}
} > > > I don't really think there is a big need to allow a sender to
} > > > separately specify "reply to address-list X if you want to just reply
} > > > to me", and "reply to address-list Y if you want to followup". Even
} > > > for those times when this is needed, the author can use From for the
} > > > former, and Reply-to for the latter. (With Sender used to indicate the
} > > > author's "real" address)
}
} For this to work as described, the first function, reply-to-author, has
} to use From and ignore Reply-To.
I'm not the one not paying attention. For this to work as described, two
things are required: First, the author has to change From and leave out the
Reply-To when he means "reply to address-list X if you want to just reply to
me" and he must put in Reply-To exactly when he means "reply to address-list
Y if you want to followup." The fields look like this:
Replies to address-list X to reply to me (case 1):
From: X
Sender: <real-author>
To: <destinations>
Replies to address-list Y to follow up (case 2):
From: <real-author>
Reply-To: Y
To: <destinations>
The second thing required is that user agents interpret Reply-To in such a
way that *neither* `reply' nor `reply-using-destination-fields' takes any
addresses from the To field in the event that Reply-To is present.
The quote from Keith that explains this second requirement is:
I realize that many UAs don't handle "reply-to-all" this way,
in particular a lot of UAs use Reply-to only as a replacement for From.
But the DRUMS document already clarifies that reply-to is the author's
preference as to where replies should be sent.
See <http://www.imc.org/ietf-822/mail-archive/0025.html>.
So in case 1, you get
reply --> To: X
(a) reply-using-destination-fields --> To: X, <destinations>
and in case 2 you get
reply --> To: Y
(b) reply-using-destination-fields --> To: Y
The argument, which I acknowledge that you don't accept, is that (b) is
not a change from RFC822, 4.4.4, because 4.4.4 never sanctioned (a) in
the first place. Regardless of whether it's a change from 822, in both
your proposal and Keith's it is reply-using-destination-fields that must
change in all user agents.
} > other than your willful misrepresentations.
}
} Idiot.
Yet another willful misrepresentation.
} [ RFC 822 4.4.4 ]
} > However, that undermines your own proposal as much as it does Keith's.
}
} Don't be ridiculous. Nothing in RFC 822 ``undermines'' the use of new
} header fields for extended functions. In fact, extension fields and
} user-defined fields are explicitly permitted.
Ah, but the effect of your proposal is the same as Keith's -- the reply-
using-destination-fields function will no longer use all the possible
destination fields. You can't use 4.4.4 against one but not the other.
} Keith's proposal is different. He's changing the semantics of Reply-To
} and From, with no label to indicate the change.
He's not changing the semantics; he's merely asking that the existing
semantics be enforced more strictly.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com