First draft of Site Admin's Document

[[e-mail]]

Hi All,
	Well, it's about time that IAFA got some work done :-)

As promised here is the first draft of the Site Administrators document
that Peter and myself have put together. It is quite rough in many places
(the first two parts especially), but I wanted to get something out to
the list ASAP in order to start the discussion. Don't worry too much
about spelling and order (we didn't :-). This is just the foundation for
the discussion phase. We would like to have the first "official" draft by
mid-March in time for IETF San Diego. 

The first couple of sections deal with standard anonmous FTP archive (AFA)
stuff: setting one up and general pointers to its maintenance. The "main"
part of the document is the additional information that we would like to
see AFA's publish. As mentioned in the document, we realize that this is
a far from ideal solution to the problem, however it looks as if it is
the only thing we'll have to work with for the next couple of years until
some form of standard is put into place and deployed. We think it is a
workable solution until such time.

The document is currently 14 pages so I've formatted it for
printing for those who want to. Cut at the dotted line and ship it off. 

Here we go....enjoy

-Alan


----8<--------8<--------8<--------8<--------8<--------8<--------8<--------8<
Feb  9 23:53 1992  draft.1 Page 1


DRAFT                 IAFA-WG                 Guide to FTP Site Administration

Introduction

As the growth of the Internet continues it is now fair to speak of an
"Internet infostructure". Companion to the extensive physical
infrastructure that is itself responsible for the specific routing and
delivery of messages, the Internet infostructure is comprised of that
growing body of information and the structure that holds it now available
to users of the net. Much of this infostructure is available equally to
all users. Other portions are available to anyone participating in
specific network-based workgroups. The Internet acts as an enabling
technology that makes available this wealth of information to those who
know how to access it.

In this document we concentrate on the remote file transfer model
for sharing information in an Internet environment. On the
Internet, this model is primarily implemented using the File
Transfer Protocol (FTP) [1]. Available at most
sites, an FTP service provides users with a secure and reliable
mechanism to copy specific files from one host to another across
the network.

In particular, we aim to provide information to anyone
contemplating setting up or maintaining an Internet information
archive using the facilities of FTP. A companion document will
cover the use and operation of FTP archives from the user's
perspective.

Users of FTP  normally must go through a login sequence when
connecting to a foreign host. They are then allowed to copy those
files to which they have been granted access permission. The login
sequence provides basic authentication and security in an open
systems environment with hundreds of thousands of interconnected
hosts and millions of users. The underlying FTP protocol provides
needed error checking and thus ensures reliability.


What is Anonymous FTP?

The basic FTP-based file sharing model has been extended throught the
creation of a network of universally accessible FTP archives sites.
Information at such sites is available to all users of the Internet,
without the usual authentication step using the convention of
"anonymous FTP".  Under this mechanism, site administrators make
available a collection of files to the Internet community by creating
a special "anonymous" user account. Normal authentication mechanisms
are disabled (hence the use of the term "anonymous") thus allowing
anyone who connects to such a site to copy information back to their
own host.

The use of anonymous FTP began as a convention among relatively few
sites on the Internet. Details on establishing and operating such an
archive and even the names of sites supporting this mechanism was
shared among users of the net through ad hoc methods. With the
continued growth of the Internet [2] such ad hoc methods







Feb  9 23:53 1992  draft.1 Page 2


are now seen to be inadequate.


Anonymous FTP indexing tools

It is expected that as the amount of information on the network grows,
such resource discovery tools will become increasingly more important.
The Internet Anonymous FTP Archive Working Group (IAFA-WG) has been
formed under the auspices of the Internet Engineering Task Force to
foster better utilization of the anonymous FTP archive mechanism for
sharing information on the Internet.

This guide is intended for current and potential archive
administrators and includes procedures for setting up a site and
guidelines for its operation. In addition, we include proposals for
using anonymous archives as the first step to "publishing"
information in the Internet enviroment are included.

Despite their success, anonymous FTP archives are not the ideal manner
for publishing information. They do however, have the advantage of being
relatively cheap and easy to establish and provide near universal
access to their contents. With proper attention by archive site
administrators, they provide a relatively simple way to distribute
information.



Organization of this document

This document is divided into four sections. Part I discusses
the reasons why an organisation might wish to establish an anonymous
FTP archive site. Specific issues, both technical and non-technical
are addressed to herp the site administrator determine if establishing
such an archive is appropriate for his or her site.

Part II describes the steps needed to set up and maintain an
anonymous FTP archive site. Specific examples for the most common
operating system environments are included.

Part III offers a set recommended information that a site may wish
to compile and make available to archive users. It is expected that
archive indexing tools would automatically gather and make
available this information to a wide audience. Although not
required, it is expected that providing such information would make
your archive a more useful resource.

At the heart of this section are specific recommendations that are
intended to provide a standardized means for sharing information
about the contents of a specific archive site. These
recommendations include information concerning services provided by
the institution, document abstracts, and information such as
administrative contacts, local Timezone and other site-specific
details.

Part IV contains a set of recommended encoding procedures for
the information outlined in Part III. These procedures allow the







Feb  9 23:53 1992  draft.1 Page 3


adminstrator to take into account site-specific issues, such as
whether a particular operating system offers the capability of
creating and using subdirectories, any limitations on filename
length or the inability to use specific characters in filenames.

Using these recommendations, it is assumed that automated tools
will be developed that can incorporate information about that
site into larger infostructures which enable the general public to
locate and access the information at the site in a timely and
efficient way.


Part I: What is an anonymous FTP archive and why set one up ?

Internet archives are repositories of information of common interest
to a group. For example, researchers sharing a common set of data
will often put the information in a central location so that it can
be accessed by all those in the group. How this access is performed
can vary, but on the Internet the FTP service and the associated
remote file sharing paradigm are often used.

The FTP service has been around since the early days of the
Internet. It has been a successful service, with over 40% of
current network traffic being used for this purpose [* ref *].

The basic FTP system is designed around a client/server model. Users
invoke the client to connect to the server process running on the
remote host. The server is responsible for verifying the authenticity
of the user and performing the operations requested by the user
through the client, enforcing the security and integrity of the host
system.  In ordinary FTP sessions one would log into an account on the
remote host from where one either wanted to retrieve the file or to
which the file (or files) were to be placed. Basic commands allow the
user to navigate through the remote file system and copy or delete
files. This form of access requires one to have the name and password
of the account on the remote system. 


Why set up an anonymous FTP archive ?

Site administrators set up anonymous ftp archives for any of
several reasons:

a) Sharing of useful information. Many sites contain data which their
owners would like to make publicly available.  Research papers, locally
produced software and datasets are some of the most common offerings.
An anonymous ftp archive allows you to make this information available
to a large audience that would not otherwise be able to easily access
it.

