Re: [Nmh-workers] RFC 5322 group support

[Ken Hornstein]

>Also RFC 6854.  It just allows group support in some header
>fields that 5322 doesn't.  I bring it up because it was
>proposed in March 2013, so apparently there's still interest
>in developing group support.  (I don't bring it up because
>I think it's a good idea.)

Fair enough ... looking back at that very brief discussion, I think fixing
that for us was very simple.

>> email headers have what is known as "group" support.  Specifically, you
>> can do something like this:
>> 
>> To: groupname: a, b, c;
>
>nmh handles this the same way, if there's no need for the
>trailing semicolon:
>
>  To: groupname: a, b, c

Technically, the semicolon is required by the standard.  post(1) will insert
one if it doesn't exist.  Also, I forgot to mention this with Ralph's
message, but as I read it the example he posted:

    To: cow-orkers: tom, dick, harry; xyzzy

is incorrect.  It should be:

    To: cow-orkers: tom, dick, harry;, xyzzy

Although it seems we clean this up when you get it wrong; how about that!

>After seeing your later messages, maybe that's a surprise.
>I don't know if there's a way for nmh to put a non-blind group
>in a message.

Currently, there is not.  Like I said, it's been that way since at least
1985, and I haven't seen any complaints just yet :-/

>I vote for just updating the documentation.  Because the
>trailing semicolon isn't required, maybe we shouldn't call
>it group support, just blind list?  And maybe that would
>avoid Ralph's objection?

I'm not sure how to write some documentation here that is clear; I
prefer using RFC termology whenever possible, so I'd still like to
say "group".

>Also, this might be related to the way I fixed part of this bug:
>  
>  http://savannah.nongnu.org/bugs/index.php?15604
>
>which reported that the last member of a blind list in an MH
>alias file wasn't expanded.  The fix was to remove the
>trailing semicolon from the documentation.  Now I can guess
>where it came from.  I don't see a need to revisit that
>because this is for the alias file, not in the draft.  So
>there's not an issue with non-related addresses following
>the alias on a line.

Hm, so you never figured out the root cause?  I mean, in theory it SHOULD
have worked fine.  But having just dealt with this for the RFC 2047 encoder,
I can see it's easy to get it wrong.

--Ken