Dismiss
There will be a system update on Friday, May 5th, 6 PM ET. You may experience a brief service interruption.
Browse Prior Art Database

Free file transfer (RFC0487)

IP.com Disclosure Number: IPCOM000003628D
Original Publication Date: 1973-Apr-06
Included in the Prior Art Database: 2000-Sep-13
Document File: 2 page(s) / 3K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.D. Bressler: AUTHOR

Abstract

In the past several months, many people have commented to me about their difficulty in transferring files. The hang up appears to be with systems that have some flavor of security, but on which the user has no access privileges. Specifically, the FTP server demands a user and password before it will grant any system access. The loophole which people have been using is the MAIL FILE facility, which is both limited in scope and intended for other purposes.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 100% of the total text.

Network Working Group Bob Bressler

Request for Comments #487 BBN

NIC #15065 6 April 1973

Free File Transfer

In the past several months, many people have commented to me about

their difficulty in transferring files. The hang up appears to be with

systems that have some flavor of security, but on which the user has no

access privileges. Specifically, the FTP server demands a user and

password before it will grant any system access. The loophole which

people have been using is the MAIL FILE facility, which is both limited

in scope and intended for other purposes.

A frequently used model for file protection is to define three

levels of user access: 1) only the user himself; 2) all users in a

group; 3) everyone. Up until now, "everyone" has meant anyone already

granted logon privileges. A new class is, perhaps, needed to cover

everyone, exclusive of whether or not they are logged on.

With all this in mind, I propose the following course of action:

If a user connects to an FTP server and makes a file request without

supplying a user name-password, the server should then examine the file

access parameters. If the file is listed as accessible to anyone, then

the transfer should be allowed to proceed.

This scheme can be implemented so as not to yield file creations

privileges - for example, store commands can be implemented via an

append mechanism. If I wanted a file sent to me I could create an empty

file with unlimited append access. I would then inform the foreign user

to store (append?) to that file.

The problem of accounting is somewhat more complex. Clearly,

storing a file in a user's directory can be charged to that user. When

retrieving a file from a general system directory, there is no "user"

specified, and overhead may have to be billed. The former case involved

both CPU time for transfer and secondary storage charges for storing the

new file. In the latter case, only CPU charges are involved, and these

may be sufficiently small to not cause a major problem.

BBN TENEX has agreed to modify their FTP server to allow general

access transfers as described above. Specific details for usage will be

available when installation is complete. I urge other systems to make

this service available, if only on an experimental basis. The success

of such an experiment will be judged by the reaction of the general user

community and the uses to which FTP is put.

NOTE: Bob Clements tells me that the BBN TENEX implementation will

probably require a user name of something like "FREE" or

"ANONYMOUS", but not require a password.

RB/jm

[ This RFC was put into machine readable form for entry ]

[ into the online RFC archives by Alex McKenzie with ]

[ support from GTE, formerly BBN Corp. 9/99 ]