b) Caching and redundancy. Sites at the end of slow network links often
set up an AFA site to redistribute information obtained from other
sites so that the operation need not be repeated multiple times for
the same piece of information. Large software offerings such as X11 or
TeX which can total several hundred Megabytes are often prime
candidates for caching at the closer end of a slow network link.







Feb  9 23:53 1992  draft.1 Page 4



c) To raise a site's profile by providing a valuable network resource.
A useful large and well maintained archive site is a valuable resource
to the general Internet community. This can give the group providing
the archive higher visibility which in turn can call attention to
other work by that site.


Initially, most ftp archives resided on centrally controlled mainframe or
minicomputers. The huge growth in the number of workstations and PCs on
the Internet has led to the growth of a number of smaller, more
site-specific archives.  The current population of archives now offer
everything from small collections of specialized data to collections
consisting of hundreds or even thousands of Megabytes of information,
much of it shadowed or copied from other sites on the Internet.


Part II: Setting up and maintaining an anonymous ftp archive site.

Once it has been decided that an anonymous ftp account is to be created
it is up to the system administrator to configure the FTP server to allow
such access. How this is done exactly is operating system dependent and
may be as simple as creating a password entry with the appropriate
information for an FTP pseudo-user. In most modern systems, support for
the anonymous account is built into the FTP server program primarily to
enforce security. It is important to bear in mind that once the account
is enabled, by its very definition, _anyone_ on the network can access
the account. Examples for some common operating systems are given below:


UNIX

In most implementations of UNIX, the ftp server (ftpd) is launched from
inetd running as the super user (root). The anonymous facility is enabled
by adding an account for the user "ftp" to the password file. A typical
/etc/passwd enty would look like:

ftp::67:20:Anonymous FTP account:/home/ftp:/bin/true

Note that a) there is no entry in the second (password) field and b) that
the shell is listed as /bin/true so as to prevent access to the account
by telnet(1) or rlogin(1). The line

/bin/true

