Richard Damon writes: > On 1/30/21 9:40 PM, Sam Kuper wrote: > > All I am advocating is that:
> > 2. Footer 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. Really? I can't recall ever seeing a long line of underscores in the wild -- except in my (accidentally) rms-baiting .sig (see below). I don't have a strong opinion on this, myself (that's why I asked). But it's quite clear from RFC 3676 that there are tools that handle .signatures specially, and I'm not sure that they're all strippers. For example, they could be tools to extract contact information, in which case the naive implementation (go to EOF, back up to .sig separator, parse) would fail or even corrupt data if list footers use the "-- " convention. The fact that the RFC goes to the trouble of special-casing the .sig separator (it's specifically NOT format=flowed even if that is specified, and not subject to stuffing, DelSp, etc.) strongly suggests that there are a lot of naive tools out there. > 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. A slightly more precise spec than Sam's such as exactly 72 underscores followed by exactly one SPC (or even HT) should be unlkely to occur even in markdown. > 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 Not the way IETF works. Almost certainly[1] this convention would be considered "not wire protocol" and therefore not in scope for IETF, except perhaps for an update to 3676 giving the footer separator the same treatment as the .sig separator (and that assumes my suggestion were adopted). If the distinction is desired by users, having Mailman document it, and IWBNI other MLMs adopted it, that would be enough. No RFC needed, really. > 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. I don't consider that a big loss if we switch back. Given the prevalence of top-posting nowadays, I doubt anybody cares about .sig stripping except us Boomers (and Mark, who is honorary Greatest Generation no matter his age :-). Especially since "-- " has only been the footer separator since June 2017. I doubt many users will have noticed (either way). Steve Footnotes: [1] In IETF mail standardization, all we can be certain of is uncertainty itself. -- ________________________________________________________________________ ________________________________________________________________________ What are those straight lines? "XEmacs rules." _______________________________________________ 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
