Re: Never-ending arguments about mailing lists considered harmful (was: Re: Adding [ietf] considered harmful)
John, JCKSince the secretariat is JCK operating with very tight resources (something else that has JCK been in enough documents and presentations that I assume/hope JCK everyone knows), it is in _our_ advantage to let them automate JCK anything they can sensibly automate without causing _severe_ JCK problems. Conversely, asking for things that might take large JCK amounts of time and energy (such as per-user setting of tag JCK fields or application of spam filtering), is, IMO, pretty lousy JCK prioritization. Let's take this a bit further: For any suggestion involving computing and/or communication functionality, proposals should come with the resources to do the major work, where the Secretariat only has to provide some interface information. JCK (iii) I am, personally, getting concerned that the IETF is JCK approaching the point where we are more concerned about process JCK and administration than we are about doing high-quality design yup. So, here is a simple suggestion for anyone proposing anything in the IETF: Explain what real and significant problem it responds to and what it will take to develop and operate it. Who must do the work, what are their incentives for doing it and why should we believe they will be successful at doing it anytime soon? Interestingly, this applies both to protocol design suggestions and to IETF process revision. We need to start focusing on small sets of essential, near-term problems, with core, near-term solutions. As a group, we have zero success with any other approach. d/ -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
[IETF] Re: Adding [ietf] considered harmful
At last a meaningful remark, quoting from below (far below)... I cannot believe we are even having such a dumbass debate. With apologies, I do not appreciate is the number of individuals who have made observations based on their personal experience concerning the SPAM subject. Trading war stories does not contribute to meaningful technical work, and in fact works to the detriment of the IETF. Gene Gaines [EMAIL PROTECTED] Sterling, Virginia USA On Thursday, December 18, 2003, 12:00:37 PM, Mark wrote: Keith- 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. This is just wrong. From lines and Reply-to and whatever are headers that are meant to be processed by computers. So, you can say all you want about how dumb MUAs do or do not process these (and how intermediate mail servers should keep their mits off). Now, humans use these lines, too. So, call them dual use. The subject line, on the other hand, is just for people. Sure we can make programs and filters grok them to classify mail if there is some standard format (e.g., i-d actions). But, fundementally subject lines are for humans, not computers. So, comparing subject line munging to reply-to munging seems to me to pretty much apples and oranges. You might read the above as supporting your point that we should not add [ietf] to subject lines because subject lines are not for computers (or dysfunctional MUAs) to process. However, I think the correct interpretation is that it is OK for the mail server to add these tags **and** they may aid the entities that the subject line is actually for in the first place (humans). Hence, they are fine. allman (I cannot actually believe I am sending a non-snide comment in this thread. Someone should slap me. I read through the whole thread last night. Every message was dumberer than the previous one (probably including this one!). I was literally laughing out loud. I cannot believe we are even having such a dumbass debate. But, it was like a wreck on the highway and I could not stop rubber-necking. If we have this much trouble about 6 characters in the subject line then we might as well forget that problem statement thingy. Really.) --
Re: Adding [ietf] considered harmful
Mark Allman wrote: A tag in the subject line is clearly overdue. But, if we're going to do it, let's do it right. Please use [IETF] not [ietf] because it's more befitting of a proper acronym. Just what we need, a mailing list that SHOUTS. (Then again, for this list, maybe it constitutes fair warning...) -- /===\ |John Stracke |[EMAIL PROTECTED]| |Principal Engineer|http://www.centive.com | |Centive |My opinions are my own. | |===| |Music is not a noun, it's a verb. --John Perry Barlow| \===/
Never-ending arguments about mailing lists considered harmful (was: Re: Adding [ietf] considered harmful)
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 [EMAIL PROTECTED] 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?
Re: Adding [ietf] considered harmful
From lines and Reply-to and whatever are headers that are meant to be processed by computers. So, you can say all you want about how dumb MUAs do or do not process these (and how intermediate mail servers should keep their mits off). Now, humans use these lines, too. So, call them dual use. The subject line, on the other hand, is just for people. Book titles are for people, too. Does that mean that it's okay for a bookseller or library to change the titles on books, in order to help the consumer indentify where they came from? I'm a bit surprised at the frequency at which people who claim to be networking protocol engineers fail to appreciate the benefits of clean separation-of-function and layering.
Re: Adding [ietf] considered harmful
On Thu, 18 Dec 2003 13:07:24 -0500 Keith Moore [EMAIL PROTECTED] wrote: I'm a bit surprised at the frequency at which people who claim to be networking protocol engineers fail to appreciate the benefits of clean separation-of-function and layering. Hopefully the drawbacks are appreciated also. Quoting Rich Seifert, Layering makes a good servant, but a poor master. Use layering to organize the way you THINK about networks, but don't let it restrict how you DESIGN networks. If I recall correctly, David Clark used to say something very similiar to this in a protocol workshop class at Interop awhile back. John
Re: Never-ending arguments about mailing lists considered harmful (was: Re: Adding [ietf] considered harmful)
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
Re: Adding [ietf] considered harmful
The subject line, on the other hand, is just for people. Book titles are for people, too. Does that mean that it's okay for a bookseller or library to change the titles on books, in order to help the consumer indentify where they came from? Um, my library slaps a helpful identification tag on the spine of every book to help me find it. Your analogy, man ... allman
Re: Adding [ietf] considered harmful
Keith- 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. This is just wrong. From lines and Reply-to and whatever are headers that are meant to be processed by computers. So, you can say all you want about how dumb MUAs do or do not process these (and how intermediate mail servers should keep their mits off). Now, humans use these lines, too. So, call them dual use. The subject line, on the other hand, is just for people. Sure we can make programs and filters grok them to classify mail if there is some standard format (e.g., i-d actions). But, fundementally subject lines are for humans, not computers. So, comparing subject line munging to reply-to munging seems to me to pretty much apples and oranges. You might read the above as supporting your point that we should not add [ietf] to subject lines because subject lines are not for computers (or dysfunctional MUAs) to process. However, I think the correct interpretation is that it is OK for the mail server to add these tags **and** they may aid the entities that the subject line is actually for in the first place (humans). Hence, they are fine. allman (I cannot actually believe I am sending a non-snide comment in this thread. Someone should slap me. I read through the whole thread last night. Every message was dumberer than the previous one (probably including this one!). I was literally laughing out loud. I cannot believe we are even having such a dumbass debate. But, it was like a wreck on the highway and I could not stop rubber-necking. If we have this much trouble about 6 characters in the subject line then we might as well forget that problem statement thingy. Really.)
Re: Adding [ietf] considered harmful
On Thu, 18 Dec 2003 13:19:29 EST, Mark Allman said: Um, my library slaps a helpful identification tag on the spine of every book to help me find it. Your analogy, man ... A quick sampling of 15 books from our local public library shows that: a) All 15 have spine tags for on the shelves and barcodes for check in/out. b) The exact location of neither tag is standardized - the height of the spine tag is variable and attempts to not obstruct the author/title originally printed. The barcode is *usually* placed on the back in such a way as to avoid obstructing text, but on 2 books is on the *front* because less information got overlaid that way. Obviously, the library is telling us to try to not munge existing information by sticking stuff in the Subject: line. :) pgp0.pgp Description: PGP signature
Re: Adding [ietf] considered harmful
Not an option. I don't even have POP3 access to the email server. Clint (JOATMON) Chaplin Keith Moore [EMAIL PROTECTED] 12/17/03 08:26:40 would it be asking too much to add [ietf] to the subject line of each message? yes. it's completely redundant information, and it interferes with readability, particularly on small displays. why don't you get a better mail reader that lets you classify mail as it arrives? that is a much better way to distinguish one list's traffic from another. This email has been scanned for computer viruses.
Re: Adding [ietf] considered harmful
i tend to agree with keith. this thread should have started life with the subject line I can't figure out how to use filters on my client-side or web-side email system and died right there. (Both hotmail and yahoo can at least filter on To: or Cc: which'll catch emails sent to [EMAIL PROTECTED] - the same rule's worked for my old netscape 4.x client for years.) gja Keith Moore wrote: would it be asking too much to add [ietf] to the subject line of each message? yes. it's completely redundant information, and it interferes with readability, particularly on small displays. why don't you get a better mail reader that lets you classify mail as it arrives? that is a much better way to distinguish one list's traffic from another.
Re: Adding [ietf] considered harmful
On Wed, 17 Dec 2003, Keith Moore wrote: Because we, people on the road, use various mail systems and even web based mail so do the rest of us. ever tried to read mail from a palm pilot? those [foo] turds get *really* annoying... Why such a war for just 6 characters, while all mailing lists do it? because I've tried it, and found it to be a royal pain in the wazoo. Have you been out there? yup. Let's give it a try and see... feel free to set up your own list mirror that prepends [ietf]. Or for all of those so free with advice that the rest of us endeavor to program our clients, servers, etc. to add the tag, you could just program yours to remove it. Clearly y'all have more expertise in this space and interest in gaining expertise with mail software. Should be a snap. Or just change the IETF list manager to which which makes addition of the tag optional by subscriber. I've encountered that feature in the past so I know it is available. Dave Morris
Re: Adding [ietf] considered harmful
Because we, people on the road, use various mail systems and even web based mail, where the filters are not applied yet... Why such a war for just 6 characters, while all mailing lists do it? Have you been out there? Let's give it a try and see... Cheers On Thu, 2003-12-18 at 04:26, Keith Moore wrote: would it be asking too much to add [ietf] to the subject line of each message? yes. it's completely redundant information, and it interferes with readability, particularly on small displays. why don't you get a better mail reader that lets you classify mail as it arrives? that is a much better way to distinguish one list's traffic from another. Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 Toute connaissance est une reponse a une question G.Bachelard signature.asc Description: This is a digitally signed message part
Re: Adding [ietf] considered harmful
Because we, people on the road, use various mail systems and even web based mail so do the rest of us. ever tried to read mail from a palm pilot? those [foo] turds get *really* annoying... Why such a war for just 6 characters, while all mailing lists do it? because I've tried it, and found it to be a royal pain in the wazoo. Have you been out there? yup. Let's give it a try and see... feel free to set up your own list mirror that prepends [ietf].
Re: Adding [ietf] considered harmful
Hmmm, I am wondering if running this e-mail thread is adding a couple years worth of 6byte additions to the subject. Seems silly to me - I prefer lists to do this - makes many peoples life easier - doesn't make anyones life harder (and frankly if 6 bytes is going to blow your bandwidth budget - you have worse troubles than this proposal) Please consider this as someone who thinks it is a good idea because some people want it - regardless if they can jump through 10 more hoops and get the same functionality with filters (on what ? - I hate it when people bcc: mailing lists and you loose the from/cc field containing the mailing list you are filtering on) - procmail (oppps what about the people that don't use that, etc. Bill On Thu, Dec 18, 2003 at 10:39:21AM +1200, Franck Martin wrote: Because we, people on the road, use various mail systems and even web based mail, where the filters are not applied yet... Why such a war for just 6 characters, while all mailing lists do it? Have you been out there? Let's give it a try and see... Cheers On Thu, 2003-12-18 at 04:26, Keith Moore wrote: would it be asking too much to add [ietf] to the subject line of each message? yes. it's completely redundant information, and it interferes with readability, particularly on small displays. why don't you get a better mail reader that lets you classify mail as it arrives? that is a much better way to distinguish one list's traffic from another. Franck Martin [EMAIL PROTECTED] SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 Toute connaissance est une reponse a une question G.Bachelard
Re: Adding [ietf] considered harmful
doesn't make anyones life harder it hinders readability, esp. on small screens it hinders sorting of mail by subject it gets messed up with conversations involving multiple lists it's a pain to write filters to take the stuff out... bandwidth is not the issue. Please consider this as someone who thinks it is a good idea because some people want it not everything that some people want is a good idea. regardless if they can jump through 10 more hoops and get the same functionality with filters (on what ? return-path. it's required to be there, you know... - I hate it when people bcc: mailing lists and you loose the from/cc field containing the mailing list you are filtering on) that's because you're using the wrong fields. nothing in the mail standards has ever required every recipient to appear in a to or cc field.
Re: Adding [ietf] considered harmful
On Thu, 18 Dec 2003 10:39:21 +1200, Franck Martin said: Why such a war for just 6 characters, while all mailing lists do it? If all mailing lists do it (which in itself is a dubious assertion) is sufficient justification, why are we bothering with an IETF? Maybe we should just disband and let Redmond write the standards, since all computers do it. pgp0.pgp Description: PGP signature
Re: Adding [ietf] considered harmful
Is invoking Microsoft close enough to invoking Hitler to end this thread? (Hint: please!). Keith is right. If you don't like the way the IETF discussion list comes into your mailbox, start a reflector that fixes it the way you like it. IETF+censored does more violence to its contents than we're talking about now, and I wouldn't dream of subscribing without it... Spencer
