> 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
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 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.
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?
> 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.
Nmh-workers mailing list