LYNX-DEV implementation of cc: on mailto:

[Al Gilman]

  From: Foteos Macrides <address@hidden>
  Subject: Re: LYNX-DEV problem getting lynx-cgi to work

    ...  In a LINK or Anchor the ?searchpart is a DISadvised field
  in the actual URL...                                                
  
                        The FM code will treat any cc= fields in the
  ?searchpart as extensions of the primary address, adding the values
  to that primary, comma-separated list.  

  [...]
  It would be a simple hack of the FM LYMail.c to make components of a
  primary address list advisory, but IMHO that should be all or none.
  
[Al Gilman:]
DESIRABLE BEHAVIOR (just suppose...)

Let me describe one application scenario where I currently think
of a mailto: in an HREF (with cc: parameter) as a good solution:

Original_poster sends an item by mail
     To: lynx-dev
     cc: interested_third_party

What do we want in the web page at FLORA as the best support for
appropriate follow-up?

When someone goes to respond to this post, consider that the
draft distribution offered to the responder is:
     To: original_poster
     cc: lynx-dev, interested_third_party

Structurally, one could describe this as:
     To: previous_From
     cc: previous_To, previous_Cc

There is room for debate and list-by-list policy vote on the
issue of whether previous_From and previous_To appear in these
places in the reply addressing or swap places.

In any case, the person sending mail (the responder writing a
follow-up post) should review the proposed distribution and make
address-by-address decisions to add or delete addresses starting
with those suggested by the automaton.  In fact, given what
current desktop tools will do in the way of supplying addresses
in headers, the user presently should be able to edit addresses
as text strings, too.

The above is my rough model of good Mail User Agent behavior.

CURRENT FM CODE BEHAVIOR (have I got it right?)

From what you said, what I expect to get from

     href="mailto:original_poster?cc=lynx-dev,interested_third_party";

when Lynx processes this mailto: is
     To: original_poster, lynx-dev, interested_third_party
     Cc: <only what responder adds>

and the responder cannot revise the To: value.

That seems unfortunate.  There are plenty of cases where one
would appropriately eliminate either lynx-dev or the
interested_third_party from the addressing of one or another
response.  Since at the moment the archiver doesn't know whether
original_poster is on distribution via lynx-dev or not, the only
safe policy is to include original_poster in the automatic draft
addressing and leave it to responder to delete that entry if the
original_poster is known to be on distribution and not want
duplicates.

IMPLEMENTATION THOUGHTS

Appropriating addresses placed in the URI as cc= values into the
To: header is probably expedient in terms of the Lynx code.  In
that case it is all the more important to give the responder the
opportunity to revise the resulting To: value.

The user-defined Mail User Agent option (recently mentioned by
Gil, but with us from ages dark) would solve these problems and
reduce the pressure to (laboriously) turn Lynx into a real Mail
tool.

--
Al Gilman

;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;