Re: Confusing UAs considered harmful (was *Reply-to* considered harmful)
Keith Moore <[email protected]>
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Message-ID | <[email protected]> |
> On Mon June 6 2005 14:58, Keith Moore wrote: > > > Rather, the whole assumption that the author of a message should be able to > > change the behavior of a recipient's user agent is very much in doubt. > > That's emphatically NOT the assumption behind the Reply-To field semantics. > "suggestion" != "change the behavior" It was the assumption in RFC 822, according to both my reading of that document and my understanding of statements made by the editor of that document. 2822 (correctly IMHO) changes the semantics to "suggestion". However, most MUA implementations still treat Reply-to more as an "indication" of where responses are to be sent than as a "suggestion" - in the sense that they use Reply-To to change the default behavior of a Reply command, they don't make it clear to the recipient that the default behavior is being changed, and they don't allow recipients to easily choose other behaviors. > > The only way to make Reply work better is to improve the user interfaces > > of mail user agents so that recipients of messages are more easily able to > > explicitly choose where their replies go. > > Agreed. Maybe UAs, when instructed to respond, should start with "Where > do you want your message to go today?" :-) > > > To the [extent?] new fields can help > > this process, they can only do so by providing more information to a recipient > > to inform that choice. > > Maybe. Sometimes too much information can make matters worse. Ultimately > a respondent needs to give some thought to the matter, and neither a UA > nor a new header field is a substitute for thought. Entirely agree. And if we're going to have a new field for suggesting where replies go, it needs to be designed in such a way that it makes a useful suggestion for the recipient, rather than in such a way that recipient UAs are expected to process it automatically without human input. Keith