RFC393 Comments on Telnet Protocol Changes

0393 Comments on Telnet Protocol Changes. J.M. Winett. October 1972. (Format: TXT=9435 bytes) (Also RFC0109, RFC0139, RFC0158, RFC0318, RFC0328) (Status: UNKNOWN)

日本語訳
RFC一覧

参照

Network Working Group
Request for Comments: 393                         Joel M. Winett
NIC 11585                                         Lincoln Laboratory
Categories: TELNET                                LL-67
References: RFC 109, 139, 158,318, and 328        3 October 1972


                  Comments on TELNET Protocol Changes



    Through this RFC, I am registering my objection to two of the
three suggestions for changing the TELNET protocol as described in RFC
328 and am adding my suggestion for the interpretation of the TELNET
Reverse Break Control Code.


1.  Hide-your-input

    This code was originally put in the TELNET protocol to give the
    virtual terminal the ability to simulate a real terminal which has the
    print suppress capability. If the terminals being used at some
    installations do not have the ability to disable the printing
    mechanism, the TELNET being used can either ignore this code or
    attempt to simulate the function using other means (e. g., blacking
    out a number of character positions and returning to the first
    character position).  Every attempt should be made to allow a network
    user of a time-sharing system to have the same facilities as a local
    user of the time-sharing system. The specification of TELNET protocol
    should not limit the function of users if a function cannot be
    supported by all users.

    The "Hide-your-input" and "Echo" TELNET control codes provide for the
    support of two functions available in some time-sharing systems.  The
    "Hide-your-input" function is really a special case of the "Echo" mode
    of operation where the server tells the user that the server will echo
    but the server does not. A separate code is used for this func- tion
    since some servers may support this function but may not support the
    full "Echo" mode of operation.


   ] This material has not been reviewed for public release and is [
   ] intended only for use with the ARPA network. It should not be [
   ] quoted or cited in any publication not related to the ARPA    [
   ] network.                                                      [






                                                                [Page 1]

    The "Hide-your-input" and "Echo" modes of operation are disabled with
    the "No-echo" control. ASCII control codes could have been chosen for
    these functions but it was decided that the NVT ASCII control codes
    should only be specified for commonly used functions.

    To indicate the number of characters for which the printing should be
    suppressed, the "Hide-your-input" TELNET control could be rede- fined
    to include a byte following the "Hide-your-input" control to indicate
    the number of characters for which the printing should be concealed.
    The "No-echo" control would still be sent so that systems with the
    print suppress feature would not have to count characters.


2.  Data Types

    The protocol should allow a server to support users with character
    codes other than ASCII, e. g., EBCDIC. The definition of an alter-
    nate character code should include the definition of the TELNET
    control codes. An EBCDIC code has been proposed in RFC # 109 and has
    been implemented on the Lincoln Laboratory 360/67. If it is desired to
    allow one to return to the network standard ASCII code, the non-ASCII
    code should contain a code to indicate return to ASCII.


3.  Reverse Break

    The code for Break is defined as a 129th ASCII data code. It is
    usually transmitted from a user's network virtual terminal to a server
    when a corresponding key (break key or attention key) is typed on the
    TELNET terminal and is interpreted by serving systems as that special
    key. Since a common function of this key is to interrupt a running
    process the server must be alerted to the fact that this code has been
    transmitted no matter when it is sent.  Thus, the TELNET SYNC (TELNET
    data mark together with a network interrupt on the TELNET send socket)
    must also be trans- mitted to cause the serving process to examine the
    received charac- ters. The ASCII control code EOT (Octal 4) could have
    been chosen for the break function but his code is not interpreted by
    all systems.  Thus, it was decided that an NVT TELNET control code
    should be used for this purpose.

    The use of the Break Code from server to user TELNET has not
    previously been defined and, thus, could be used to solve the
    following problems which occur with line at a time and half duplex
    systems. Line at a time systems do not output characters to the
    terminal a character at a time but, instead, wait until a line is ready
    for output. If a CR-LF sequence (TELNET protocol for end of line)
    is received it is interpreted as an end of line and the characters
    received are output. If characters are received which do not end



                                                                [Page 2]

    with CR-LF the user TELNET does not know whether or not other
    characters will follow which are part of the current line. Thus, the
    characters received thus far must be output, without a CR-LF (new
    line). If an end of message code were transmitted, the user TELNET
    would know whether or not other characters would be received for
    output. The user TELNET would then print characters either when
    the TELNET Break control is received or when the CR-LF newline
    sequence is received.

    If the user TELNET is being run from a half duplex terminal, the
    terminal cannot receive input and type output at the same time.  Thus,
    if output is received while the terminal is being used for input the
    TELNET program must either buffer the received characters or abort the
    input mode of operation to write out the received charac- ters. If
    characters received are written out as they are received, the terminal
    operation would be very similar to a full duplex terminal.  This mode
    of operation requires that the terminal have a reverse break
    capability to allow the input mode to be aborted by program control.

    In some systems it is only desirable to abort the input mode of
    operation when a complete line is ready for output. If a string of
    characters received does not end with an end of line code, the
    characters received will not be output until after the input line is
    entered, i. e., the mode of operation changed from input to output.
    If an end of message code were transmitted, the user TELNET could
    abort the input mode of operation even though the end of line code was
    not received.

    In systems which do not support the reverse break feature or if the
    terminal does not have this feature it is not possible to abort an
    input mode of operation in order to output received characters. In
    this case, the systems can operate in either of two modes, a) un-
    locked keyboard, or b) locked keyboard mode.

    In an unlocked keyboard system, received characters are not output
    until the user completes an input line. An input line is completed
    when the end of line code is entered. This might be a CR, a LF, or
    a NL code. After received characters, if any, are output, the input
    modes is re-entered. To receive output the user must enter an input
    line (possibly a null line). If the user is waiting for output, he must
    repeatedly enter a line until the output has been received and typed.
    Since an input line must be entered just to receive output, it is
    desirable to define an input line which does not result in anything
    being sent to the serving system. If a null line (a line consisting of
    just the end of line code) is chosen for this purpose, some other input
    line must be defined to cause a null line to be transmitted.

    In a locked keyboard system, the input mode is not immediately



                                                                [Page 3]

    re-entered after an input line is entered. It is re-entered only after
    a defined prompt is received. The prompt can be defined to be the
    reception of any character or can be defined to be a specific charac-
    ter code. If a specific code is chosen the serving site must send this
    code whenever the terminal should be put into input mode. If an end of
    message code were transmitted this code could be inter- preted to be
    the input prompt code.

     In summary, three situations have been described where an end of
message code would be desirable.

     a) To indicate when a line which does not end with CR-LF should
        be output for line at a time systems

     b) To indicate that the input mode in half duplex operation should
        be aborted so that received characters can be output

     c) As a prompt character to cause the input mode to be entered
        for locked keyboard half duplex systems

     The ASCII TELNET control code for Break (Reverse Break) could be
interpreted as an end of message code when sent from server to user.



          [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by BBN Corp. under the   ]
          [ direction of Alex McKenzie.                      1/97 ]























                                                                [Page 4]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

<演算子 小さい

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る