ietf-822
[Top] [All Lists]

Understanding response protocols

2004-09-08 12:00:02

Nathaniel Borenstein writes:
Most users don't have a very complex mental model about this stuff.  

And experts are supposed to be an exception?

Sometimes I want my response visible to everyone who read the original
message. In standard USENET terminology, that's a ``followup,'' although
I'd call it ``respond'' in an MUA.

Sometimes I want my response visible only to the sender of the original
message. In standard USENET terminology, that's a ``reply,'' although
I'd call it ``respond only to sender'' in an MUA.

Those two cases cover almost every response I send. Yes, there are some
occasions where I want to do something more complicated, but those
occasions are rare enough that I don't mind handling them manually.

Of course, the followup address list and the reply address list are
based on information provided by the sender. (I can't expect to send my
message to the original Bcc addresses, for example!) This information is
provided through a protocol. Do the protocol details really matter? Yes,
they do:

   * The sender has to be able to specify a followup address list that
     doesn't include the reply address list. For example, the correct
     followup address list for this message is ietf-822(_at_)imc(_dot_)org; the
     correct reply address list is djb(_at_)cr(_dot_)yp(_dot_)to(_dot_)

     Any protocol that doesn't allow this---for example, ``reply to
     Reply-To||From; follow up to To+Cc+(Reply-To||From)'', which was
     the de-facto standard---is inherently broken.

     Of course, I can say ``Please take djb(_at_)cr(_dot_)yp(_dot_)to out of 
the cc list
     if you're sending mail to ietf-822(_at_)imc(_dot_)org(_dot_)'' Anyone 
following up
     can do this manually. But this human protocol is much less pleasant
     than something handled automatically by the MUAs.

   * There's a huge installed base of software that writes messages (and
     of messages already generated by that software). There's also a
     huge installed base of software that reads messages.

     A protocol that has horrible effects when it interacts with today's
     software---for example, ``reply to From; follow up to Reply-To''---
     isn't broken per se but would impose huge transition costs. Yes,
     the simplicity would be nice, but it's much more difficult to
     deploy than other protocols.

   * There's a small but noticeable installed base of mailing-list
     software that inserts the list address as Reply-To. This breaks
     ``reply to Reply-To||From,'' among other things.

     This software should be stamped out anyway, but in the meantime
     it's helpful for a protocol to provide a workaround.

The protocol we're moving to---``reply to Mail-Reply-To||Reply-To||From;
follow up to Mail-Followup-To||(To+Cc+(Mail-Reply-To||Reply-To||From))''
---solves all of these problems. It allows the sender to specify an
independent followup address list; it doesn't hurt existing software;
and it provides a workaround to Reply-To insertion.

As a practical matter, my MUA inserts Mail-Followup-To: 
ietf-822(_at_)imc(_dot_)org
into this message, since I told it a long time ago that I didn't want
copies of messages sent to ietf-822(_at_)imc(_dot_)org(_dot_) If you follow up, 
and your
MUA supports Mail-Followup-To, then you'll be faced with the correct

   To: ietf-822(_at_)imc(_dot_)org

rather than having to edit

   To: ietf-822(_at_)imc(_dot_)org
   Cc: djb(_at_)cr(_dot_)yp(_dot_)to

down to the desired address list. Nobody has presented any reasons that
the protocol should be modified; the bottom line is that it works.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago