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.

Received on Monday, 9 December 1996 20:47:16 UTC