• Aucun résultat trouvé

aspects first, consider the following: If we continue to define a new contact socket for every new "user level&#34


Academic year: 2022

Partager "aspects first, consider the following: If we continue to define a new contact socket for every new "user level&#34"

En savoir plus ( Page)

Texte intégral


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 function (push or pull a file, start or stop a batch job, funnel some of my

output through the Network Virtual Graphics Terminal module) for me now,

Padlipsky [Page 1]


RFC 451 Unified User Level Protocol Proposal February 1973

why not simply put hooks in Telnet to indicate that a Network Generic Function is wanted instead of a Host-specific one at a given point in time? Then everybody can come in through Telnet in ways that are

already known (and usually debugged and optimized) and fan out to other services through a single mechanism, where that single mechanism can be whatever is most appropriate to a particular Host. This view has the additional virtue of keeping the Host "Answering Service"-equivalent processes out of the act when new protocols come along -- where by Answering Service, I mean that process which manages logins in general for a given Host. This process is, of course, a particularly sensitive one on those systems which worry about accounting and security.

That’s all probably a bit vague. Perhaps some idea of how I think the UULP would work will cast some light on what I think it is. What’s needed is a way of letting the Server know that it’s being given a

generic command (I decline to call it a Network Virtual command, but I’m afraid that might be what I mean) like "STOR" or "RETR" rather than a local command like "who" or "sys". What could be simpler than defining a Telnet Control Code (TCC) for "Network Generic Function Follows"? So if the Server Telnet receives a command line beginning with the NGF TCC (say, 277 octal), it just feeds the line to the appropriate process or procedure (depending on the structure of its operating system). This approach also offers a handy way of communicating back the fact that a particular protocol or piece thereof isn’t available: define a TCC for

"Unimplemented Generic Function". This feels a lot cleaner than having a close on socket 3 mean anything from "no FTP Server exists here" to

"the FTP Server happens to be busy."

Notice that the UULP automatically provides the answer to such objections as the one Braden raises in RFC 430, that "there is no mechanism within the FTP for _changing_ a password. A user shouldn’t have to use a different protocol ... to merely change his password".

With the UULP, any system which has a password changing ability would have it available for all user level protocols because all of its abilities are made available by the generic login. This seems clearly superior to having to retrofit afterthought after afterthought to the various user level protocols as we come to realize that life is more convenient when we get away from the view that each protocol lives in its own island universe. I understand that one of the main motivations for going the multiple contact socket route was to avoid syntactic (and semantic) conflicts between the protocol and the particular Host’s

"normal" command processor; however, locking ourselves in to special command processors exclusively is awfully procrustean. So instead of cutting off the limbs to fit the bed, why not use the UULP to expand the bed.

Padlipsky [Page 2]


RFC 451 Unified User Level Protocol Proposal February 1973

Although this is a tentative proposal and not meant to be a detailed design spec, one elaboration suggests itself which might make the general idea more attractive: For ease of implementation on some

systems, it would probably be a good idea to define additional TCC’s for

"Begin User Protocol". That is, the user side starts the FTP by sending the "Begin FTP" Telnet Control Code, waits for the Server to send either the same code or the one for "Unimplemented Generic Function", and then proceeds (or not) to send STOR’s and RETR’s and the like. (It could also follow the "I will"/"I won’t" style discipline of RFC 435 if we like.) Probably each line is preceded by the Network Generic Function TCC so that systems which don’t pass input off to some other process can still distinguish between input to the system command processor and input to the procedure(s) which perform(s) the protocol in question, although perhaps it would be preferable to have an "End Protocol" TCC.

Now, I’m the first to admit that what makes sense to me, on my system, may not make sense on somebody else’s. But it does seem plausible to me that the unified user level protocol I’ve sketched here ought to be no harder to implement than the multiple contact socket (MCS) ICP is. And the advantages of the UULP over the MCS ICP in terms of ease of

extension and (at least in my mind, if not in this paper) clarity make it seem worthwhile to consider further. So rather than try to refine it here, let me simply ask for comments both on the general notion and on the necessary iteration of the design from sketch to spec. (The Multics scenario in ICCC booklet shows how to get "mail" to me, for those who don’t feel like RFCing or phoning.)

[ 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 ]

Padlipsky [Page 3]


Documents relatifs



Genera supports soft deletion (when the filesystem is capable of that), so Delete File only marks the file as deleted, it does not irretrievably remove talk it.. time The Status

As is the case with earlier Series "D" releases, existing UNIVAC equipment is being offered in specific configurations at prices substantially reduced


It is plain that we are not only acquaintcd with the complex " Self-acquainted-with-A," but we also know the proposition "I am acquainted with A." Now here the

Vortex collision and energy dissipation rates in the Ginzburg-Landau heat flow, part I: Study of the perturbed Ginzburg-Landau equation. Vortex collision and energy dissipation rates

To make the service more reliable, the mid-level network could have at least one nameserver that is able to resolve nameserver queries for all domains directly connected to

A mechanism is needed to allow the sender to transmit this sort of presentational information to the recipient; the Content-Disposition header provides this mechanism,

(In contrast to MIME content-type parameters, which are defined on a per-content- type basis.) Thus, for example, the ‘filename’ parameter still means the name of the file

a) It allows an abstract interface for the Call Agent so that for example, the same incoming call-setup event can be used in the case of MF wink start and MF immediate

disassociation with the arpa domain and its understanding the domain would be used by the Internet Corporation for Assigned Names (ICANN) and Numbers and the Internet

Performing even a user-level privacy function in a privacy service could be useful, for example, when a user is sending messages from a legacy client that does support

This document more clearly distinguishes telephone numbers as identifiers of network termination points from dial strings and removes the latter from the purview of

an initial connection protocol which specifies how a user program connects to the server program, and.. a command protocol which specifies how the user process talks to

This document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over

The date/time information is extracted from the header, shifted to the specified time zone, and the value of the given date-part is determined.. The test returns true if

However, it should be possible to send a paper tape to a disk file, or vice versa, with the transfer looking like a paged file; so perhaps we are dealing with a data

This document creates and populates such a registry, thereby changing the mechanism defined in RFC 2648 for adding new sub-.. namespaces

Because the service is UUS1 implicit for the ISDN User-to-User service, the inclusion of the "uui" option tag in a Supported header field conveys no additional

If no loop is found, the DDT client saves the prefix returned in the Map-Referral message in the referral cache, updates the saved prefix and saved RLOCs in the

The Web Push protocol [RFC8030] describes how an application server is able to request that a push service deliver a push message to a user agent.. As a consequence of

Central will never send Channel Abort message on this channel; if the remote site closes its socket (socket b), Central will not re-transmit, but simply cease sending messages