Re: Predraft of a new URL scheme: mailmsg

>* Your examples have spaces. Spaces must be encoded in URLs.

Correct; that was a mistake on my part. I'll fix that in the next round.
This also brings up something that we need to put in the spec for client
software writers: they have to decode strings before sending the message.
Few mailing list programs would understand the command "subscribe%20foo-l".

>* Could this be done as an extension to the 'mailto' URL?

Certainly, if folks here think that that is a good idea. I didn't think it
was a good idea to extend an existing scheme since many client program
writers might have assumed that the scheme is fixed. If I were writing a
URL-reading client and was coding for mailto, I would take everything after
the ":" and stuff it into the "To: " field. Amending mailto: would make
this kind of programming break, which is why I chose a different name. I'm
open to either.

>* Security considerations: it's important that no agent send mail
>  'from' a person without that person being aware of the details of the
>   recipient and content.

Very true; however, this is a client implementation issue. We could put in
the spec a warning about this kind of problem (maybe not quite as graphic
as Rob's...), and strongly urge client software writers to always show the
user what is about to be sent before sending it off. This will work the
same as selecting a "mailto:" URL today, except that two fields (subject
and content) are already filled in.

--Paul Hoffman
--Proper Publishing

Received on Tuesday, 3 January 1995 17:23:10 UTC