Re: [Nmh-workers] Changes to forw(1)

[Paul Fox]

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
 > address@hidden
 > https://lists.nongnu.org/mailman/listinfo/nmh-workers
 > 


=----------------------
paul fox, address@hidden (arlington, ma, where it's 53.8 degrees)