rfc98.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 564 行 · 第 1/2 页


RFC 98                  Logger Protcol Proposal                 Feb 1971


    scheme, it is not possible to implement administratively assigned
    user codes, because the logger must assign permanent sockets
    before the identity of the user is verified. A future connection
    protocol can avoid this problem by implementing a socket
    connection as a part of the admission phase. The logger would talk
    to the user over the logger's sockets. Following identification it
    would transfer the connections to the sockets belonging to the
    user.

5.  General Console Communications. A companion paper under
    preparation outlines a protocol for general console communcations
    between hosts. This paper will seek to adress most of the
    problems associated with typewriter like communications. This
    includes discussion of full and half duplex, character escapes,
    action characters and other pertinent topics. Such a protocol
    might not be suitable for all terminals and host systems but
    would include solutions to problems for many. It is not
    intended as a monolithic standard, but rather as a recommendation
    for those sites who wish to implement a common protocol. The
    important point is that we feel quite a bit of actual network
    usage is required before all the problems are better understood.
    This is a prerequisite for devising a standard.


                             SPECIFICATIONS

Initial Connection Protocol - Connection Phase

      The following sequence is as presented in RFC 80. It  is  restated
      here for completeness.

1.  To intiate contact , the using process requests a connection of
    his receive socket (US) to a socket (SERV) in the serving host.
    By convention, this socket has the 24-bit user number field set
    to zero. The 8-bit tag or AEN field is set to one indicating
    the socket gender to be that of a sending socket. There is no
    restriction on the choice of the socket US other than it be of
    of the proper gender; in this case a receive socket. As a result
    the using NCP sends:

                            User -> Server

                   8        32          32         8
                +-----+------------+------------+-----+
                | RTS |     US     |   SERV     |  P  |
                +-----+------------+------------+-----+





                                                                [Page 6]

RFC 98                  Logger Protcol Proposal                 Feb 1971


    over the control link one, where P is the receive link assigned
    by the user's NCP.

2.  The serving host now has the option of accepting the request for
    connection or closing the the connection.

    a.  If he sends a close it is understood by the user that the
        foreign host is unable to satisfy a request for service at
        this time. The serving host's NCP would send:

                          Server -> User

                   8        32          32
                +-----+-----------+------------+
                | CLS |    SERV   |     US     |
                +-----+-----------+------------+

        with the user's NCP sending the echoing close:

                          User -> Server

                   8        32          32
                +-----+-----------+------------+
                | CLS |     US    |    SERV    |
                +-----+-----------+------------+

    b.  If the serving host is willing to provide service it will
        accept the connection and immediately close the connection.
        This results in the the serving host's NCP sending:

                          Server -> User

                   8        32          32
                +-----+-----------+------------+
                | STR |    SERV   |     US     |
                +-----+-----------+------------+

                   8        32          32
                +-----+-----------+------------+
                | CLS |    SERV   |     US     |
                +-----+-----------+------------+










                                                                [Page 7]

RFC 98                  Logger Protcol Proposal                 Feb 1971


        with the user's NCP sending the echoing close. It sends:

                          User -> Server

                   8        32          32
                +-----+-----------+------------+
                | CLS |     US    |    SERV    |
                +-----+-----------+------------+

        It should be mentioned that the echoing closes are required
        by the host-to-host protocol and not by the logger initial
        connection protocol.

Character Set

        The character  set  used  in  conducting  the  login  dialog  is
standard  ASCII  as  documented  in "American National Standard Code for
Information Interchange", ANS X3,  4-1968,  American  National  Standard
Institute, October, 1968. A logger at a serving host may demand any kind
of input that can be  expressed  as  a  string  of  one  or  more  ASCII
characters. It similarly, it may output any such string.

        All ASCII characters  are  legal,  including  the  graphics  and
control  characters.  However, it is proposed that the only standard way
of indicating the end of a console  line  be  the  line  feed  character
(012).  This  is  in  accordance with an anticipated change to the ASCII
standard.

       Currently the ASCII standard permits  two  methods  of  ending  a
line.  One  method  defines  a  single  character,  line  feed (012), as
incorporating the combined functions of line space and  carriage  return
to  the  lefthand  margin.  The  second  method, implicitly permitted by
ASCII, uses the two character sequence  line  feed  (012)  and  carriage
return (015) to perform the same function.

        There is a proposal  that  the  ASCII  standard  be  changed  to
include  a  return  to  the  left-hand  margin  in  all  vertical motion
characters of at least one full space (line feed, vertical tab  and  new
page). This will disallow the dual character sequence to end a line.

        It is suggested that a character in a hostst character  set  not
having  any  ASCII  equivalnet be represented by the ASCII two character
sequence ESC (033) and one of the ASCII  characters.  Each  host  should
publish a list of the escape sequence it has defined.







                                                                [Page 8]

RFC 98                  Logger Protcol Proposal                 Feb 1971


Transaction Block Format

        All textual messages exchanged between user and  logger  are  to
consist of one or more "transaction blocks". Each transaction block is a
sequence of 8-bit elements in the following format:

                <code> <count> <char1> ... <charn>

<code>     is an 8-bit element that is not interpreted in this
           protocol. In the proposed general console communications
           protocol, this field specifies communication modes or
           special characteristics of this transaction block. Here
           <code> is to be zero.

<count>    is an 8-bit element that specifies the number of character
           elements that follow in this transaction block. It is
           interpreted as a binary integer which has a permissible
           range between 0 and 127. The most significant bit is zero.

<chari>    is an 8-bit element containing a standard 7-bit ASCII
           character right-adjusted. The most significant bit is
           zero. The number of <chari> in the transaction block is
           governed by the <count> field. A maximum of 127 and
           minimum of zero characters are permitted in a single
           transaction block.

        The most significant bit of each  of  these  elements  is  zero,
effectively   limiting   each   of  these  elements  to  seven  bits  of
significance. The reason for doing this is twofold: the  eighth  bit  of
the  <chari> elements is specifically reserved for future expansion, and
it was desired to limit  all  the  elements  so  as  to  permit  certain
implementations  to  convert  the incoming stream from 8-bit elements to
7-bit elements prior to decoding.

        With one exception, there  is  to  be  no  semantic  connotation
attached  with  the  division  of a logger-user message into one or more
transaction blocks. The character string comprising the  message  to  be
transmitted  may  be  divided and apportioned among multiple transaction
blocks according to the whim of the  sending  host.  If  less  than  128
characters  in  length,  the message may be sent as a single transaction
block. The exception is that separate messages may  not  appear  in  the
same  transaction  block. That is, a message must start at the beginning
of a transaction block and finish at the end  of  one.  Note  also  that
there  is  no syntactic device for specifying the last transaction block
of a message. It  is  presumed  that  the  logger  end  user  both  have
sufficient  knowledge  of  the  format to know when all of a message has
arrived




                                                                [Page 9]

RFC 98                  Logger Protcol Proposal                 Feb 1971


        Note that the first 8-bits of data transmitted through  a  newly
established  connection  must  be  a  type code as specified in Protocol
Document 1. This type code must be sent prior to the  first  transaction
block and should be discarded by the receiving host.


Acknowledgments

        Robert Bressler,  Allen  Brown,  Robert  Metcalfe,  and  Michael
Padlipsky  contributed  directly  to  the  establishment  of  the  ideas
presented  here.  Thanks  are  due  Michael  Padlipsky  and  others  for
editorial comments.


       [ This RFC was put into machine readable form for entry ]
          [ into the online RFC archives by Carl Moberg 1/98 ]



































                                                               [Page 10]