W3C home > Mailing lists > Public > www-html@w3.org > July 1998

RE: <a href="mailto:email address">

From: Jukka Korpela <jkorpela@cc.hut.fi>
Date: Thu, 9 Jul 1998 09:31:48 +0300 (EET DST)
To: www-html@w3.org
Message-ID: <Pine.OSF.3.96.980709085949.551A-100000@alpha.hut.fi>
On Wed, 8 Jul 1998, David Norris wrote:

> >That is a very browser-specific method, and URLs should be "handleable"
> >by other kinds of apps (like Email, Usenet, etc.). The extended mailto

This relates to my suggestion of adding attributes to the syntax
of A elements. In what particular sense would that be very
browser-specific? As I mentioned, it would downgrade gracefully,
unlike the extended URL syntax.  

> This is an important factor to remember.  URIs are not specific to HTML or
> even a web browser. They can be, and are, used anywhere.  32-bit Windows
> uses URIs everywhere.

I presume it uses some extended, enhanced, improved, Windows-friendly
URI syntax anyway. The purpose of the general URI specification is
to define something interoperable. Any particular system that uses
them internally can of course add extensions for use within that system.

> I wouldn't discount the idea because some browsers don't support it.  If we
> said that every time something new came up then we would be in terrible
> shape.

That's not the point. The point is that extensions should be made
so that they downgrade gracefully if possible. Of course this has
sometimes a high price.

>  I still would like to know which browsers supposedly break on the
> extended mailto URIs.  I haven't found any on Windows that break, so far.  I
> have just about every browser that can run on Windows.

I just tested on two browsers that seem to still be useable on
Unix systems here, X Mosaic 2.7b4 and Netscape 1 something. When
following a link with HREF="mailto:address?Subject=something",
they invoke a mail user agent putting address?Subject=something
into the To: field. I think you know what happens then. 

Archaic browsers? Perhaps. (I remember the time when most people
seemed to identify Mosaic with the Web. :-)) I have seen people
report that the ?Subject thing breaks on new browsers as well
when configured to use an external E-mail program.

The point is that just taking what follows mailto: and giving it
to an internal or external routine for simply sending mail to
that address is what one can _expect_ browsers to do, on the
basis of how RFC 1738 defines mailto: URLs. Nota bene:

   The mailto URL scheme is used to designate the Internet mailing
   address of an individual or service. No additional information other
   than an Internet mailing address is present or implied.
   - -
   Unlike many URLs, the mailto scheme does not represent a data object
   to be accessed directly; there is no sense in which it designates an
   object.

If the syntax is radically changed according to the proposal, browsers
would be forced to parse the entire mailto: URI and invoke a mail
user agent in a more complicated manner - or one could use only
such mail user agents which can accept data in the new URI format.
This is _restrictive_ instead of adding functionality.

Most fundamentally, a mailto URI with something like ?Subject
is radically different from the original mailto URL concept which
denotes a specific _resource_, an Internet mailing address.
The URL mailto:Jukka.Korpela@hut.fi specifies such an address or,
if you prefer a more concrete wording, my incoming mailbox.
Irrespective of details in syntax, anything like
mailto:Jukka.Korpela@hut.fi?Subject=hello
is something different. The subject is not a property of my mailbox.
Instead, that new syntax would refer to a _message_ with yet-unspecified
content but with subject line set (at least by default) to "hello"
and to be sent to my address.

Essentially different things need different schemes. The mailto:
URL as referring simply and definitely to an E-mail _address_ is useful
(although of course less useful than many Web authors think).
It should be left in piece. If desired, a new scheme like message:
or msg: could be defined for (partially on entirely prefilled)
E-mail _messages_. And there would be no law against browsers
having error recovery which internally converts
mailto:address?somedata to msg:address?somedata
(for symmetry, one might have the recipient specified in the msg:
syntax in To=address).

In HTML, there would be little need for such URIs, since in HTML
one can use _forms_ much more effectively and in a manner which
works fine on virtually all browsers. 

Yucca, http://www.hut.fi/u/jkorpela/ or http://yucca.hut.fi/yucca.html
Received on Thursday, 9 July 1998 02:31:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:37 GMT