may have to be added to the file /etc/shells to allow /bin/true to be
used as a "shell". Most UNIX systems will have the ftp server perform a
chroot(2) call in order to enforce the confinement of the process to the
specified anonymous ftp home directory (in this case /home/ftp).

Subdirectories of the ftp home directory called "bin" and "etc" should be
created. root should own the home directory.

a) ~ftp/bin should have a copy of the ls(1) program with execute only
permissions to all and the directory should be not by writable by
anyony. Both should be owned by root.







Feb  9 23:53 1992  draft.1 Page 5



b) ~ftp/etc should be created with owner root and readonly permissions.
It can optionally contain a file called passwd with one entry of the form

ftp:*:67:20:Anonymous FTP account:/:/bin/true

Note in this case that the passwd field is "*" and the home directory is
listed as "/". A file called "group" can also be placed in this directory
with an entry for the ftp group conforming to the group(5) manual entry.

In systems with dynamic libraries (eg. SunOS 4.X), a copy of these
libraries and certain devices may need also to be created. Consult your
documentation.

[VMS]

[other OS?]

There are a few areas of potential problems from both the security and
administrative sides of running an anonymous ftp archive site which will
be mentioned here. If you are not sure of the capabilities of your server
it is a good idea to consult your system documentation or your software
vendor. Some of these problems can be solved by using one of the freely
distributable ftp servers now available.

Technical

a) The view of the filesystem that the ftp client has access to should be
restricted with only those files specifically intended to being
distributed actually visible. In the best case, this restriction should
be enforced at the lowest possible level, preferably by the operating
system itself. Application-level enforcement should be avoided. For
example, some ftp servers try to restrict the movement of the clients by
filtering pathname requests. This is a weaker enforcement of
access policies than those supplied by the operating system and alternate
servers which utilize OS support should be used in preference.

b) Many sites maintain "incoming" directories which allow the uploading
of information into the archive by the general public. These can be very
useful for the easy distribution of data. However, they can also be used
as a transfer point for files that should not be on your system.  Most
operating systems allow having a directory be world writable but not world
readable. If you really want to have one of these directories, it is a
good idea to configure them in this way to allow the site adminstrator to
examine and vet the data before it is made generally available.

c) Check the permissions and ownerships of the files in your archive.
Many administrators have adopted the practice of transferring ownership
of archive files to the ftp pseudo-user. The file permissions should then
be scrutinzed to make sure that individual files cannot now be modified
by that user (unless of course, that is specifically the intention). The
"ftp user" is anyone using the anonymous account. The replacement of
files with corrupted versions (viruses, trojan horses etc) has been known
to occur.

d) The anonymous ftp subtree of the file system is usually self







Feb  9 23:53 1992  draft.1 Page 6


contained. This means that references (UNIX symbolic links for example)
outside of this subtree will not be resolved and are thus inaccessible to
users of the system.

e) Care should be taking when naming or renaming files in archives. The
truism that names should be meaningful takes on a greater significance in
this environment since this is all that the remote user has to work with
when trying to discover the contents of the file without actually
retrieving it. If one is caching a file from another ftp site, renaming
is usually not recommended since the ability to determine if the two
files contain identical information can be lost. Additionally whitespace
an non printable characters (on operating systems which allow this) is
frowned apon since this can make the file inaccessible to the remote user.
Additionaly, characters such as '@', '!', '|', or "_" may not be available
or have special significance on remote systems and should be used with
caution.

f) Very large files should be split into smaller pieces when placed in
ftp archives. The retrieval of large files can be difficult on unreliable
or congested links since if a failure during transfer occurs, it is
usually not possible to restart from the point of failure and continue.
The entire transfer has to be restarted. This can be time consuming and
costly in terms of network bandwith. Currently, files of 500 - 600 K are
usually considered as the maximum desirable size. Files larger than this
should be split.


Non technical

a) Check the contents of the archive to make sure that the files stored
there can legally (and ethically) be obtained by the general public.
Information (progams, documents, datasets) which is freely distributable
or in the public domain should be the only information placed in an
anonymous ftp archive site. That information of unknown legal status
should not be made generally available until the question is resolved: do
not assume that because the information might have been retrieved from
another archive that it is supposed to be generally available. There have
been many instances in the past of proprietary information being unwitting
distributed by uninformed archive administrators. This could prove to be
an expensive mistake. Know what is in your archive.

b) It is wise to only obtain files for caching on your system from
"reputable" sites around the net. These are well known and are run in a
highly professional manner.

