i was starting to think i was done with this, but i guess i'm not.
david wrote:
Oliver wrote:
I prefer that we don't have Nmh- prefixes on our headers. Apart
from it seeming ugly
Don't look at them :-) I am serious. These directives are for
internal nmh use, not to please the eye unless that can be done with
and yet... those directives appear right at the top of my edit
buffer, and they do things which are documented that i can control by
adding them and removing them. i find it hard not to look at them.
they're no more "internal" than "Fcc". so pleasing the eye, is,
actually, not unimportant.
no drawbacks. Note the two distinct purposes described earlier in
this thread for the lines that appear in a MH/nmh draft header.
and unnecessary,
1) Namespace pollution. 2) Traceability when nmh breaks.
the header/pseudoheader namespace has been polluted since just about
when MH was written. the likelihood of a future problem arising from
a bit more pollution is probably about equal to the number of problems
we've had in the past.
the reasoning that went behind the deprecation of X- applies.
Does it? nmh's directives are for internal use only by nmh. I
don't call the directives "headers" for that reason, I call them
pseudoheaders. They resemble headers, but they're not. post(8)
should excise them, and no one should ever see them after. Ever.
exactly. and no one will, except for the single "draft forwarded to a
friend" case that's always been with us, and which seems really
unlikely to ever be a problem. nmh is likely the only mailer in the
world that makes it trivial to import someone else's draft message,
including headers, as a whole.
RFC 6648 objects to X- because:
Under this convention, the name of a parameter not only
identified the data, but also embedded the status of the
parameter into the name itself
Status can change, so that after standardization, both forms (with
and without X-) have to be supported. nmh directives don't have
that issue, except internally within nmh, and we have complete
control over that.
Nmh- isn't a status, it's a namespace. It won't change.
If mmh, GNU mailutils mh or perhaps a GUI that supports MH
folders like Claws Mail add the same feature, they might not
want the Nmh- prefix.
Of course. They should never see it. If they do, it's a problem and
I want to know about it.
But some users may want to mix the clients and have them interoperate.
If a new header called Attach: or Forward: or Anything Else: is
standardized, but has different semantics than an nmh pseudoheader with
the same name, what would nmh then do?
i guess we'd change the name. as you've said, these names are only
ever seen within the context of the running nmh. we'd have to release
note such a change, of course. we can even document now, that if an
Attach or Forward or Dcc or Fcc header is ever standardized by the
IETF, that we'll probably need to change nmh's user interface at that
time. in fact, we should add that disclaimer anyway, since we already
face that potential problem with long-existing headers.
paul
You see the problem in CSS where you end up having to specify certain
properties multiple times for webkit, firefox, IE and then also
without the prefix for once the feature got standardised.
I don't envision nmh's pseudoheader sematics aligning perfectly with
anything that might be standardized.
David
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
=----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma, where
it's 53.8 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers