[Mew-dist 06566] Re: mailto: url support

[sen_ml at example.com]

At around Wed, 30 Sep 1998 00:42:19 +0900,
 藤原  誠/ Makoto Fujiwara <makoto at example.com> may have mentioned:

>   The original question was, in fact, the handling of URL written
> in the mail. 

i should have phrased the question better :-)

imho, i think it would be good for mew to be able to handle mailto:
urls which are in messages, but what i really meant was whether
there were mew functions which could be called with an argument
being a mailto: url.

> If the URL is with 'http://', the 'browse-url-or-mew'
> is appropriate pointer, maybe, but the original asks handling
> of 'mailto:' type URL.  Mew is the Message Handler and Mew may
> potentially have the full support for 'mailto:' type URL found
> in (received) mail. Parse the URL with 'mailto:' and put headers
> and body message in the draft buffer. Should be nice idea.

this is the intent of rfc 2369 i think.

another application idea i was considering was to add support to mew
to managing a user's mailing list interfacing.  i have a proto-type
file-format in mind that looks like this:

X-List-Name: mew-dist
X-List-Type: fml
X-List-Resources: <http://www.mew.org/FAQ/FAQ06/index-j.html>
List-Help: 
List-Unsubscribe: <mailto:mew-dist-ctl at example.com?body=subscribe%20name> (*)
List-Subscribe: <mailto:mew-dist-ctl at example.com?body=unsubscribe%20name> (*)
List-Post: <mailto:mew-dist at example.com>
List-Owner:
List-Archive: <http://www.mew.org/Win32/search-j.html>

X-List-Name: pgp-users
X-List-Type: fml
X-List-Resources:
List-Help:
List-Unsubscribe: 
List-Subscribe: <mailto:pgp-users-ctl at example.com?body=subscribe%20firstname%
20lastname> (*)
List-Post:
List-Owner:
List-Archive:

...

if mew had a function which created a draft message when handed a
mailto: url, it would be easy for users to subscribe, unsubscribe, get
help, etc. from various mailing lists.  each user can accumulate
mailing list information into a file (like the one described above --
of course it doesn't have to be a single file) to be made use of in
the future.  since most mailing list software does not support rfc
2369 yet (and some may never), a user might want to accumulate this
information (i know i want to :-) ).

since (except for things like a user's name or email address),
subscribing to most mailing lists is the same for everyone (and public
information), a repository of mailing list information could be made
available to everyone (an updated of course), so that interfacing to
mailing lists could be made more uniform from the point of view of the
user.  a very desirable consequence -- at least from the user's standpoint.

if more mailing list software comes to support rfc 2369, then any
given (recent) message which originates from a list using that
software will contain headers like:

  List-Unsubscribe: <mailto:mew-dist-ctl at example.com?body=subscribe%20name> (*)

so, to unsubscribe from a particular mailing list, a user should just
have to locate a message from a particular list, and execute an
appropriate command which locates the List-Unsubscribe: header,
extracts the appropriate mailto: url, hands it to the
mew-draft-compose-message-from-mailto :-) function...and presto, a
draft for unsubscribing from a particular mailing list will be
made available to the user.

the applications of the other headers should be obvious, i think.

(notes: 

  1) the format described above contains X-List-* headers -- these are
     not part of rfc 2369.

  2) it's not as elegant as it could be, because rfc 2369 doesn't allow
     for variable substitution -- see section A.5 -- but it's a good start,
     i think.  the (*)s in the example above are an indication that the
     user will probably want to modify the message in some way --
     for example, it may be necessary to specify an email address.
     perhaps fib functionality could be applied here in some way?

  3) one could also track information about whether a user is currently
     subscribed or not for a particular mailing list (though of course, this
     is only always a guess -- who know what the current state of a mailing
     list is?)
)

> But I don't think the current 1.93 have that facility.
> ( I am just writing my understanding and nothing more than that.)

too bad.  i wonder how difficult it would be to implement?  it seems
to me that this functionality might exist in w3 mode or some other 
elisp package -- if so, perhaps that functionality can be used directly
or as a base?

comments?