Mailto misnamed not misdesigned (Was: Hyperlinks depend on GET (was: Re: REST and the Web))

----- Original Message -----
From: "Paul Prescod" <paul@prescod.net>
To: <www-tag@w3.org>
Sent: Saturday, March 30, 2002 3:04 AM
Subject: Re: Hyperlinks depend on GET (was: Re: REST and the Web)
[...]
> The mailto: URI as it currently exists breaks my model. That's too bad.
> Considering the rate of new URI adoptions on the Web there will never be
> another silly URI scheme like that again. Here's how I would have
> implemented mailto:


The mailto:  schema name was badly chosen, but the concept is
sound as originally defined.  It was intended simply to be a space
in which to put all the internet email addresses, which are called
mailboxes.  A mailbox is an abstract thing, related to email messages
by (for example)  To: From: and Cc: feilds but also used in many
other situations.  It also normally has a relationship with the social
entity
-- typically a person or group --which owns it.

The unfortunate choice of name "mailto", my fault,  has lead browser
designers to think that it specifies an action. It is supposed to specifiy
an address. A perfectly reasonable representation on a user's screen
would be a compilation of links to messages sent to or from that
address (which the user knows about) and also a represenattion
with photo, name, and so on, of the person with whom the  mailbox
is associated, and a button "compose mail to this person".

Software which launches an email composition window is
relatively boring -- but it is of course also the eaiest thing to do.

> The important thing I'm trying to get across is that you decide what to
> do based on the documents you are looking at, not the URI mechanism that
> happens to be used to glue them together. That's part of the "URIs are
> opaque" idea. What does it mean for XSL if the behaviour of the
> stylesheet is now dependent in part on what kind of URIs you use? Also,
> do we need to start being specific in our schemas to restrict explicitly
> to URIs that we know support GET?

[...examples of giving an XML cal]
> There is never a harm (other than a tiny performance hit) in doing a GET
> to ask the object what else can be done with it. I would be glad to
> design an XML encoding for NSF mount points. Then de-referencing an
> HTTP, FTP, file:/// or Gopher URI would give you the information you
> need to do the mount.

The disadvantage is that you have just lost your address space.  You have
lost
the ability to simply and unabiguously refer to an email address.
Instead, you have to dererence lots of tiny documents  just to compare two
email addresses for equality. (You may be looking at email offline!)

No, all email and net news revolves around the email address - let's give
it first class status in URI space. But as an address not an instruction,
as it always was supposed to be.  Nor does it represent a document, though.

> There is no forward path to mailto: URIs that also support jabber or AOL
> messenger or whatever. But XML representations are extensible and using
> content negotation even "stupid" representations can be "upgraded" to
> extensible ones. So as long as you do things my way you can always shove
> a little bit more metadata into the document referenced by the URI and
> make the system a little more intelligent and sophisticated. Plus, the
> cost for deploying new XML vocabularies is a tiny fraction of the cost
> for deploying new URI syntaxes and there are great fallback schemes we
> can use which are not generally available for URIs.

Is that why none of the links I keep to radio stations on the web last more
than
a few months?  They all point to files in some outdated format

> As I've shown, retrievable documents are not limiting. They are
> incredibly powerful, flexible and extensible. It is URIs that are
> limiting -- when you try to use them for expressing behaviour, rather
> than addressing.

Agreed.  "mailto"  does *not* express behaviour -- it just sounds as though
it does.

> They are, after all, just addresses. It's a little bit like looking at a
> phone number and figuring that it starts with 976 so the "appropriate
> thing to do" is ask the person on the other end what they are wearing.
> Let me suggest that it would be better to find out whether the number is
> ACTUALLY associated with a sex hotline based either on the context you
> found it in, or the information you get when you call it. The form of
> the phone number is irrelevant.

yes.

> I can only think of two widely deployed, important cases where I've seen
> many URIs that did not support GET. The mailto link is one.

The telnet: address is another.  These are parts of the Internet
architecture
whcih are not parts of the information space.  But they are important
concepts.
Telephone numbers are another.  These end points for example can
be represented but don't have a common state like a document.  But they
are important in the Internet architecture.

>The other is
> magical urn: URIs used primarily for XML namespaces. If something like
> RDDL ever gets deployed and becomes useful, people who use those
> non-resolvable URIs will wish they had just used http: URIs.

Agreed!

> We aren't
> at that point yet, so I guess we'll have to wait and see. (by the way, I
> was historically a big booster of urn: style URIs for namespaces)

Welcome back out of the cold!    ;-)

>  Paul Prescod

Tim

Received on Monday, 1 April 2002 15:37:05 UTC