c) Many ftp servers allow the logging of operations requested by their
users. This logged information usually contains the names or IP addresses
of the hosts from which the client is logged on. In the past when there
were may users on a system, this information didn't say much about who
was doing what. However, in today's network environment where individual
computers have in fact become _personal_ computers, this information can
easily identify the actual user to a high degree of probability. It is
considered unethical behavior to release this logged information to
individuals or groups not directly associated with the maintenance of the
archive. Privacy rights have in many respects not been legally
defined for computer environments and as such it is up to each site







Feb  9 23:53 1992  draft.1 Page 7


administrator to see that priviledged information is not conciously or
inadvertently distributed.

d) Anonymous ftp site administrators should be aware that the storage of
pornographic material in their archives may cause problems of a legal or
(more likely) political nature. This is also true of other potentially
offensive material such as that related to weaponry or terrorism. There
are a number of cases where the network provider for sites carrying such
material has threatened termination of network access until the offending
files have been removed.


Part III: Useful Configuration and Contents Information

In this section we define a minimum recommeded set collection of
information that you could offer as the administrator of an archive
site. In doing so, you would extend the functionality of your
archive, as well as the functionality of indexing and resource
discovery tools that choose to pick up and redistribute this
information.

It is expected that this information will itself be made available
through the anonymous ftp archive mechanism. The specific encoding
method used will be site-specific and encoding methods for some of
the most popular computing environments are presented in Part IV.

Note that these recommendations do not mandate or require that any
particular piece of information be offered. Rather, they are
suggestions for a minimal subset of information that we believe
will make your archive a more useful resource to the Internet.


Site-Specific Configuration Information:

Your site could include a variety of description and configuration
information that would be of use to potential users of that
archive. These might include:

Description Information:

Site Overview:

	- A brief abstract listing the overall goals and aims of
	  the archive site administration. If your site is intended
	  to specialize in a particular type of information
	  (Examples might include software for a specific machine
	  type, on-line copies of a particular type of literature
	  or research papers and information in a particular branch
	  of science or engineering) you could indicate this.


Configuration Information:

Site configuration information could be included to help users
better understand your wishes on how and when to access your site.
This could include such information as:







Feb  9 23:53 1992  draft.1 Page 8



Access Information:

	- Text describing the access policies of this site. This
	  could include such information as preferred times of
	  usage, conventions or restrictions for uploading files
	  to this site etc.

Contact Information:

	- You might also wish to include the name of the
	  organisation or group administering the site.
	- The postal address of the site
	- The telphone number of the site


[* Suggestions welcome for additions to this list *]


Site-Specific Content Information:

The preceeding selection all pertain to access and utilization
policies for a site. You could also wish to make available a
selection of information about the actual contents of your archive
or even the services available from your organization or
institution. Thus, you could make available information on:

Services:
	- The archive should offer an overall directory of each the
	  various Internet services offered by the associated
	  organization's systems, along with corresponding contact
	  information. This directory could indicate whether the 
	  the parent organization offers such services as:

		- an on-line library catalogue,
		- interactive network tools
		
          or any other services you currently offer.


The existance of an entry in such a directory could also be used as
an indication that associated archive configuration entries existed
for such areas as abstracts of on-line documents, descriptions of
available software, or a list of publicly available electronic
mailing lists maintained at this site. In such cases you might wish
to include specific information on:

Abstracts:
	- The system could also include an outline of each textual
	  document contained in the archive. This might correspond
	  to the actual abstract for each technical report or other
	  paper served from this archive site but any textual
	  document offered could have a corresponding abstract made
	  available for it.

Packages:







Feb  9 23:53 1992  draft.1 Page 9


	- The system could also include an appropriate outline for
	  each of the program packages offered at this site. This
	  owuld correspond to the README file included with many
	  freely distributable software, but should definitely include
	  such information as:
		- what the program claims to do,
		- the orginal author,
		- current site where the package is being maintained,
		- current package maintainer,
		- and any special considerations or restrictions on
		  the package's use (GNU copyleft, hardware
		  restrictions, etc).

Mailing Lists:
	- The archive administrator might also wish to indicate
	  which publicly available mailing lists are maintained
	  by this organization or institution, along with
	  subscription information.


Complete File listing:

	Each archive might wish to include a recursive
	listing of all archive entries at this archive in format
	appropriate for that environment. Such listings, if
	properly maintained, reduce network traffic while
	simplifying the task of archive indexing services.


