Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs

[Vlad Harchev]

On Fri, 14 Jul 2000, Klaus Weide wrote:
> On Fri, 14 Jul 2000, Vlad Harchev wrote:
> > On Thu, 13 Jul 2000, Klaus Weide wrote:
> > > On Thu, 13 Jul 2000, Vlad Harchev wrote:
> > > > On Thu, 13 Jul 2000, Klaus Weide wrote:
> > > > > On Thu, 13 Jul 2000, Vlad Harchev wrote:
> > > > > > On Wed, 12 Jul 2000, Klaus Weide wrote:
> > > > > > > On Mon, 10 Jul 2000, Vlad Harchev wrote:
> > > > > > > > On Sun, 9 Jul 2000, Klaus Weide wrote:
> > 
> >  Isn't this stack beatiful?
> 
> It would be nices if somebody else popped in once in a while...

  Yeah, I'm begining to forget that we are on mailing list :)

>[...] 
> > > > > That's a first draft for a definition of the problem, but it still 
> > > > > needs
> > > > > some work.  What exactly is 'going to'?  Obviously you don't mean just
> > > > 
> > > >   I meant 'x','g','G','E' and ACTIVATE commands (probably I missed some 
> > > > other 
> > > > exotic comand, but unlikely).
> > > 
> > > HEAD?  'd'ownload?  or
> > 
> >   As currently, not supported for mailto: URLs.
> >  
> > >   HTTP/1.0 301 Moved Temporarily
> > >   Location: mailto:address@hidden ,
> > 
> >   MUA should be invoked in this case since user will have to type message of
> > the body.
> 
> Well, probably.  It's a weird case anyway (but this kind of redirection is
> normally only blocked if no_goto_mailto is set).
> 
> > > or
> > > 
> > >   RULE:Redirect mailto:address@hidden  mailto:address@hidden ,
> > 
> >   Don't get why you give this item - it has nothing to do with mailto:
> > handling.
> 
> Maybe I should have written
>     RULE:Redirect http://somewhere/somepath/*  mailto:address@hidden ...

 Then external MUA should be used since lynx won't fill the body, and user
will have to type something.

> > Also, CERN rules for mailto: are yet not supported by lynx.
> 
> Mailto on the right side works...  (assuming the left side isn't lynxexec
> or something similar, or mailto itself).
> 
> Anyway, *you* asked for (or at least mentioned) "exotic" commands...
> My question is, is this 'going to'?  I am trying to get you to
> find a better formulation than 'going to'.

  Here is a draft of formulation:
 External mailto: handler will be used (if enabled) in the cases when the
user is expected to fill/edit body of the message (i.e. activating "mail this 
file" from 'P'rint menu won't allow MUA to be used).
 
> >  As for FORM mailto: action - since user is not expected to type anything
> > (subject field, body, etc), external MUA shouldn't be invoked. 
> 
> As above - the user *is* expected to type something in the FORM mailto action 
> case.  Namely, subject and (unless disabled) cc.
> 
> Try it.
>    <TITLE>Test of form with mailto action</TITLE>
>    <FORM ACTION="mailto:address@hidden";>
>    <INPUT type=text name=i1 value=foo>
>    <INPUT TYPE=submit name=sn value=sv>
>    </FORM>

  Hmm, never encountered forms with mailto: so I was unaware about the fact
that user will have to type anything (though when I tested this form, lynx
didn't ask anything - it just informed that mail mailto: action was sent).

> 
> > > The problem is how to describe exactly when your proposed MUA replacement
> > > feature applies and when it doesn't, for documentation in lynx.cfg and
> > > maybe Lynx_users_guide.  (Also, how to call the feature/option.)  If it
> > > can't be described simply and accurately, then maybe it's too complex
> > > or not well designed.  If it's easier to say "this option applies to all
> > > mailto URLs" rather than "this option applies to all mailto URLs except
> > > for [long explanation]", then maybe "applies to all mailto URLs" _is_ the
> > > more logical behavior.
> > 
> >   It looks like the rule of thumb is: if user is expected to type message 
> > body
> > or edit subject and cc: in given situatiuon, then external MUA will be
> > invoked (if enabled).
> 
> According to *that* rule of thumb, the external MUA would have to be
> invoked for a FORM mailto action.

  According to RFC you've quoted, it probably should (probably this will be
configurable). 
   
> I guess I also want to re-open the question whether lynx's built-in
> handling of FORM mailto actions is right.  I just read RFC 2368,
> which defines "The mailto URL scheme".  It says:
> 
> 7. Security Considerations
>[...] 
> 
> Lynx's handling of FORM mailto actions doesn't do what the RFC says.
> There is prompting for some headers, and at that point the user
> has a chance to cancel the submission with ^G, but that's it.  The
> prompts look like "Subject: ..." and "Cc: ", I am not sure that that
> is even enough to "make clear that the user is about to send an
> electronic mail".
> 
> (Whether lynx handles mailto in other contexts according to the
> specs is another question.)
> 
> Using mailto as a FORM action is non-standard and discouraged:
> 
>[...] 
> Still, since lynx chooses to support it, it should do it right.
> At least, there should be an option to select between current behavior
> and full editing access to the message that is about to be sent
> (probably just using lynx's normal reply_by_mail that is used for normal
> non-FORM mailto URLs, with some modifications - don't use "original
> message" prefixed with '>', use form data instead to pre-fill the

  Yes, this seems to be optimal approach.

> message; do something about content-type).  While we're at it, an
> option to turn mailto FORM actions completely off without having
> to disable all mail sending.

  Yes, I like this idea of turning off mailto: actions in forms using lynx.cfg
setting.
 
> Vlad, I'm not saying that you should "fix" this for lynx's built-in
> mail handling (would be nices though), but you should keep this in
> mind when thinking about external MUA invocation.  Basically, don't
> assume that just because lynx currently doesn't allow to edit an
> outgoing FORM mailto message, that's the way it should be when using
> an external MUA.

  Yes, thanks to you I think so now :)

>   Klaus
> 

 Best regards,
  -Vlad


; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden