- From: Jukka Korpela <jkorpela@cc.hut.fi>
- Date: Thu, 9 Jul 1998 09:31:48 +0300 (EET DST)
- To: www-html@w3.org
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 UTC