Andrew Derbyshire writes:
 
>It looked like your routine built a wonderful RFC822 header, but didn't
>reduce it, or did the original have an odd number of quotes?  From a
>human standpoint, "Andrew H. Derbyshire" should stay that, not become
>"\"Andrew H. Derbyshire\"" or ("Andrew H. Derbyshire").  Also, you
>might try quoting the name via parenthesis instead if the special
>character "quote" is in the header.
 
Although I agree that the original quoted string should stay as it is
rather than having its quotes escaped and extra quotes added, that is a
special case.  (By the way, I got Eric's version without an odd number
of quotes.)  It does make sense to quote the "phrase" part of the second
(phrase route-addr) definition of "mailbox" when necessary to denature
"specials", when it is not already adequately quoted.
 
Your other suggestion (parentheses) has limited applicability and little
point, since "s are perfectly valid in "phrase"s if balanced.  First,
if you comment out the entire "phrase", you have to remove the <>
around the "route-addr", which must then conform to "addr-spec" format
(no "route" part).  Second, if the original "phrase" contained unbalanced
parentheses in quotes, it was valid, but the addition of parentheses around
the whole thing denatures the quotes and the result becomes invalid.
 
An example of the first point:
      "Andrew H. Derbyshire" <$AHC@CLVM>
cannot become
      ("Andrew H. Derbyshire") <$AHC@CLVM>
but must be
      ("Andrew H. Derbyshire") $AHC@CLVM
instead.
 
(Now, I don't really believe that is *right*, just required by RFC822.)
 
An example of the second point:
      "Andrew H. Derbyshire (202 555-1212" <$AHD@CLVM>
cannot become
      ("Andrew H. Derbyshire (202 555-1212") <$AHD@CLVM>
or even
      ("Andrew H. Derbyshire (202 555-1212") $AHD@CLVM
due to unbalanced parentheses.
 
Silly?  Possibly, but it can happen in a world of limited field lengths
and human typists.
 
--Mark