Re: Updating RFC 2368 (mailto: URI)

Martin Duerst <[email protected]>
Newsgroups gmane.ietf.imaa
Message-ID <4.2.0.58.J.20030216094052.051204a8@localhost>
At 19:54 03/02/15 -0800, Paul Hoffman / IMC wrote:

>At 5:59 PM -0500 2/15/03, Martin Duerst wrote:

>>Or is it forbidden to include such octets %-escaped? In that case,
>>it would be impossible e.g. to create a mailto: URI that sends a
>>PNG image to somebody (for example, not that that's frequently done).
>
>It is impossible to do that anyhow. RFC explicitly 2368 forbids MIME body 
>parts.

Here is all I have found about this topic; if there is anything
that I have missed, please tell me:

    The special hname "body" indicates that the associated hvalue is the
    body of the message. The "body" hname should contain the content for
    the first text/plain body part of the message. The mailto URL is
    primarily intended for generation of short text messages that are
    actually the content of automatic processing (such as "subscribe"
    messages for mailing lists), not general MIME bodies.

'primarily intended' doesn't mean that everything else is forbidden,
I guess.

    A mail client should never send anything without complete disclosure
    to the user of what is will be sent; it should disclose not only the
    message destination, but also any headers. Unrecognized headers, or
    headers with values inconsistent with those the mail client would
    normally send should be especially suspect. MIME headers (MIME-
    Version, Content-*) are most likely inappropriate, as are those
    relating to routing (From, Bcc, Apparently-To, etc.)

Again, 'most likely inappropriate' isn't the same as forbidden.
It may well be that the user is shown the image that is being sent.
Anyway, the PNG example was just an example. Actually, I worried
more about sending a message body with text other than just ASCII.
How would that be done?

Regards,   Martin.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.