John,
Trying to make this response a brief one, and hopefully the last message
I need to write on this topic for a while.
1) While I generally support reducing secretariat workload when
possible, I don't think it follows that it's to our advantage to "let
them automate anything they can sensibly automate without causing severe
problems", particularly without taking due care in how it is done.
We've had quite a few problems already with lists being subject to
arbitrary censorship, and many of spamassassin's criteria have no sound
justification.
I should at this point re-iterate that so far nothing harmful has been
done, and it does look like there's some attempt at "due care". I hope
that publicizing this issue will encourage more "due care".
2) I have given several reasons for objecting to adding [xxx] to message
headers, ranging from theoretical/academic arguments about
separation-of-function and layering to statements of personal experience
that this very practice causes problems with reading mail on small
displays, with searching, etc. These are not absolutes but merely
factors that people should consider rather than immediately assuming
that subject munging is a good idea.
3) It's gotten to the point that almost any argument about a technical
subtlety on the IETF list gets labelled a religious war. I suspect this
is partly because we're straining to articulate the justification for
our positions (so they look somewhat like religious arguments even when
there's an underlying technical basis for them), but that's inherent
in the fact that these subjects are subtle.
I remember a time when we valued the exchange that helped to illuminate
these subtleties and give justification for our positions, and when we
did not think that this level of exchange was inappropriate or an
excessive consumption of bandwidth. I'm not sure what has changed, but
I hope it's not the case that we can no longer try to understand subtle
effects of technical decisions - because I believe our inability to do
that has caused the quality of our output to suffer tremendously.
4) I see the [xxx] labelling as a design issue. Even if we claim we're
only designing for ourselves, it's still a concern because to me the
casual attitude toward adding [xxx] reflects a lack of understanding of
fundamental network protocol design principles. I see the spamassassin
filtering as a process issue, but one that affects our ability to
produce good designs, because I've seen several occasions where
valuable input from outsiders was discarded for arbitrary reasons and
the design suffered for it.
John, I know you well enough to know that
- You've seen more than a few problems with header munging yourself,
and with munging of protocols by intermediaries in general;
- You are more aware than most that the Internet is a diverse community
with widely varying needs and capabilities and that it is becoming
more diverse all the time;
- You know enough about protocol design to appreciate the value of
separation of layers in general, and of separation of function between
user agent and transport in particular; and
- You know enough about information storage and retrieval systems to
appreciate the value in keeping data models clean.
So I don't think I need to convince you of these things. If I'm talking
to you specifically, I try to frame my statements with knowledge of your
experience and depth in mind. When I make statements like the above on
the IETF mailing list, I'm doing so for the benefit of people who don't
seem to understand these things (regardless of who is in the To field),
and part of my reason for doing so is to try to remedy that situation in
a small way.
Any good design is necessarily a compromise. It might be that there are
cases where, _after_ considering the various factors, that adding [xxx]
is a reasonable compromise, particularly for a list that operates only
for a year or two - one can argue that UA capabilities won't change much
while the list is in use. However such compromises are _not_ justified
by statements of the form "it works for me, therefore it is good for
everyone" -- particularly when the Internet is so diverse and when
there's a tendency for these practices to become entrenched.
It does seem like we often get bogged down in arguments between people
of widely varying depths, or between people of very different kinds of
expertise. In the first case there is no basis for compromise because
the person who is out of his depth doesn't understand the need for
compromise or the basis that makes the compromise reasonable. In the
second case compromise is difficult because there is little or no common
ground. I'm not sure how to resolve either kind of impasse in a
reasonable fashion other than by discussion, though this does sometimes
get tedious. Yes, I'd like to find a better way.
At any rate, it seems difficult to get a compromise before it is clear
that people understand the issues associated with a decision. Only when
people respond to an argument in a way that shows they understand and
respect the issues, or at least, that they're willing to try to do so,
does compromise become feasible. If there's a way to get closure on
such issues more quickly I suspect it involves recognizing this and
reflecting that recognition in our culture and processes.
Keith