Part IV: Information Encoding for Specific Environments

In this section we offer recommended encoding methods for the
standard items of information listed in Part III. In many cases
these recommendations should be applicable to all environments.
Where this is not true standardized encodings are offered for
specific environments. 

We offer such a standardized format so that If such information _is_
to be offered, it is formatted in such a way that it can be utilized
by automated indexing and retrieval tools. The encoding methods
proposed were developed to be extensible, so that additional
information can be offered in a similar format, if the site
administrator so wishes.

Developing such recommendations offered several challenges. It is
hoped that the encoding conventions should be applicable to as wide a
variety of operating systems, file structures and encoding schemes as
possible. In addition, the globalization of the Internet requires
attention to constraints such as language in use at an archive site.


In addition, the encoding methods proposed must be easy to implement
and, for the moment, use existing methods of access and retrieval. 
We currently assume that the site language is English. Additional
formats for other languages may be proposed at a later date.








Feb  9 23:53 1992  draft.1 Page 10



An Encoding for UNIX Sytems:

All information encoded using this scheme should reside in a standard
configuration and content directory located at the root of the
anonymous ftp file tree. Specific items of information are to reside
in specific named files an directories.

Files should be made world readable and that size and last
modification dates [* times? *] can be obtained through the existing FTP
mechanism.

The specified encodings take one of three types. These are:
	- Free form text
	- semi-structure (in which specific fields are detailed
	  but their contents are free form)
	- structured

The encoding form for each entry is included in its description.


The advantages to this system are that this information need only be
constructed once with infrequent periodic updates as changes ocurr. Many
of these files may never change during the lifetime of the host as an
anonymous ftp site. They require no special programs or protocols to
construct: a text editor is all that is needed.

This document will propose a basic set of categories which will be
modified in the future as need dictates. 


Configuration directory

[* It seems to make sense to call the configuration directory CONFIG and
that it be placed in the file structure directly under ("the child of")
the directory in which the FTP client is located on login to the
anonymous ftp host

The following categories/filenames are in English

Categories marked with a '?' have questionably utility but are included
for consideration *]

Categories

1) Free format. The information in these files will be handled as one
large text string. No attempt will be made by automatic tools to extract
individual pieces of information from them.

(Information about the host itself)

POST:			The postal address of the site
PHONE:			The telphone number of the site (in international
			format)
ACCESS:			Text describing the access policies of this site.
			Information such as preferred times of usage,







Feb  9 23:53 1992  draft.1 Page 11


			conventions or restrictions for uploading
			files to this site etc. would be placed here.

DESCRIPT:		Contains text and keywords describing any
			field or area of specalization that the site
			subscribes to. For example, if the site was
			concerned with molecular biology a paragraph
			or two with that keyword and some further
			description would be in order. 

ORG:			Contains the name of the organisation or
			group administering the site.

			Example:
				School of Computer Science
			or
				McGill University


1) Semi-structured. These categories should have the specified fields,
but no formal syntax will be specified. 

The assumption shouldn't be made that the information contained in
these categories applies to the anonymous ftp host itself. Rather, the
group or organization may publish general information: the specific
information will be contained inside the file describing the category.
All files will be retrieved from each subdirectory. Attempts may be
made to parse the information within each file.

MAILLIST (subdirectory)
------------------------

A file for each mailing list maintained by that
site, group or organisation. The file should be the name of the list if
possible. It contains the following fields:

NAME
ADDRESS
ADMIN
DESCRIPTION
KEYWORDS

Each field name is followed by the appropriate information, each field
starting on a new line.

NAME        The name of the list. 
ADDRESS     The address (in RFC 822 format) that mail intended for this
            list should be sent to.
ADMIN       The address (in RFC 822 format) of the administrative
            contact for the list. It is to this address that additions and
            deletions to the list should be directed. 
DESCRIPTION A description of the purpose of the list. Any special
            conditions for the list should be included.
KEYWORDS    Keywords useful for anyone looking for the list









Feb  9 23:53 1992  draft.1 Page 12


PACKAGES (subdirectory)
[* Two proposals *]
[Package to be taken to mean program (suite), dataset, document etc]

a) A file for each package on the anonymous archive that that archive is
responsible for (either by authorship or maintenance). There is a concept
that many packages have a "home" base from which the latest copy can be
obtained: in some sense the site is "authoritative" for that package.

