Re: Understanding response protocols

> I don't follow that; which part of the specification do you
> believe is responsible for failure of some UAs to display the
> field?
The part that doesn't say that it needs to be obvious to the recipient 
that replies aren't going to the recipient list of the original 
message.
> > > > (a) there's no way to determine the sender's intent (did he want the
> > > > old behavior or the new behavior?)
> > > Regarding a default set of response recipients (as discussed above),
> > > I see no "old" vs. "new" dichotomy; it's the same behavior (which
> > > in any case is the respondent's (or his UA's) behavior). If the
> > > original author(s) feel(s) that expressing an intent is important,
> > > there are several ways at his.their disposal
> > These exist regardless.  By that argument, we don't need reply-to or
> > mail-followup-to or any other header field to affect how replies are
> > addressed.
> No, that's not the argument. You seem to be conflating the
> recipient list with the indication of intent.
You seem to be separating them.  This increases the chance that a vital 
piece of information will be missed because the recipient has to look 
in two places.
> > It could be because
> > the sender is pointing to an alternate address for himself - say
> > because he wants to get replies on his PDA.  Or it could be because 
> > the
> > sender thought replies should go to his secretary, or to a list, or
> > somewhere else.
> Perhaps he only wants responses sent to his PDA (or secretary)
> for a limited period of time.  Perhaps he expects different
> recipients to respond to different addresses.  I don't believe
> it practical to devise a way to handle the myriad of
> circumstances that individual authors might under some
> situations like to express -- at least not without adding
> more confusion to the situation (which languages should
> the authors desires be expressed in, which charsets, what
> formats should be used for date and time, how should
> precedence relationships be expressed, etc.).
Having too little information is confusing because it's ambiguous.  
Having too much information is confusing because it's complex.
The simple solution is to let the author supply text  that describes 
why the recipient should or should not use a particular reply address, 
since the decision is going to be have to be made by a human recipient 
(rather than his MUA) anyway.  But this doesn't lend itself to giving 
the recipient a small and fixed number of buttons to choose from, and 
that's the style most MUAs have adopted.
> > > > (b) it would make the effect of setting reply-to even less
> > > > predictable than it is now
> > > Specifically for "middle" responses, I see no change.
> > We seem to be talking about two different things.  I'm talking about a
> > new header field that would change how (new) UAs compose replies by
> > default.  You seem to be talking about a new reply button.
> What do you mean by "default" -- what is the specific
> respondent action that you have in mind that all respondents
> are supposed to conform to?
I don't have any such model of responder behavior in mind.  I have a 
model in mind for a MUA user interface that facilitates a variety of 
responder behaviors.
> > > > > Use of From (ignoring Reply-To when present), as you have
> > > > > suggested is a change to the standard response protocols.
> > > > I've suggested lots of things.  I haven't seen any suggestion, by me
> > > > or anybody else, that doesn't have some drawbacks.
> > > True, but as mentioned yesterday, this particular change has
> > > a rather small scope of impact; it affects only a subset of
> > > UAs, has no impact on MTAs, etc.
> > I disagree.
> Would you like to elaborate?
Not in detail.  In brief - it affects the vast majority of MUAs out 
there, and it makes existing uses of reply-to much less reliable.
My transition model is that, at least for many years, recipient MUAs 
need to keep honoring Reply-to (at least in the sense that they make 
the recipient aware that reply-to was used and give him the chance to 
explicitly reply to that address) _unless_ the sender of the message 
also asserted whatever new reply request gets adopted.   If we define a 
new reply request field, we can make sure that existing uses of 
reply-to don't fail.  If we redefine reply-to to behave differently (or 
to be ignored), those existing uses will fail.
> > > For (b), as I've said, I think you were on the right track when
> > > you stated that that should be handled in the message store.
> > My sense is that that answer doesn't sound good to lots of people.
> > I'm still trying to understand why.   I think there are at least
> > two issues here.  One is that it requires substantial changes to
> > existing message stores (if you built one from scratch to handle this 
> > it
> > would be fairly easy).
> As mentioned, Cyrus IMAP already has a configurable option
> for this (implemented in the message store).
so all we have to do is get everyone to switch to Cyrus, and then they 
won't want to overload mail-followup-to anymore.  how well do you think 
that will work in practice?
> > Another is that ordinary users have much
> > more ability to change or upgrade their user agents than they have
> > to upgrade their message stores.
> That might be so for a user who uses only one UA on only
> one computer to access his messages.  I don't think we
> should restrict our thinking to that model.
nothing says there can't be multiple ways of suppressing duplicates.  
it should be possible to arrange that they won't interfere with each 
other.  the user with the UA or MS that suppresses duplicates can then 
choose whether or not to originate mail with the mechanism that 
suppresses duplicates on replies to lists.
> > So there may be a perception
> > (and it may be correct) that it's easier to deploy a solution to
> > this problem in the MUA than in the message store - even if,
> > from a purely technical perspective, it doesn't work as well as
> > the message store solution.
> Unless one is dealing with a large centralized time-sharing
> system, duplicate detection (let alone suppression, for some
> meaning of the term) at an MUA requires that the MUA have
> access to sufficient information to perform the task. An
> MUA that accesses messages by any of the likely protocols
> (POP variants, IMAP) is going to involve substantial
> amounts of client/server traffic.  Better to handle
> duplicate detection/suppression at the MDA or message
> store.
I agree that it's "better" if you control all aspects of the system, 
and it's also "better" if you use multiple MUAs, and it also will work 
more reliably - for a user who can impose such a constraint on his 
message store.  However in my experience most MUAs download all of the 
messages anyway, and most users only use one MUA most of the time.  So 
for those users duplicate suppression in the MUA might be a viable 
option.
heck, I can't even get my home ISP to support IMAP/POP over SSL or TLS 
- which EVERYBODY should be doing.   (and by most metrics they are one 
of the better ISPs in the US)  I don't imagine that I'll get them to 
support duplicate suppression anytime soon.  But if someone adds 
duplicate suppression to any of several different MUAs, I can install 
that MUA on my machines and the fact that my ISP doesn't run the 
message store like I want them to becomes irrelevant.
> > > Oh! Have you never sent a response to the mailbox in the From
> > > field as well as the Reply-To address(es) when Reply-To was
> > > present?
> > Perhaps, but it's been extremely rare - and I probably only did this
> > when the Reply-To addresses were redundant with other addresses
> > that were already in the recipient list.
> That wouldn't explain including the From field mailbox when
> it was not present in To or Cc.
what does that have to do with the question?  (or maybe this is a 
rathole?)
> > There are lots of scenarios that could be constructed.  Which ones
> > deserve to have buttons dedicated to them?
> If you wish to discuss UI design, a potentially more productive
> approach might be to consider allowing the user to pick and
> choose from among the standard address fields (From, Reply-To,
> To, Cc, Sender, Return-Path) in the original message.  That
> would certainly provide flexibility.
Something like that, yes.

Keith