[Mailman-Developers] [Mailman-Users] RFC: X-Archive header fields

[Richard Hartmann]

On Feb 13, 2008 7:59 PM, Stephen J. Turnbull <stephen at xemacs.org> wrote:

> Moving to Mailman-Developers per BAW.  CC to -Users; Reply-To set to
> -Developers only.

I love being in an atmosphere where people know what they do. Proper
mail & list handling is not too much of a surprise on these lists I guess,
though.


> Argh.  You'd think they'd get in touch with the maintainers and users
> of the most popular mailing list software before approving it.  It
> doesn't even mention the word "thread".

Indeed.


> A couple of minutes' reflection suggests to me that this distinction
> may be artificial.  Specifically,

In the same sense that both a directory and a file are both files ;)


> (1) It's not obvious to me how many such distinctions make sense.  For
> example, User A may wish to jump to head of thread to see the whole
> thing, while User B may wish to jump to most recent to see if there's
> been a resolution (or maybe the list is infested with top-posters so
> reading the most recent in last-line-first mode is the most efficient
> way to get the whole thread!)  Some users may want to see an index,
> which might be by-date or by-author or by-subject.

In theory, several options could be offered. In the scheme I had in mind,
as it is what a thread basically is, is a tree view of the discussion, sorted
by thread. Of course, this can be debated, but I feel this what a 'thread'
actually is.


> (2) This URL "works" in the sense that you get the specified document,
> and the query part is ignored.  I don't know if this is an artifact of
> the server daemon or if it's part of the specification of the query
> part.
>
>     http://www.ietf.org/rfc/rfc2822.txt?bogusquery=doesnotmatter

That is implementation-specific. As the list software could handle &
generate the URI itself, this would solve itself.


> (3) In current best practice (heck, even pipermail does it) each
> message contains "up" pointers to one or more relevant indicies.  This
> means that you're at most three clicks from where you want to be
> (archive link in current message, thread index, thread-head message).

No reason to enhance this with a better, more general standard, though.


> Given those three points, I suggest that a better way to do this is to
> provide some standard queries *relative to an archived message* that
> dynamic archive servers can support, while with a static server the
> user is not very far from where she wants to be in any case.

Now _that_ is something I can fully agree with. Perhaps inject some
other X fields that allow the MUA to build their own URIs more or less
freely in reaction to whatever was supplied in the mail.

I do not think you will be able to specify standard modifiers that all list
software can agree to, so an implicit URI generation is not viable.

Which of the two options is better is up for debate, please join in :)


> Some additional comments: (1) suggests that "archived thread" is
> premature in the RFC tradition; there's no practice to support it yet
> AFAIK.  We could support it, but use of URLs with derived queries
> generated by MUAs is somewhat more flexible (there's no backward
> compatibility problem with archaic X-Headers).

As the RFC was released Dec 2007, changes should be relatively
painless to make in a new RFC.


Richard