b) A file for each package on the anonymous archive. [* Of course some
sites won't do it for _every_ package, but some may want to choose some
packages that they would particularly like to "advertise" *].

[* In both cases the following fields apply *]

NAME        The name of the program
AUTHOR      The name of the individual or group which wrote/compiled ("put
	    together") the package. Email address should be included.
DESCRIPTION The description of the package.
KEYWORDS    Keywords useful for anyone looking for the package

[* For proposal (b):

STATUS	    One of either "original" or "copy" to determine if the anonymous
            site is "authoritative" for that package.

[* Or perhaps "MAINTAINED@" or "MAINTAINEDBY" *]

ABSTRACTS
A list of the abstracts of paper's available on the AFA

Fields are:

NAME        The name of the paper 
AUTHOR      The name of the individual or group which wrote
	    paper. Email address should be included.
DESCRIPTION The description of the paper.
KEYWORDS    Keywords useful for anyone looking for the package


SERVICES
A list of any special services the host provides. Examples include
systems like WAIS, Prospero, Gopher, the Geographic database, weather
servers etc.

Fields are:

NAME		The name of the service
ACCESS		Procedure to be followed in order to access the service
		(eg. telnet to a specific port number, special account
		etc)
DESCRIPTION	A description of the service.
KEYWORDS	Keywords for anyone looking for the service

3) Structured








Feb  9 23:53 1992  draft.1 Page 13


(Information about the Host)

TIMEZONE (signed numeric)
The signed numeric differenc of the site from UTC with
"-" signifying zones west and "+" meaning times east. Daylight savings
conventions are ignored since they can be resolved externally. Thus North
American Eastern Standard Time (EST) would be -5, France would be +1 etc.

EMAIL (alphanumeric string)
Contains the email address at which the site administrator can be reached
in RFC 822 standard. For example, a file containing

	[e-mail]

would be valid. Alternately,

	"Alan Emtage" <[e-mail]>

could be used.

LOCALE? (alpha string)
Contains the comma separated list of city, state (province etc), country
in which the site is located.

Example:

Montreal,Quebec,Canada

COORDS (string)
Contains the whitespace or comma separated latitude and longitude
in degrees, minutes (specified as degrees.minutes) of the host. The
number can be signed with "+" for points East and North, "-" for points
West and South. Alternately, the letters E or W after the latitude will
signify East or West; N or S signifying North or South on the longitude.

Example:

-23.45,+33.15

Would specify latitude 23 degrees, 45 minutes West, Logitude 33 degrees,
15 minutes North. This could also be specified as 

23.45E,33.15N

[* This isn't as strange as may first appear. The ability to display the
hosts location (on a map for example), may be of considerable use *]

(Information for the "infostructure")

CNAME (string)
The preferred name of the AFA. This must be a valid name resolvable under
the standard DNS protocol. Thus if the site administrators would prefer
you to use the name "ftp.foobar.net" instead of the primary name
"free.foobar.net", this information would be placed in this file.

UPFREQ (numeric)







Feb  9 23:53 1992  draft.1 Page 14


The frequency in days for which this site would like to be updated in the
infostructure. Sites that changed their information often would have a
shorter update time than those who didn't. Of course it would be more
desirable if the infostructure was current all the time. However at this
point, this just not a feasible proposal. Thus we can benefit from a clue
given by the site administrator, the person who has the greatest
knowledge in this area. An empty file could signify "no preference".

UPTIMES (alphanumeric) 
The preferred times between which the site would like the
infostructure update to be performed. The assumption of nightime (local)
updates may be incorrect for sites that run heavy nightime loads. The
file consists of the starting and ending times as two 4 digit numbers
separated by commas or whitespace. An optional "L" could follow the
second number separated by commas or whitespace. UTC would be the
default. Thus a file containing

0000 0500 L

would mean that the site would prefer to be updated between 0000 and 0500
local time. An empty file would signify "no preference". The use of "L"
would require that the TIMEZONE file be present to calculate the UTC
times.

(Contents of the host)

LISTING
A recursive file listing (ls -lR) of the anonymous ftp home directory.
[compressed using the UNIX compress(1) facility or equivalent is
desirable for reducing network load].

[* Other categories *]

[* Other Operating Systems *]


Bibliography

[1] RFC 959		Postel, J.B.; Reynolds, J.K. File Transfer
                        Protocol. 1985 October

[2] RFC1296		Lottor, M.  Internet Growth (1981-1991).  1992
                        January;