Browse Prior Art Database

Proposed Host-Front End Protocol (RFC0929) Disclosure Number: IPCOM000004342D
Original Publication Date: 1984-Dec-01
Included in the Prior Art Database: 2000-Oct-10

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Lilienkamp: AUTHOR [+2]


Status Of This Memo

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

Network Working Group Joel Lilienkamp (SDC)

Request for Comments: 929 Richard Mandell (SDC)

Michael Padlipsky (Mitre Corp.)

December 1984


Status Of This Memo

The reader should be aware of several things in regard to what the

present document is up to. First and foremost, IT IS A PROPOSAL FOR

A STANDARD, NOT A STANDARD ITSELF. Next, it assumes that the

separate document, RFC 928, which is an introduction to the present

document, has been read before it is. Next, it should be understood

that "final cut" over this version of the document has been exercised

by the author of RFC 928, not by the primary author of the present

document, so any readers bothered by style considerations should feel

free to blame the former, who's used to it, rather than the latter,

who may well be guiltless. (Editing at a distance finally become too

hard to manage, so if I'm typing it myself I'm going to fiddle with

it myself too, including, but not limited to, sticking my own section

on the Conceptual Model in before Joel's words start, rather than

leaving it in the Introduction. MAP)

Finally, it should be noted that this is not a finished document.

That is, the intent is eventually to supply appendices for all of the

protocol offloadings, describing their uses of protocol idiosyncratic

parameters and even their interpretations of the standard per-command

parameters, but in order to get what we've got into circulation we

haven't waited until all such appendices have been written up. (We

do have notes on how to handle FTP, e.g., and UDP will be pretty

straightforward, but getting them ready would have delayed things

into still another calendar year, which would have been very annoying

... not to say embarrassing.) For that matter, it's not even a

finished document with respect to what is here. Not only is it our

stated intention to revise the protocol based upon implementation

experience gained from volunteer test implementations, but it's also

the case that it hasn't proven feasible to iron out all known

wrinkles in what is being presented. For example, the response codes

almost certainly need clarification and expansion, and at least one

of us doesn't think mandatory initial parameters need control flags.

However, to try too hard for polish would be to stay in subcommittee

for the better part of forever, so what you see is what we've got,

but certainly isn't meant to be what you or we are stuck...