0. My concern is almost entirely for the use of email as an effective medium for technical collaboration. I am far less concerned about the amount of bandwidth, storage space, etc. that this takes up. I'm not saying that that's not a valid concern, but it's two or three levels down for me in comparison to - how effectively does email support serious technical discussions?
1. Even when email was plain-text only, collaborative technical discussion over email was far from perfect. There were multiple quoting schemes in use (>, ], indent with spaces, ...) which made it difficult to write code that did a good job of quoting/wrapping messages for replies. Various email processors would wrap lines at arbitrary lengths (because some old systems had inherent line length limitations), so each new reply might generate more separate lines of text with only a few characters each. ASCII art, which was quite useful even if limited in capability, would get wrapped in replies as if it were ordinary text.
And yet, the capability we had prior to say 1992 to collaborate over email was FAR better in most respects than anything that exists today, whether standard or proprietary, email-based or web-based or some kind of hybrid.
Part of what made things work in those days was a shared understanding of the limitations of the medium, and a willingness of many participants in a discussion to manually reformat text from subject messages, as well as editing out less-relevant content from subject messages, to make their replies legible. Another part of what made things work in the old days is that MUAs treated message content as plain text and allowed it (including portions of subject messages included in replies) to be edited as plain text.
(This last bit wasn't universally true, but it was true of most MUAs used by IETF participants. I remember one particular WG, most of whose participants' MUAs insisted on top-posting and didn't allow editing of the subject message, even though their MUAs did insist on including the full text of each subject message in every reply. And since their MUAs prevented them from collaborating effectively over email, that WG insisted on having frequent face-to-face meetings that were at first not announced outside of the WG. Even after that, they treated the IETF face-to-face meetings as inconveniences, because those meetings brought in a lot of "outsiders" who weren't on board with the core WG. The longstanding rules about announcement of interim meetings, that are now being discussed again, were a direct result of that group's practices - but that group's practices were largely a consequence of the MUAs they used. Tools really do matter.)
More generally, even in those days, some IETF participants found it advantageous to use a different MUA, and perhaps a different email account, than those recommended or imposed by their employers, in order to better work with IETF mailing lists. (The way that their MUAs handled replies wasn't the only reason, but it was one reason.)
2. Even after MIME introduced explicitly typed message body parts, I'm not aware of any serious attempt that emerged to make collaborative email work better. Perhaps this was because the old use of plain-text only seemed good enough, and not everyone started using HTML all at once - it crept up on us. And in those days it was common for MUAs to allow sending text-only messages, and some participants would do that out of courtesy.
It seems like a little bit of effort to make MIME+HTML work better for collaborative technical discussions, if done early enough, might have yielded significant benefit. e.g. define distinct markup for wrapped text vs. non-wrapped text. But to my knowledge the experiment was not done, at least not in a multi-vendor environment. And format=flowed came a bit late to expect universal adoption.
Also, there's nothing to tell an MUA that some particular recipient address is a collaborative technical discussion that should use different rules for replies than ordinary messages.
3. Part of the problem may be that, even before the introduction of HTML, there was a widespread assumption that SGML-like syntax should be used for markup. SGML and its descendants have a fundamental flaw in that they expect text to be tree-structured, organized in a hierarchy like chapters, sections, paragraphs, and so on. This might be mostly harmless for documents that evolve linearly and have a small set of editors. But collaborative technical discussion over email isn't like that at all.
In that environment it's important to be able to quote fragments of text from one or more subject messages, where any quoted fragment might span several layers of hierarchy in that subject documents, without having those quoted fragments disturb the hierarchy of the reply. Similarly it's useful to be able to reference arbitrary fragments of text without regard for whether those fragments contain fragments of multiple levels of document hierarchy. It's difficult to do that in a format that assumes that text documents conform to a hierarchy.
Also, a series of email messages that are exchanged in a technical collaborative discussion, is not like a single document that's being edited or annotated by multiple contributors. Instead, there's a set of documents/messages that evolve more or less independently from one another. Even that set of messages isn't tree-structured because a reply might quite reasonably quote fragments from multiple messages that don't have a common set of antecedent messages.
I'm not saying that it's impossible to do this in *ML can't be defined; clearly this it is possible to define such conventions. But it won't work well, unless ALL MUAs that are used to contribute to the conversation implement the same protocol for parsing that *ML and composing replies, and that needs to behave reasonably when generating replies to messages that don't implement that protocol. And we already have approaching 30 years of inertia of implementing HTML email poorly that is not easily overcome. (just to pick one example, which MUA vendor wants to make its newer versions behave incompatibly with its older versions for the sake of interoperability with some emerging standard?)
4. My recollection is that HTML was added to email almost as an accident. MIME didn't assume that HTML would be used, because web browsers and the web were only barely visible to the public by the time MIME was published. But early web browsers (at least those for GUI environments like Mosaic and later Netscape) tended to include email MUAs (as well as Usenet capability). And the browsers already had HTML rendering capability, so supporting HTML email in those browsers only seemed natural... even if a lot of pesky details didn't get sorted out right away, and some not ever. In those days, effective support for most MIME content-types was "launch a separate application in a separate window", so built-in same-window HTML support in an email reader did a lot to legitimize that format.
Even today, there's really no standard for use of HTML in email. Interoperability is poor in the sense that different MUAs generate very different HTML, and the same HTML message will look very different on different recipients' MUAs. There's no set of carefully-crafted agreements for privacy-vs-functionality tradeoffs. Each MUA generates replies in its own fashion. etc.
So when referring to HTML support in MUAs, we shouldn't talk about whether HTML email is supported as if "support" were well-defined or use of HTML email is standardized in any meaningful way. It's a crapshoot, and that would be a problem even without considering use of HTML email in collaboration.
A. define a format for use in collaboration that needs to contain ( fixed-text / flowed-text )* On 8/18/23 16:59, Brian E Carpenter wrote:
Hi, I'd like to take a slightly different approach, and hence have moved this from tools-discuss because it's not (just) a tools issue.We have an ongoing disaster that is making email much less effective for the IETF and we aren't talking about it.- There's the old story about top-posting vs in-line comments. (Too make your life harder, this message does both, although IMHO top-posting should be used rarely, mainly for changes of tack like this one. In-line comments are almost always better in an ongoing conversation.) - Flowed vs line-wrapped. (For many years everybody wrapped their messages at about column 72, or even less. These days, we have an unholymixture of wrapped and flowed text with no obvious pattern and it makes long discussions harder and harder as they go on and on and on, and is compounded by the next problems.)- Monospaced fonts vs variable width. (For many years everybody used monospace and it was common to include ASCII art in emails. Today, that's essentially broken. I've also seen messages where apparently there were tables that have been converted to a variable-width font but of course don't line up at all in the receivers MUA.) - Different mechanisms for quoting. (For many years, a simple ">" at the start of each quoted line did the job, and quoted quoted quoteslooked like this.But now we seems to see multiple quoting methods depending on which MUA is operating. There's also a nasty interaction between CRLF and LF line endingsthat sometimes affects quotingin a weird way. ) - And of course some people insist on sending HTML mail and assume that the result will be legible and comprehensible despite the fact that they use colours and fonts and font sizes that are unsuitable for many readers and/or their MUAs. A conversation that consists of a mixture of plain text and HTML messages rapidly becomes a swamp. Are we going to tackle this mess? (Some more in-line comments below.) On 18-Aug-23 21:35, Vasilenko Eduard wrote:Hi IETF new IT,It is radicules that participants of many WGs could not just push “Reply” to a message in the most common e-mail program in the world.I don't see that as ridiculous (and I don't know which MUA you mean).We need to trim it (loose context),The full context is the mail thread, and can always be found, but what matters is that the new comment can be read in the appropriate context. I've never had to trim *relevant* context, although I certainly intentionally trim irrelevant context. (I won't trim this message so that people who didn't see it on tools-discuss can read to the end, but that won't take it anywhere near a limit.)convert it to text (loose HTML features),As I said above, losing HTML features is no loss.and control it manually so that the message would not cross the 80KB limit.I had no idea there was a limit on 6man. I can't imagine a *useful* messagein a conversation that needs that many characters. (Yes, occasionally people choose to review a draft by including 100% of the text; I've never understood why.)Could we release this limit to something like 1MB? PS: My 3 previous employers (for 25 years) restrict messages to 10MB.As Robert Sparks pointed out, allowing anything like that on mailing listscreates a significant amount of network traffic. It also fills thousands of disks around the world with redundant megabytes and contributes to global warming. I'm quite aware of the ridiculous message sizes incorporate networks - the combined effects of front-posting and rich text -and I think it's unquestionably a bad thing. In fact, one of my employers introduced automatic message expiry and deletion after six months as a result, which had very negative side effects. Regards BrianEduard *From:*Glen Barney via RT [mailto:support@xxxxxxxx] *Sent:* Friday, August 18, 2023 6:02 AM *To:* Vasilenko Eduard <vasilenko.eduard@xxxxxxxxxx> *Subject:* [rt5.ietf.org #20604] RE: Large messages to 6man list Hello -You've reached the IETF Support center - we're the platform operators for the IETF - and this address exists to allow for the reporting of services which are down or malfunctioning.Your question pertains more to operating policy of the IETF, and settings used by them for the operation of their services. If you feel that a policy should be changed, please reach out to the Tools Team on thetools-discuss@xxxxxxxx <mailto:tools-discuss@xxxxxxxx> and voice your opinion.I should mention that the IETF infrastructure is in a transition mode - they are moving all of their services from their current provider (us) to new hosting under design. It is likely that your concern will be addressed as a part of that transition, but, again, you can voice your opinion there if you wish and let them know.Thank you, Glen -- Glen Barney IT Director AMS (Outgoing IT Platform Provider)On Thu Aug 17 02:34:02 2023,vasilenko.eduard@xxxxxxxxxx <mailto:vasilenko.eduard@xxxxxxxxxx> wrote:Hi IETF IT,Is it possible to improve the default message restriction?Keeping history is much more convenient if the investigation is neededlater (for a particular topic). Context is important but lost whenmessages are trimmed.It is 2023 now. Storage space is much cheaper https://diskprices.com/ <https://diskprices.com/>.What is the reason for the 80k restriction? (I assume historically)Eduard-----Original Message-----From: Bob Hinden [mailto:bob.hinden@xxxxxxxxx <mailto:bob.hinden@xxxxxxxxx>]Sent: Wednesday, August 16, 2023 6:15 PMTo: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>>Cc: Bob Hinden <bob.hinden@xxxxxxxxx <mailto:bob.hinden@xxxxxxxxx>>; Ole Troan<otroan=40employees.org@xxxxxxxxxxxxxx <mailto:otroan=40employees.org@xxxxxxxxxxxxxx>>; Vasilenko Eduard<vasilenko.eduard@xxxxxxxxxx <mailto:vasilenko.eduard@xxxxxxxxxx>>Subject: Re: Large messages to 6man listGenerally the solution to this is to not just reply and send,, but todelete the reply history from the email. Otherwise for longdiscussions, the emails keep getting bigger and bigger.Bob> On Aug 16, 2023, at 2:35 AM, Pascal Thubert (pthubert)> <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>> wrote:>> Oups!>> Sorry Ole.>> -----Original Message----->> From: Ole Troan <otroan=40employees.org@xxxxxxxxxxxxxx <mailto:otroan=40employees.org@xxxxxxxxxxxxxx>>>> Sent: Tuesday, August 15, 2023 4:07 PM>> To: Pascal Thubert (pthubert) <pthubert@xxxxxxxxx <mailto:pthubert@xxxxxxxxx>>; Vasilenko>> Eduard>> <vasilenko.eduard@xxxxxxxxxx <mailto:vasilenko.eduard@xxxxxxxxxx>>>> Cc: Bob Hinden <bob.hinden@xxxxxxxxx <mailto:bob.hinden@xxxxxxxxx>>>> Subject: Large messages to 6man list>>>> Pascal, Vasilenko,>>>> You are still posting too large messages to the 6man list. Over the>> 80KB message limit.>> The consequence of that is that we have to manually approve them, or>> they might not make it to the list.>>>> O.___________________________________________________________Tools-discuss mailing list - Tools-discuss@xxxxxxxx - https://www.ietf.org/mailman/listinfo/tools-discuss
