- From: Tim Berners-Lee <timbl@w3.org>
- Date: Mon, 1 Apr 2002 15:36:56 -0500
- To: "Paul Prescod" <paul@prescod.net>, <www-tag@w3.org>
----- 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