Never-ending arguments about mailing lists considered harmful (was: Re: Adding [ietf] considered harmful)
2003-12-18 10:15:40
Keith and others,
While...
(1) I agree that this (and any SpamAssassin or other
header-insertion or filtering) would, ideally, better be
done as a per-subscriber optional feature, and
(2) I recognize that, if for some reason (unfathomable
to me, but there is no accounting for taste), people
encapsulate messages in message/rfc822 body parts and
then sign them (or archive hashes of messages including
the headers), any modification of the encapsulated
message would wreak havoc, and
(3) I've got an MUA (and an MTA) that are capable of
filtering on Return-path and/or List-* and/or receipient
(including subaddress)fields,
there are three things about this discussion that bother me...
(i) A number of efforts within the community have pointed to the
advantages of having more routine work done in a routine and
automated way by the secretariat. Since the secretariat is
operating with very tight resources (something else that has
been in enough documents and presentations that I assume/hope
everyone knows), it is in _our_ advantage to let them automate
anything they can sensibly automate without causing _severe_
problems. Conversely, asking for things that might take large
amounts of time and energy (such as per-user setting of tag
fields or application of spam filtering), is, IMO, pretty lousy
prioritization.
(ii) Even with powerful filtering and organizing tools, some of
us prefer (as a matter of taste) to not have, e.g., one folder
or color per mailing list or other correspondent. For us, a
subject line indicator of source makes it easier to organize
things cognitively. Is it a big deal one way or the other? Not
for me at least; I can't speak for others. But it is helpful to
some of us, regardless of what the MTA or MUA may or be able to
do. And that makes me (at least) a little intolerant of people
starting religious wars that, themselves, consume large amounts
of (human as well as network) bandwidth, if only because...
(iii) I am, personally, getting concerned that the IETF is
approaching the point where we are more concerned about process
and administration than we are about doing high-quality design
and engineering and getting high-quality results out. I don't
think we are there yet, and I think the trends in that direction
are still reversible, but I take
* the relative amount of energy the community seems
willing to spend discussing two, essentially trivial,
changes to mailing list management, or
* the fine details (rather than broad issues) of a
process WG charter, or
* heated arguments about proposals for which most of the
people actively participating in the discussions have
clearly not read the relevant documents, or
* IESG being willing to tie up Proposed Standards (or
even lower-maturity documents) in order to make sure
that all of the grammatical and procedural niceties are
adhered to, or
probably several other things that belong on that list...
as symptoms of serious and deep problems with our priorities and
how we do business.
For the record, before I'm quoted out of context (as I probably
will be anyway), our copying procedures from SDOs that have
become much more procedure-bound, so much so that they often
appear to no longer care about quality or adoption or
interoperability of standards as long as the many procedural
rules are followed to the letter and they can report getting
more standards out one year than in the previous one would not,
IMO, be a good idea ... indeed, it would be closer to the height
of stupidity.
To make a distinction that may be useful before you (or someone
else) replies, if you (or someone else) wants to get on a tear
about NATs, I may or may not agree with you, and I may or may
not believe that the flaming the topic tends to generate will
result in any real progress or changes in behavior, but at least
I'm sure the issue is important to the future of the Internet.
Can you say the same for whether the Secretariat and its mailing
list machinery adds (or does not add) a few headers to a message
or a few characters to a subject line ... assuming they don't
_break_ conforming software used in a rational way (e.g., with
the robustness principle in mind)? And, if the answer is "no",
is there any hope of increasing the ratio of meaningful
technical standards work to this sort of debate around here?
regards,
john
--On Thursday, 18 December, 2003 09:58 -0500 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
<sarchasm>
Maybe we should also rewrite the From header field so that
people with dysfunctional MUAs won't have trouble replying to
the list?
Maybe we should also rewrite the Reply-to field so that it
doesn't matter when people get confused about the difference
between reply to author and reply all?
And let's be sure to rewrite the To field so that everyone who
uses that field to collate list traffic will get the messages
put in the right bin.
</sarchasm>
It's taken us ~15 years to get rid of "features" like those
mentioned above that well-meaning authors of list software put
in to work around lack of user agent functionality. We're
still not rid of all of it.
I used to call it "header munging disease" - the idea that if
a message passes through an intermediary, there's a strong
temptation for the author of that intermediary to consider
munging every header field (as well as the message itself)
just in case it could somehow be useful to somebody -- never
mind that this removes valuable information from the message,
and reduces everyone's ability to use the messages to that of
the least capable MUA.
Putting [foo] in the subject header is just another example of
this trend. Sure, it might be useful to people with
dysfunctional MUAs, and there are a lot of those people out
there. There were once a lot of people whose MUAs couldn't do
"reply all", too.
The short-term solution is to make [foo] an optional feature
specified on a per-recipient basis.
The long-term solution is to fix the MUAs to recognize and do
appropriate things with List-* fields.
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: Adding SpamAssassin Headers to IETF mail, (continued)
- Adding [ietf] considered harmful, Keith Moore
- Re: Adding [ietf] considered harmful, grenville armitage
- Re: Adding [ietf] considered harmful, Franck Martin
- Re: Adding [ietf] considered harmful, Keith Moore
- Re: Adding [ietf] considered harmful, David Morris
- Re: Adding [ietf] considered harmful, Mark Allman
- Re: Adding [ietf] considered harmful, John Stracke
- Re: Adding [ietf] considered harmful, Keith Moore
- Never-ending arguments about mailing lists considered harmful (was: Re: Adding [ietf] considered harmful),
John C Klensin <=
- Re: Never-ending arguments about mailing lists considered harmful (was: Re: Adding [ietf] considered harmful), Keith Moore
- Re: Never-ending arguments about mailing lists considered harmful (was: Re: Adding [ietf] considered harmful), Dave Crocker
- Re: Adding [ietf] considered harmful, Mark Allman
- Re: Adding [ietf] considered harmful, Keith Moore
- Re: Adding [ietf] considered harmful, John Kristoff
- layering and separation of function, Keith Moore
- Re: Adding [ietf] considered harmful, Mark Allman
- Re: Adding [ietf] considered harmful, Valdis . Kletnieks
- [IETF] Re: Adding [ietf] considered harmful, Gene Gaines
- Re: Adding [ietf] considered harmful, Bill Strahm
|
|
|