[Gnu-arch-users] Specifying protocols [was: the dangers of no reply-to munging]

[Stephen J. Turnbull]

I've gone off-list on mail headers themselves, but understanding
design of communication protocols is directly relevant to
understanding arch (or any revision management system).

>>>>> "MJ" == MJ Ray <address@hidden> writes:

    MJ> These cases are not very well constructed, as M-F-T is not a
    MJ> good solution for any of them.  You might also like to ask
    MJ> "Given only M-F-T and other non-List-* headers, how can I tell
    MJ> if a message is from a mailing list?" and

Why would you ask any of these questions?  AFAICT, they are of purely
academic interest.  They do not communicate information directly useful
in construction of reply addressee lists.

Yes, I can see ways to use that information, in combination with other
information, to construct useful information.  But there are other
ways to get the constructed information, too.

    MJ> "What does M-F-T actually give that isn't present elsewhere?"

That's a good question, but there's too little context to be directly
answered.  In a conversation like this one, people often end up
talking past each other (as I think you and Andrew are---viz, Andrew
already answered this, and you dismiss his examples as "not well-
constructed"), because the context comes out in dribs and drabs, and
neither protagonist is willing to adjust "his" context to accomodate
the other's points.  And there is a _lot_ of context!  For (extended ;)
example:

In designing a mail protocol to facilitate replies, there
are three important issues (aka "requirements") to be aware of:

(1) The replier has several abstract options for constructing
    addressee lists in replying, and which is appropriate depends on
    her intent and the content of the reply.  (By "abstract" I mean
    that if the replier had time and full knowledge of all _personal_
    mailboxes, she would construct a subset which goes directly to the
    intended recipients, does not Pass Go, and does not collect 200
    List-* headers.)

    Typical criteria would be "I want to CC the sender personally if
    and only if she wants CCs" (note, nothing about why, eg, avoiding
    dupes) and "I want to send to all members of some abstract
    discussion group (== list of personal mailboxes of people
    participating, including lurking, in a thread)".[1]

(2) The sender often has information that the replier does not which
    is relevant to accurate construction of real addressee lists that
    implement the replier's abstract addressee list.

(3) Any communication between the sender and replier is off-line.  The
    sender only gets one chance, and that is before the sender can
    know anything about the replier's intent.

Now, of course (1) has an infinite variety of "answers," but it's
generally agreed that there are two important abstract classes of
addressees, which I will immediately expand to three:

  o the sender
  o the discussion group (all addressees)

Now break up the discussion group into two abstract classes,
giving:

  o the sender
  o the automated mailing list(s) in the discussion group
  o personal CCs in the discussion group

Note these are still abstract because we haven't said how to identify
them.  One is easy.  RFC 2822 specifies that the From: header
identifies the sender.  Now, what might people know that others don't
know?

  o The sender is authoritative on his reply-to.  Unfortunately, RFC
    2822 doesn't implement this in the Reply-To: header, presumably
    for backward-compatibility reasons, since there was a draft from
    IETF DRUMS that proposed it.

  o Either the sender or the replier may be able to identify a given
    mailbox as a mailing list.

  o Either may be able to identify a given mailbox as a personal CC.

Now I will propose two further abstract splits:

  o Mailboxes that are part of the abstract discussion group, and
    those that are not.  Note that a member of a list may not be a
    member of the abstract discussion group ("There is a discussion of
    an SCM that may be of interest to l-k members on gnu-arch-users"
    should be posted to l-k, but Alan Cox, a member of l-k, is not a
    member of the abstract group---at least not yet ;).

  o Personal mailboxes that are members of the abstract discussion
    group via a mailing list, and those that are not.

I'm not saying these can be implemented simply enough to be useful,
but we want to go farther than useful in the abstract.  This allows us
some room to speculate about what doesn't breach the bounds of being
too fragile to be useful in the concrete spec.

  o Once again, the sender is authoritative on whether he's part of
    the group.  (You know, the "delete me from CCs, please" message.)

  o The sender is authoritative on whether he is a member of a list,
    and whether he wishes to receive personal copies anyway.

  o Either the sender or the replier may be able to identify abstract
    group members or nonmembers.

  o Either may be able to identify a mailbox as a personal mailbox
    which is a member of a mailing list.

Then the questions are (1) what is the finest partition of concrete
mailboxes (== including mailing lists) we can achieve (ie, into
"should vs. should not be in the reply's addressee list") based on
information known to somebody in the system, and (2) what protocol
communicates that information effectively to the replier, who
constructs the addressee list?

Here's one set of concrete distinctions we can dispose of immediately.
According to requirement (3), above, the replier can't help the sender
compose his headers, so we can ignore what the replier only knows;
eliciting that information efficiently is purely an issue of MUA reply
UI design, not mail protocol (header) specification.

Plan:

Based on this rather fine categorization of abstract addressee lists,
we specify what mappings of abstract addresses to contruction of reply
headers the replier might want to implement.  These mappings are then
checked for feasibility based on the information the replier has in
the status quo.  Then we ask what information that the sender might
have would improve the accuracy of the available constructions if the
replier had access.  Now we specify a protocol for the sender (or
intermediate agents) to communicate that information to the replier
via a header (such as List-Post or M-F-T).

Finally, we think about implementations of MUA reply UI which use the
header information to heuristically (MUA can't know what the replier's
desired abstract addressee list is, so this must be heuristic) suggest
a construction of a concrete addressee list.  This permits analysis of
the accuracy of the heuristics.

Details:

Left as an exercise.  ;-)  I've made the point about specification
that I want to, and don't have time, anyway.

To come full circle, I will comment on the question that I called
"academic".  In the abstract, the replier only cares that his message
will go to his desired abstract addressee list.  (Note that we don't
need to worry about whether that list will propagate properly to
iterated replies; if his MUA complies with the _sender information and
advisory protocol_ we are now specifying for him to use, this is
automatic.)

Whether any specific abstract mailbox is implemented as the target of
a mail exploder or not is not necessary information, although it could
be useful in construction of the concrete addressee list.  But in some
cases, such as when using the M-F-T protocol, it's not useful for the
sender (or an intermediate relay) to communicate it to the replier.
The sender has already told the replier everything he knows about
which mailboxes are members of the concrete manifestation of the
abstract discussion group: exactly the list in M-F-T.[2]


Footnotes: 
[1]  Note that concrete newgroups and mailing lists are an imperfect
implementation of abstract discussion groups.  Cf. the Roundup issue
tracker for an alternative approach.  http://roundup.sf.net/

[2]  I think.  I haven't done the analysis, but this is Andrew
Suffield's claim reduced to essentials, and it seems plausible to me.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.