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 > [email protected] > https://lists.nongnu.org/mailman/listinfo/nmh-workers > =---------------------- paul fox, [email protected] (arlington, ma, where it's 53.8 degrees) _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
