Browse Prior Art Database

File Transfer and Error Recovery (RFC0133)

IP.com Disclosure Number: IPCOM000002152D
Original Publication Date: 1971-Apr-01
Included in the Prior Art Database: 2019-Feb-10
Document File: 4 page(s) / 5K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R.L. Sunberg: AUTHOR

Related Documents

10.17487/RFC0133: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Network Working Group R. L. Sunberg Request for Comments: 133 Harvard University NIC 6710 27 April 1971 [Categories C.4, C.5, C.6, D.4, D.7, D.7]

FILE TRANSFER AND ERROR RECOVERY

1 FILE TRANSFER PROTOCOL

1A Handshaking

I think that Mr Bhushan(RFC #114, NIC 5823) is not strict enough in his concept of a transaction sequence. Every transaction should prompt a response from its recipient (recall Kalin’s crates -- RFC #60, NIC 4762). Control should pass back and forth until the server terminates. The server _always_ gets the last word (more on error recovery later).

Some sample interchanges are given.

User Server Comments

<...> ==> Establish a connection <== <...> <I><...> ==> Identify self <== <+> Ok, ready

<R><...> ==> Retrieval request <== <rs> I’ve got your file <rr> ==> Send it <== <,><...> Here’s the first part <rr> ==> Got it <== <+> All done

<S><...> ==> Store request <== <rr> Ok, go ahead <#><...> ==> Here’s some protection stuff <== <rr> Ok <*><...> ==> Here’s the file <== <+> Got it. All done.

See section 2B, below, for examples of error recovery.

Sunberg [Page 1]

RFC 133 File Transfer and Error Recovery April 1971

1B Extensions to the file transfer protocol

The file transfer protocol needs a mechanism for accessing individual records of a file. This will be particularly useful when very large data bases appear on the network. The following definitions should be added to the protocol:

The store(S) and retrieve(R) requests have the data field format <key>, where <key> has the syntax:

<key>::=<devicename>RS<filename>US<keyname> | <filename>US<keyname>. -- -- --

The <pathname> syntax is changed to:

<pathname>::=<devicename> | <filename> | <pathname>RS<filename>. -- If a retrieve(R) request is given with a data field with <key> syntax rather than <pathname> syntax, then the returned data will consist of the record following the matching <key>. If a store(S) request is given with a data field of <key> syntax, then the supplied data will replace the record following the matching <keyname>. If the keyname does not exist, the record will be appended to the named file. The individual installation must provide the linkage between the <keyname> and the record it references.

In addition, the lookup(L) request will provide a list of keynames into a file (or the name of a file which contains the keynames).

Transaction code F (request File directory) requests a listing of available files. The data field of the F transaction is of the form: <pathname>GS<pathname>GS... All files in the server system -- -- which match one or more of the given <pathname> specifiers are listed in a return file. The format of the data fields of this file is: <pathname>GS<pathname>GS... If a <pathname> field in -- -- the request transaction does not include a <name> field, the default is all files on the given device. Some examples are given:

<F><DC1 DSK[62,50]] GS JOE> --- --

Sunberg [Page 2]

RFC 133 File Transfer and Error Recovery April 1971

This example requests a list...

Processing...
Loading...