[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN r
From: |
Vlad Harchev |
Subject: |
Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs |
Date: |
Fri, 14 Jul 2000 22:45:41 +0500 (SAMST) |
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
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, (continued)
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Klaus Weide, 2000/07/09
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Vlad Harchev, 2000/07/10
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Klaus Weide, 2000/07/12
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Vlad Harchev, 2000/07/13
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Klaus Weide, 2000/07/13
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Vlad Harchev, 2000/07/13
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Klaus Weide, 2000/07/13
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Vlad Harchev, 2000/07/14
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Klaus Weide, 2000/07/14
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Thomas E. Dickey, 2000/07/14
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs,
Vlad Harchev <=
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Klaus Weide, 2000/07/14
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Vlad Harchev, 2000/07/15
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Klaus Weide, 2000/07/12
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Vlad Harchev, 2000/07/13
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Klaus Weide, 2000/07/13
- Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Vlad Harchev, 2000/07/14
Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Henry Nelson, 2000/07/10
Re: lynx-dev [PATCH] remove extension to EXTERNAL command, extend CERN rules support for mailto: URLs, Henry Nelson, 2000/07/11