Browse Prior Art Database

Tentative proposal for a Unified User Level Protocol (RFC0451)

IP.com Disclosure Number: IPCOM000003605D
Original Publication Date: 1973-Feb-22
Included in the Prior Art Database: 2000-Sep-13
Document File: 3 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

M.A. Padlipsky: AUTHOR

Abstract

Now that proposals for expansions to the Telnet Protocol are in vogue again (RFC's 426 and 435, for example), I'd like to promote some discussion of a particular favorite of my own. Please note that this is presented as a tentative proposal: it's an attempt to consider the desirability of a new approach, not a rigorous specification. To begin somewhat obliquely, for some time I've felt that we (the NWG) have fallen into a trap in regard to the Initial Connection Protocol. The point is that even though the ICP gives us the ability to define a "family" of ICPlets by varying the contact socket, there's no compelling reason why we should do so. That we have done so in the FTP and RJEP I view as unfortunate--but also undesirable and unnecessary.

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

Network Working Group M.A. Padlipsky

Request for Comments # 451 MIT-Multics

NIC # 14135 February 22, 1973

Tentative Proposal for a Unified User Level Protocol

Now that proposals for expansions to the Telnet Protocol are in vogue

again (RFC's 426 and 435, for example), I'd like to promote some

discussion of a particular favorite of my own. Please note that this is

presented as a tentative proposal: it's an attempt to consider the

desirability of a new approach, not a rigorous specification. To begin

somewhat obliquely, for some time I've felt that we (the NWG) have

fallen into a trap in regard to the Initial Connection Protocol. The

point is that even though the ICP gives us the ability to define a

"family" of ICPlets by varying the contact socket, there's no compelling

reason why we should do so. That we have done so in the FTP and RJEP I

view as unfortunate--but also undesirable and unnecessary.

To take the "undesirable" aspects first, consider the following: If we

continue to define a new contact socket for every new "user level"

protocol we come up with, we'll continue to need another new mechanism

(process, procedure, or patch) to respond to requests for connection for

each new protocol. By Occam's Razor (or the principle of economy of

mechanism, if you prefer), this is a bad thing. Irrespective of the

relative difficulty of implementing such mechanisms on the various

Hosts, to implement them at all leads to a kind of conceptual clutter.

Further, a different kind of confusion is introduced by the notion which

some of our number seem to be entertaining, that the "later" user level

protocols such as FTP are somehow still another level of abstraction up

from Telnet. So it seems to me that we could spare ourselves a lot of

bother, both practical and theoretical, if we could avoid spawning

contact sockets needlessly.

Turning to the "unnecessary" aspects, I think that even if the case

against the current approach isn't completely convincing the case for a

particular alternative might be. So to show that the multiple contact

socket ICP is unnecessary, I'll try to show that what I call the

"unified user level protocol" (UULP) is better. The first thing to

notice is that all the "later" protocols "speak Telnet". This is

sensible: Telnet works, by and large. Why not make use of it? Right.

But why not make even more use of it? In view of the fact that FTP,

RJEP, and even the initiating part of the Network Graphics Protocol, are

really just ways of letting a user say to a Server "I don't know what

you call it on your system, but please perform the whatever func...