KH> I guess this illustrates one problem with open-source projects; who makes
KH> the decisions when people disagree? It's not that people who want
KH> an Nmh- prefix are being unreasonable; I mean, I understand all of their
KH> arguments; I just think my arguments are more compelling.
Do the arguments boil down to traceability vs. keystrokes?
The status quo supports both: Nmh-Attach: is used by the code, and if
someone wants to use Attach:, they can. I think that Attach: is not
the best we can do as net citizens, and that we shouldn't continue down
that path with Forward:.
PF> in defense of not using a prefix: these are all user visible headers,
PF> intended to be viewed and manipulated daily. i'm certainly happier
PF> typing "bcc" and "fcc" than "nmh-bcc" and "nmh-fcc",
Let me clarify: I'm not proposing that we go back and retrofit old headers.
As Lyndon wrote:
LN> This means, moving forward, we only generate nmh-* headers, while
LN> continuing to accept the old ones.
PF> and i prefer "attach" and "forward" to "nmh-attach" and "nmh-forward".
To save keystrokes? That shouldn't be a consideration in scripts.
And interactively, "a path" (at the What Now? prompt) is less
keystrokes that "Attach: path".
PF> as i understand it, the only worry with not using an Nmh- prefix is
PF> with leaking headers. since none of these are supposed to ever get
PF> out, conscientious scrubbing should get rid of them. (lyndon claimed
PF> they'd get out, but didn't offer an example of how, so i'm still
PF> unclear on that.)
I put one in this message. (And also an Nmh-Attach: header, which will
get scrubbed out, see below.)
KH> Personally, even if those headers DID leak out, I don't think it would
KH> be the end of the world, or even a big deal at all.
Yes, but why not try to do better: if one does leak out, allow anyone to
track it down.
RC> Pass through, nmh ignores or doesn't expect, headers should be indicated
RC> in some manner, e.g. colon prefix. Then `Bc: norm' and `Attahc:
post(1) scrubs pseudoheaders that begin with "Nmh-". It also advises the user
for each that has a non-empty value.
Nmh-workers mailing list