home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / e / id-tko-01.txt < prev    next >
Text File  |  2020-01-01  |  18KB  |  476 lines
  1. Internet Engineering Task Force                        Jeffrey E. Altman
  2. INTERNET-DRAFT                                             Frank da Cruz
  3. <draft-altman-telnet-kermit-server-01.txt>           Columbia University
  4.                                                          18 January 1999
  5.                                                    Expires: 23 July 1999
  6.  
  7.  
  8.                           TELNET KERMIT OPTION
  9.  
  10.                                 DRAFT 01
  11.  
  12. STATUS OF THIS MEMO
  13.  
  14. This document is an Internet-Draft.  Internet-Drafts are working
  15. documents of the Internet Engineering Task Force (IETF), its areas, and
  16. its working groups.  Note that other groups may also distribute working
  17. documents as Internet-Drafts.
  18.  
  19. Internet-Drafts are draft documents valid for a maximum of six months
  20. and may be updated, replaced, or obsoleted by other documents at any
  21. time.  It is inappropriate to use Internet-Drafts as reference material
  22. or to cite them other than as "work in progress".
  23.  
  24. To view the entire list of current Internet-Drafts, please check the
  25. "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  26. Directories on ftp.is.ca.za (Africa), ftp.nordu.net (Northern Europe),
  27. ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
  28. ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
  29.  
  30.  
  31. ABSTRACT
  32.  
  33. This memo proposes an optional extension to the Telnet protocol to allow
  34. the negotiation, coordination, and use of the Kermit file transfer and
  35. management protocol over an existing Telnet protocol connection.
  36.  
  37.  
  38. CONTENTS
  39.  
  40.   1. INTRODUCTION
  41.   2. DEFINITIONS
  42.   3. TELNET KERMIT OPTION
  43.   4. KERMIT PROTOCOL IMPLICATIONS
  44.   5. EXAMPLES
  45.   5.1. EXAMPLE 1
  46.   5.2. EXAMPLE 2
  47.   5.3. EXAMPLE 3
  48.   5.4. EXAMPLE 4
  49.   5.5. EXAMPLE 5
  50.   6. SECURITY
  51.   7. REFERENCES
  52.   8. AUTHORS' ADDRESS
  53.  
  54.  
  55. 1. INTRODUCTION
  56.  
  57. The Kermit protocol [KER] performs error-corrected file transfer and
  58. management over many types of connections, including terminal
  59. connections, among diverse hardware and software platforms.  It is
  60. supported by a large number of Telnet clients and is also widely
  61. available on the Internet hosts to which Telnet connections are made.
  62.  
  63. Traditionally, the Kermit protocol connection is started manually by a
  64. user, or perhaps by an automated script.  It is the user's
  65. responsibility to start the Kermit server on one end of the connection
  66. and the Kermit client on the other, or to start a Kermit "send"
  67. operation on one end and a Kermit "receive" on the other.
  68.  
  69. This procedure grew out of necessity on ordinary direct-dial
  70. connections, and serves its purpose within the limitations of that
  71. context.  But it introduces timing and dexterity problems, and lacks an
  72. effective way for each Kermit program to determine the "mode" of the
  73. other, or even its very presence, and therefore to know with certainty
  74. which operations and procedures are legal on the connection at any given
  75. time.
  76.  
  77. When Kermit services are offered on the Internet, however, a strong
  78. coupling can be established between the two end applications by having
  79. the Telnet protocol [TEL] serve as a supervisor for Kermit sessions,
  80. ensuring that a valid and known relationship is always obtained.  Kermit
  81. sessions are, in effect, embedded within Telnet sessions, with Telnet
  82. providing the mechanism for starting and stopping them and defining
  83. which end is the Kermit client and which is the Kermit server, possibly
  84. changing the relationship in response to user actions.
  85.  
  86. Kermit clients and servers that implement the Telnet Kermit Option can
  87. form the basis of a new Internet Kermit Service, described in a separate
  88. Internet Draft [IKS].
  89.  
  90. This draft assumes knowledge of Transmission Control Protocol, the
  91. Telnet Protocol [TEL], and the Kermit File Transfer Protocol [KER].
  92.  
  93. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  94. "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  95. document are to be interpreted as described in RFC 2119 [BCP].
  96.  
  97. 2. DEFINITIONS
  98.  
  99. Kermit server
  100.   A software program that is ready to accept and act upon commands in
  101.   the form of well-defined Kermit packets [KER].
  102.  
  103. Kermit client
  104.   A software program that receives requests through its user interface
  105.   from a human agent (or a script or other source) and translates them to
  106.   command packets, which it sends to a Kermit server, thus initiating a
  107.   Kermit protocol transaction such as the transfer of one or more files.
  108.  
  109. Availability of Kermit server
  110.   For the purposes of this document, a Kermit server is said to be
  111.   available if, through the negotiations described herein, its Telnet
  112.   partner knows that it is a Kermit server.
  113.  
  114.  
  115. 3. TELNET KERMIT OPTION
  116.  
  117. Support for a Kermit server is negotiated separately in each direction,
  118. allowing Kermit service to be embedded in the Telnet client, the Telnet
  119. server, or in both.  The proposed Telnet extensions are, therefore,
  120. symmetrical.
  121.  
  122. When the connection is first opened, Kermit service is unavailable in
  123. both directions.
  124.  
  125. The availability of Kermit service is negotiated using the following
  126. Telnet option:
  127.  
  128.   KERMIT           47 (assigned by IANA)
  129.  
  130. The state of the connection is controlled by the following Telnet
  131. subnegotiation function codes:
  132.  
  133.   START-SERVER      0
  134.   STOP-SERVER       1
  135.   REQ-START-SERVER  2
  136.   REQ-STOP-SERVER   3
  137.   SOP               4
  138.   RESP-START-SERVER 8
  139.   RESP-STOP-SERVER  9
  140.  
  141. The KERMIT OPTION is negotiated using the standard Telnet mechanisms:
  142.  
  143. IAC WILL KERMIT
  144.   The sender of this command incorporates a Kermit server and is willing
  145.   to negotiate its use.
  146.  
  147. IAC WONT KERMIT
  148.   The sender of this command does not incorporate a Kermit server or
  149.   refuses to negotiate its use.
  150.  
  151. IAC DO KERMIT
  152.   The sender of this command requests that the receiver negotiate use of
  153.   a Kermit server.
  154.  
  155. IAC DONT KERMIT
  156.   The sender of this command refuses to negotiate the use of a Kermit
  157.   server.
  158.  
  159. Once WILL KERMIT is negotiated in a particular direction, subnegotiations
  160. are used to indicate or request a change in state of the connection, or to
  161. convey other information.  Subnegotiations may be sent at any time.
  162.  
  163. IAC SB KERMIT START-SERVER
  164.   This command is sent by the WILL side to indicate that the Kermit
  165.   server is now active; that is, that client-initiated Kermit packets
  166.   will be accepted.
  167.  
  168. IAC SB KERMIT STOP-SERVER
  169.   This command is sent by the WILL side to indicate that the Kermit
  170.   server is no longer active, and therefore that it is not ready to
  171.   accept Kermit packets.
  172.  
  173. IAC SB KERMIT REQ-START-SERVER
  174.   This command is sent by the DO side to request that the Kermit server
  175.   be started.  It must be responded to with either RESP-START-SERVER
  176.   or RESP-STOP-SERVER depending upon whether or not the request was
  177.   accepted.
  178.  
  179. IAC SB KERMIT REQ-STOP-SERVER
  180.   This command is sent by the DO side to request that the Kermit server
  181.   be stopped.  It must be responded to with either RESP-START-SERVER
  182.   or RESP-STOP-SERVER depending upon whether or not the request was
  183.   accepted.
  184.  
  185. IAC SB KERMIT RESP-START-SERVER
  186.   This command is sent by the WILL side in response to REQ-START-SERVER
  187.   or REQ-STOP-SERVER to indicate that the Kermit server is active
  188.   after the request was accepted or denied.
  189.  
  190. IAC SB KERMIT RESP-STOP-SERVER
  191.   This command is sent by the WILL side in response to REQ-START-SERVER
  192.   or REQ-STOP-SERVER to indicate that the Kermit server is not active
  193.   after the request was accepted or denied.
  194.  
  195. IAC SB KERMIT SOP <octet>
  196.   Kermit Start Of Packet.  The sender of this command specifies the
  197.   octet it will use to mark the beginning of the Kermit packets it
  198.   sends.  This command must be sent by each connection partner upon the
  199.   first WILL/DO pair to allow unambigious identification of Kermit
  200.   packets in the data stream.  This subnegotiation must be sent whenever
  201.   the Start of Packet character changes.  The values are restricted to
  202.   ASCII C0 control characters other than Carriage Return and NUL.  The
  203.   normal value is 1 (ASCII SOH).  The two Kermit partners normally use
  204.   the same SOP, but may use distinct ones if desired.
  205.  
  206. IAC SB KERMIT SOP is necessary to allow each Telnet partner to recognize
  207. subsequent incoming Kermit packets.  Data following the SOP is processed
  208. by the Kermit packet analyzer.  All other Kermit protocol parameters are
  209. automatically negotiated within the Kermit protocol upon the initial
  210. exchange of Kermit packets [KER].
  211.  
  212. START-SERVER and STOP-SERVER commands must be sent by the WILL side
  213. whenever the state of the Kermit server changes.  When WILL is
  214. successfully negotiated the state of the WILL side is assumed to be
  215. STOP-SERVER.  If the server is active, the WILL side must send a 
  216. START-SERVER to indicate the change in state.
  217.  
  218. The receiver of a REQ-START-SERVER or REQ-STOP-SERVER is not required to
  219. agree to the request to change state.  The receiver must respond with
  220. either RESP-START-SERVER or RESP-STOP-SERVER to indicate the state of the 
  221. Kermit Server subsequent to the request.  RESP-xxx-SERVER is sent instead
  222. of xxx-SERVER to enable the sender of REQ-xxx-SERVER to distinguish 
  223. between the WILL side's spontaneous change in state and the response
  224. to the DO side's request.
  225.  
  226. If the Kermit server receives a Kermit packet commanding it to cease
  227. Kermit service (such as a FINISH, REMOTE EXIT or BYE packet [KER]), it
  228. must send IAC SB KERMIT STOP-SERVER if the command is accepted.
  229.  
  230. These rules ensure that the Telnet client's user interface always knows
  231. whether (and on which end) a Kermit server is available, and can
  232. therefore present the user only with valid choices, and that changes in
  233. state of one Telnet partner automatically switch the other to a
  234. complementary and valid state.
  235.  
  236. While it is possible for a traditional telnet service (port 23) to 
  237. implement this option while at the same time supporting the existing
  238. remote shell access functionality, it is not expected that this option
  239. will be used in that manner.  Instead, this option is primarily meant
  240. for use with dedicated Kermit services (port 1649) such as the 
  241. Internet Kermit Service [IKS].  
  242.  
  243.  
  244. 4. KERMIT PROTOCOL IMPLICATIONS
  245.  
  246. The Kermit protocol is described elsewhere [KER].  It is an extensible
  247. and self-configuring protocol, like Telnet, and thus any two proper
  248. Kermit implementations should interoperate automatically.
  249.  
  250. In Kermit, as in Telnet, one particular octet is distinguished.  In
  251. Telnet's case, it is IAC (decimal 255); in Kermit's it is the character
  252. specified by the IAC SB KERMIT SOP negotiation, normally SOH (decimal 1,
  253. Ctrl-A).  All Kermit packets must begin with the SOP and should not
  254. contain the SOP character in an unquoted form.
  255.  
  256. Telnet protocol takes precedence over Kermit protocol; whenever an IAC
  257. is detected, it is processed as the beginning of a Telnet command unless
  258. quoted by another IAC.  Telnet commands can contain any characters at
  259. all, including the SOP octet, transparently to the Kermit protocol, and
  260. in fact Telnet commands are not seen by the Kermit protocol at all.
  261.  
  262. Kermit protocol must follow Telnet NVT rules in each direction when
  263. Telnet binary mode is not negotiated for that direction.
  264.  
  265. If 8-bit transparency is desired, Telnet binary mode may be negotiated
  266. upon entry to Kermit protocol in the appropriate direction, and the
  267. previous mode (NVT or binary) restored upon exit from Kermit protocol.
  268. Telnet binary mode can result in more efficient transfers, but is not
  269. required for data transfer, since Kermit protocol does not require a
  270. transparent path.
  271.  
  272.  
  273. 5. EXAMPLES
  274.  
  275. 5.1. EXAMPLE 1
  276.  
  277. The Telnet server contains a Kermit server.  The Telnet client includes
  278. Kermit protocol but does not implement the Telnet KERMIT Option.
  279.  
  280.   Telnet Server                   Telnet Client
  281.   -----------------------------   -----------------------------
  282.   <starts negotiations>
  283.   WILL KERMIT
  284.   DO KERMIT
  285.                                   <responds to negotiations>
  286.                                   DONT KERMIT
  287.                                   WONT KERMIT
  288.  
  289. From this point, no subnegotiations take place, and the Kermit
  290. client/server relationship is under manual control of the user of the
  291. Telnet client.  This will be the case (for example) with existing
  292. Kermit-capable Telnet clients.
  293.  
  294. 5.2. EXAMPLE 2
  295.  
  296. The Telnet server contains a Kermit server and starts a Kermit server
  297. immediately after a connection is made.  The Telnet client does not
  298. offer a Kermit server.
  299.  
  300.   Telnet Server                   Telnet Client
  301.   -----------------------------   -----------------------------
  302.   <starts negotiations>
  303.   WILL KERMIT
  304.   DO KERMIT
  305.                                   <responds to negotiations>
  306.                                   DO KERMIT
  307.                                   SB KERMIT SOP <0x01>
  308.                                   WONT KERMIT
  309.   SB KERMIT SOP <0x01>
  310.  
  311.   <starts Kermit Server>
  312.   SB KERMIT START-SERVER
  313.  
  314. At this point the Telnet client knows that a Kermit server is on the
  315. other end of the connection, and so may customize its command set or
  316. menus to allow only those commands that are valid as a client of a
  317. Kermit server.
  318.  
  319. 5.3. EXAMPLE 3
  320.  
  321. Telnet server and Telnet client both contain a Kermit server.  Telnet
  322. client Kermit server is active whenever its terminal emulator is active,
  323. and not active at other times.  The Telnet server is used for shell
  324. access and does not start a Kermit Server unless requested.
  325.  
  326.   Telnet Server                 Telnet Client
  327.   ---------------------------   -----------------------------
  328.   <starts negotiations>
  329.   WILL KERMIT
  330.   DO KERMIT
  331.                                 <responds to negotiations>
  332.                                 DO KERMIT
  333.                                 SB KERMIT SOP <0x01>
  334.                                 WILL KERMIT
  335.   SB KERMIT SOP <0x01>
  336.                                 <telnet client enters terminal emulator>
  337.                                 SB KERMIT START-SERVER
  338.  
  339.                                 <client leaves terminal emulator>
  340.                                 SB KERMIT STOP-SERVER
  341.  
  342.                                 <client requests Kermit service>
  343.                                 SB KERMIT REQ-START-SERVER
  344.   <starts Kermit server>
  345.   SB KERMIT RESP-START-SERVER
  346.                                 <client sends Kermit FINISH packet>
  347.   <stops Kermit server>
  348.   SB KERMIT STOP-SERVER
  349.                                 <client returns to terminal emulator>
  350.                                 SB KERMIT START-SERVER
  351.  
  352.  
  353. 5.4. EXAMPLE 4
  354.  
  355. Telnet server and Telnet client both contain a Kermit server.  Telnet
  356. client's Kermit server is active whenever the terminal emulator is
  357. active.  Telnet server is used solely for Kermit protocol and
  358. automatically starts a Kermit Server upon accepting the connection.
  359.  
  360.   Telnet Server                 Telnet Client
  361.   ---------------------------   -----------------------------
  362.   <starts negotiations>
  363.   WILL KERMIT
  364.   DO KERMIT
  365.                                 <responds to negotiations>
  366.                                 DO KERMIT
  367.                                 SB KERMIT SOP <0x01>
  368.                                 WILL KERMIT
  369.  
  370.   SB KERMIT SOP <0x01>
  371.                                 <client enters terminal emulator>
  372.                                 SB KERMIT START-SERVER
  373.  
  374.   <in response to DO>
  375.   SB KERMIT SOP <0x01>
  376.   SB KERMIT START-SERVER
  377.                                 <client restricts command set to
  378.                                  Kermit protocol commands>
  379.                                 SB KERMIT STOP-SERVER
  380.  
  381.                                 <client performs Kermit protocol
  382.                                  operations>
  383.  
  384.                                 <client want to enter terminal mode>
  385.                                 SB KERMIT REQ-STOP-SERVER
  386.  
  387.   <Kermit Server refuses>
  388.   SB KERMIT RESP-START-SERVER
  389.  
  390.  
  391. 5.5. EXAMPLE 5
  392.  
  393. This is an example of something that should not be allowed to happen.
  394. Some Telnet clients that implement file transfer capabilities are
  395. designed to accept incoming connections.  In this situation the Telnet
  396. Client acts as a pseudo Telnet Server but without the ability to provide
  397. shell access or many of the other functions associated with Telnet.  If
  398. both Telnet clients support this option and contain a Kermit server that
  399. is active during terminal emulation there is the potential for a
  400. deadlock situation if scripting is also supported.  This is because
  401. Telnet clients that support a script language do not process input while
  402. waiting for the next command to be issued.
  403.  
  404.   Telnet Client One             Telnet Client Two
  405.   ---------------------------   -----------------------------
  406.   <starts negotiations>
  407.   WILL KERMIT
  408.   DO KERMIT
  409.                                 <responds to WILL>
  410.                                 DO KERMIT
  411.                                 SB KERMIT SOP <0x01>
  412.  
  413.   <in response to DO>
  414.   SB KERMIT SOP <0x01>
  415.   SB KERMIT START-SERVER
  416.                                 <responds to DO>
  417.                                 WILL KERMIT
  418.                                 SB KERMIT START-SERVER
  419.  
  420.   <client one restricts command
  421.    set to Kermit protocol and
  422.    disables Kermit Server>
  423.   SB KERMIT STOP-SERVER
  424.                                 <client two restricts command
  425.                                  set to Kermit protocol and
  426.                                  disables Kermit Server>
  427.                                 SB KERMIT STOP-SERVER
  428.  
  429. At this point both clients have restricted their command set to Kermit
  430. Protocol commands.  However, in both cases neither side is processing
  431. input.  Therefore the following restriction MUST be enforced: A Telnet
  432. partner may not restrict the command set if it accepted the incoming
  433. connection.
  434.  
  435.  
  436. 6. SECURITY
  437.  
  438. Implementors of this Telnet Option must be sure to enforce appropriate
  439. user authentication and file system access restrictions.  These issues
  440. are beyond the scope of this document.
  441.  
  442.  
  443. 7. REFERENCES
  444.  
  445. [BCP] Bradner, Scott, RFC 2119, "Best Current Practice", March 1997.
  446.  
  447. [KER] da Cruz, Frank, "Kermit, A File Transfer Protocol", Digital Press/
  448.       Butterworth Heinemann, Newton, MA, ISBN 0-932376-88-6 (1987).
  449.  
  450. [IKS] da Cruz, Frank, and Jeffrey E. Altman, "Internet Kermit Service",
  451.       Internet Draft <draft-columbia-kermit-service-00.txt>,
  452.       August 1998.
  453.  
  454. [TEL] Postel, J., and J. Reynolds, "Telnet Protocol Specification",
  455.       RFC854, May 1983, et seq.; "Telnet Option Specification",
  456.       RFC855, May 1983, et seq.
  457.  
  458.  
  459. 8. AUTHORS' ADDRESS
  460.  
  461. Jeffrey E. Altman
  462. jaltman@columbia.edu
  463.  
  464. Frank da Cruz
  465. fdc@columbia.edu
  466.  
  467. The Kermit Project
  468. Columbia University
  469. 612 West 115th Street
  470. New York NY 10025-7799
  471. USA
  472. http://www.columbia.edu/kermit/
  473. http://www.kermit-project.org/
  474.  
  475. (End)
  476.