On Sat, Jan 30, 2021 at 10:18:22PM -0500, Richard Damon wrote: > On 1/30/21 9:40 PM, Sam Kuper wrote: >> On Sat, Jan 30, 2021 at 11:22:43AM -0500, Richard Damon wrote: >>> The issue is that the 'footer' separator that was used isn't really >>> a truely distinctive line, just a line with some number of >>> underscore that could easily just happen in a natural body of text. >> >> To be clear, I was not suggesting that the traditional Mailman footer >> separator was *perfect*. I'm not wedded to that particular footer >> separator. >> >> All I am advocating is that: >> >> 1. Footer separators and signature separators should be >> machine-distinguishable from each other. >> >> 2. Footer separators should be distinguishable from likely body >> text, and should not be excessively long. >> >> 3. Signature separators should be distinguishable from likely body >> text, and should not be excessively long. > > The problem is that the current Footer separator fails point 2 if > 'likely' is interpreted as to by likely enough for a program to > algorithmically trim a post based on it. In particular it looks like > markdown code.
I am aware of this. Hence my saying, in my previous message in this subthread, "I was not suggesting that the traditional Mailman footer separator was *perfect*." > The key point with standard Signature separator was that the added > space after the -- makes it have no needed presentation usages, so it > was easy enough to carve out rules to keep automatic text generators > from creating it. Indeed. I was aware of this, too, as I likewise indicated in my previous message. > The key aspect is that before MUA developers can really try to > implement it as built in, the code needs to be reserved well enough > that you won't find it occuring in the wild. That part of the spec is > really needed to be implemented first or MUAs need a much more > complicated code to allow an 'oops' you took too much mode. Indeed. > I would say I am not being defeatist, but practical. The key factor > here is that to implement your goal, you will need to get an RFC > established and implemented that will add a requirement to all current > mail systems (i.e. to NEVER generate a line that matches you footer > seperator by accident) to allow for some systems to implement the > optional feature of footer removal with independent control over > footer and/or signature removal. That would be ideal, yes. But in practice, mail system developers do as they please. Some of them conscientiously respect RFCs and consider accessibility, etc. Some of them don't. For the developers who are conscientious, implementing a mechanism for handling ML footers is likely to mean writing a few lines of code. They might be able to partly re-use existing signature-handling code. Not a biggie. The developers who aren't conscientious will just ignore an RFC, as usual. > This is creating a moderate amount of work for a lot of people, so it > really becomes a need to show a significant benefit. Is there REALLY a > signifcant use case for a user want to remove list footers but not > signatures? Correction: a small amount of work for a small number of people. I believe that getting this right will occupy fewer developer-hours overall (i.e. across all affected parties, for the entire future), than leaving it wrong. By "leaving it wrong", I mean leaving Mailman continuing to use the signature separator line as a footer separator. Leaving it wrong will mean that everyone who wants to programmatically distinguish between signatures and ML footers will have to find or develop code for this, and probably tweak it endlessly and manually screen the output. *That* is a moderate-to-high amount of work for anyone unfortunate enough to need to do it. > And, it that use case important enough that it not only 'pays' for the > work in creating a new RFC and getting it implemented, but also for > the loss of footer trimming that happens because some people are still > using MUAs that do the signature removal but haven't added the footer > removal. Thankfully few MLs (ab)use the signature separator as a ML footer separator, This means that few users receive the "benefit" (really a drawback, unless the user desires it) of having ML footers treated as though they were signatures. So, the number of users negatively impacted would be minuscule >> But if someone comes up with an even better separator (a line of >> underscores followed by a space, maybe?), then that's great. In case you overlooked it, I draw your attention to this point. All best, Sam -- A: When it messes up the order in which people normally read text. Q: When is top-posting a bad thing? () ASCII ribbon campaign. Please avoid HTML emails & proprietary /\ file formats. (Why? See e.g. https://v.gd/jrmGbS ). Thank you. _______________________________________________ Mailman-Developers mailing list -- mailman-developers@python.org To unsubscribe send an email to mailman-developers-le...@python.org https://mail.python.org/mailman3/lists/mailman-developers.python.org/ Mailman FAQ: https://wiki.list.org/x/AgA3 Security Policy: https://wiki.list.org/x/QIA9
