URL-like representation for non-Internet resources

Gopher/Web Maintenance (goph-mn@proper.com)
Fri, 18 Nov 1994 21:46:46 -0800

Message-Id: <aaf3386a1a021003a172@[165.227.40.39]>
Date: Fri, 18 Nov 1994 21:46:46 -0800
To: uri@bunyip.com
From: goph-mn@proper.com (Gopher/Web Maintenance)
Subject: URL-like representation for non-Internet resources

All the URLs in the recent draft of the URL spec are for resources that can
be retrieved from the Internet. This makes good sense, inasmuch as the
Introduction states:

"This document describes the syntax for a compact string representation for
a resource available via the Internet."

However, there are many resources that are reachable by an end-user's
computer that *not* reachable on the Internet. These resources have
definitive addresses, and thus might benefit from a URL-like treatment.

A few schemes that come to mind include
voicephone:
fax:
modem:
postal:
maplocation:
Many personal computers can use the types of links to make direct contact
with someone else. If my Web client supported it, for example, selecting
the link <voicephone:(415)488-0944> might launch my phone dialer and call
Mitra. Similarly, <postal:Mitra, P.O.Box 580, Forest Knolls, CA 94933, USA>
could launch my word processor, start up a letter, and fill in the
information in salutation.

A few years from now, many of the above (maybe even including "postal:")
could be reachable on the Internet, or at least as reachable to the same
percentage of today's Internet users who can reach "http:". Should we
standardize them now, or possibly wait for conflicting scheme names to
appear from different Web client creators?

These examples clearly are outside of the current scope of the URL document
because they are outside the current scope of the Internet. However,
standardizing these (and other) locator names and formats soon could make
user's lives better.

Thus, should the scope be expanded to encompass some non-Internet resources
that have reasonable addressing schemes, or should a parallel document be
started for these types of locators? Is it enough for now to hold some
non-Internet scheme names in the current URL document and have a subgroup
thrash out the syntax for each scheme?

--Paul Hoffman
--Proper Publishing