Date: Wed, 15 Dec 1993 23:18:43 +0500
From: dupuy@smarts.com (Alexander Dupuy)
Message-Id: <9312160418.AA21583@brainy.smarts.com>
To: uri@bunyip.com
Subject: and now for something completely different: using URLs for "boot-loading"
While most discussion of URLs has focused on Information Retrieval types of
applications, where a human is trying to get some information, and is
following some sort of pointer to a file resource, I have a rather different
application where I thought URLs might be useful, and I would be interested in
getting feedback from this list.
I start with an embedded system (based on VxWorks) that can be dynamically
extended. So you can develop mini-applications which run on top of this
system. This embedded system doesn't require a local filesystem, but it can
support TFTP, FTP and NFS access to files across the network.
A remote-execution service is built on this embedded system that allows you to
load programs into the memory of the system, and run them whenever you want.
The remote execution service is based on UDP, so it would be complicated to
send the program files via the service itself. It occurred to me that rather
than invent yet another ad-hoc file transfer protocol, I could use existing
ones and specify the access information with a URL. When a URL was received
by the remote execution service in a load command, it would get the file
specified and load it into memory.
I could of course develop some arbitrary specification for this information,
but if URLs fit the bill, and people are familiar with them, why not re-use
some software design (especially since I am already doing this for the file
transfer mechanisms)? URNs would probably only be used on hosts, not in the
execution protocol, since the added URN->URL lookup could be done as easily on
the host rather than the embedded system. I'm not sure that I would even use
URNs at all, but given the reference someone made to "the URN for Mosaic 2.0
for DECstations" perhaps they might be useful in some future Internet which
uses them to support software distribution.
So far, this seems (to me, at least) a reasonable use for URLs. But there are
some problems which come up when I look at the current URL specification in
Tim's URL Internet Draft.
First is that the only access method specified which I can use is FTP. The
URL I-D says, in regard to the FTP naming scheme, "A client may in practice
use local file access to retrieve objects which are available through more
efficient means such as local file open or NFS mounting, where this is
available and equivalent".
Unfortunately, given a host name and a valid anonymous FTP path, there is no
general algorithm for determining the necessary access path for NFS, since
anonymous FTP access usually takes place while chroot()ed to the home
directory of the userid "ftp". Since the ftp userid may be specified in
/etc/passwd on the source machine, or taken from YP, NIS+, HESIOD, or other
naming services, it is impossible to translate the path in an FTP URL into a
path relative to the true root of the system, which is needed for an NFS mount
to succeed.
If an FTP URL provides a username, then the FTP server presumably doesn't do a
chroot(), so the path name is more likely to be correct (although it still
might not be, if the server in question runs something other than Unix).
However, the username doesn't provide sufficient information to determine the
authorization tokens which may be needed to access the file; uid and gid
numbers in the case of Unix authentication, or a 48-digit hexadecimal private
key, in the case of DES authentication. This information could be encoded in
the password field, but doing so would make the URL unusable for FTP.
Regarding passwords, the section describing "Internet protocol parts" says
"provision of encoding a password after the user name, delimited by a colon,
could be made, but obviously is only useful when the password is public, so
that is also discouraged." I would beg to differ, since more and more vendors
provide software distribution via FTP, and many of them require passwords for
access. In fact, I would even go so far as to say that the FTP ACCT string
should be representable in an FTP URL. In the case of my remote execution
protocol, commands can be encrypted, so it isn't unreasonable to send
passwords across, and with privacy enhanced mail, it might not even be
unreasonable for them to send URLs with passwords embedded in mail documents.
Using FTP URLs for TFTP access is even more hopeless, since TFTP servers often
chroot() to a different directory than the one used for FTP anonymous access,
making it impossible to access any files offered by one service from the
other.
In summary, I suggest that two more naming schemes be provided, NFS and TFTP,
which would specify access to files through those respective protocols, using
syntax similar to that already defined for other Internet protocols, with the
changes that "userid : group @" may precede the hostname for NFS, to be
interpreted as decimal user and group ids for use in Unix-style NFS
authentication (if not specified, user and/or group would default to 0).
The FTP spec should also be extended to allow "user : passwd : acct @" to
precede the hostname, specifying the user, password and account strings for
use with USER, PASS, and ACCT FTP commands (if not specified, the standard
convention of USER=anonymous, PASS=mail-address, ACCT not specified, would be
used).
If there is any feeling on the list that these extensions might be useful, I
would be glad to write up the necessary changes to the draft document.
I realize that these extensions may not seem terribly useful to those working
in the Information Retrieval area. However, I feel that if URLs are supposed
to be truly universal, they should be usable anywhere that you want to embed
references to a resource, whether it's in a hypertext document, a BOOTP/DHCP
configuration file, or a dynamic boot-loading protocol packet.
@alex