Message-Id: <32ACC075.5E15@w3.org> Date: Mon, 09 Dec 1996 20:45:05 -0500 From: Tim Berners-Lee <firstname.lastname@example.org> To: Larry Masinter <email@example.com> Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, email@example.com, Subject: Re: revised mailto spec Larry Masinter wrote: > > Tim should read the spec before reacting to it. I have, thank you. We were talking about the same spec. > It proposes that > 'mailto:' be extended to allow the URL to specify more 'default' > entries for headers. Clearly part of the 'security considerations' are > that any client that implements this must be aware of -- and deal with > -- all of the various security threats that might arise. My problem is not with the function, but with the semantics. I tried to express this last time. What do you get when you dereference "mailto:" ? I think that you get a orginator/recipient. That was my intent originally anyway. You don't get "the result of sending a mail to this address". It is true that, given a mail address, a very likely operation on it will be to mail to it. But I believe a mail address is a sort of object. I'd like, as I said, when following a mailto: link, to get a not just the option of mailing to the address, but also anything else known about it on my machine. (When it maps into desktop/http terminology, it would accept drag&drop/POST.) The crucial part of the spec appears early on: "The mailto URL scheme is used to designate the Internet mailing address of an individual or service, or an Internet resource that can only be reached via electronic mail." I belive the world will be confused by regarding a mail address and a resource retrievd through mail as the same thing. (Analogy: You write Phone: +1-617-253-5702 but Fax: +1-617-258-5999 because, when derefereced, you get in one case a channel to a natural language audio channel, and in the other case a CCITT facsimilie service. They behave totally differenetly. Architecturally, a fax address is quite like a mail address, but a telephone is more like a TV channel. This muddling proposal is like replacing Fax:+1-617-258-5999 with Phone:+1-617-258-5999?say="wheeeeeoooooo";f=2.4kHz if that helps explain my point) We should not be put off by the fact that the "mailserver:" way of getting a document, and the interaction of a normal email service or person both use SMTP. Nor should we try to sneak the mailserver: address space (with its implied protocols, implications on caching, etc etc etc) into a good spec which makes the well-defined, time-proven staple-of-the-internet email address a class of URL. Dan LaLiberte argues the opposing idea to its limit, I think, that a human response and an automatically generated response will have to be monitored in the same way. However, at Web architecure level the mailserver action is fundamentally (if you don't look under the hood) a GET, and the mailto: action is basially a POST, and that any apparent similarity follows from the fact that the mailserver GET is [currently] not very well hidden. I am not speaking against "mailserver:" as a separate space. I propose it be developed as a separate spec. > Larry Tim ____________________________ With w3c director hat off.