home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc0933.txt < prev    next >
Text File  |  1996-05-07  |  7KB  |  160 lines
  1.  
  2.  
  3. Network Working Group                                       S. Silverman Request for Comments: 933                               MITRE-Washington                                                             January 1985 
  4.  
  5.                       OUTPUT MARKING TELNET OPTION 
  6.  
  7.  Status of this Memo 
  8.  
  9.    This RFC proposes a new option for Telnet for the ARPA-Internet    community, and requests discussion and suggestions for improvements.    Distribution of this memo is unlimited. 
  10.  
  11. Overview 
  12.  
  13.    This proposed option would allow a Server-Telnet to send a banner to    a User-Telnet so that this banner would be displayed on the    workstation screen independently of the application software running    in the Server-Telnet. 
  14.  
  15. 1.  Command Name and Code 
  16.  
  17.    OUTMRK    27 
  18.  
  19. 2.  Command Meanings 
  20.  
  21.    IAC WILL OUTMRK 
  22.  
  23.       Sender is willing to send output marking information in a       subsequent sub-negotiation. 
  24.  
  25.    IAC WON'T OUTMRK 
  26.  
  27.       Sender refuses to send output marking information. 
  28.  
  29.    IAC DO OUTMRK 
  30.  
  31.       Sender is willing to receive output marking information in a       subsequent sub-negotiation. 
  32.  
  33.    IAC DON'T OUTMRK 
  34.  
  35.       Sender refuses to accept output marking information. 
  36.  
  37.    IAC SB OUTMRK CNTL data IAC SE 
  38.  
  39.       The sender requests receiver to use the data in this       subnegotiation as a marking for the normally transmitted Telnet       data until further notice.  The CNTL octet indicates the position       of the marking (see below). 
  40.  
  41.  
  42.  
  43. Silverman                                                       [Page 1] 
  44.  
  45.  
  46.  RFC 933                                                     January 1985 Output Marking Telnet Option 
  47.  
  48.     IAC SB OUTMRK ACK IAC SE 
  49.  
  50.       The sender acknowledges the data and agrees to use it to perform       output marking (see below). 
  51.  
  52.    IAC SB OUTMRK NAK IAC SE 
  53.  
  54.       The sender objects to using the data to perform output marking       (see below). 
  55.  
  56. 3.  Default 
  57.  
  58.    WON'T OUTMRK 
  59.  
  60.       Output marking information will not be exchanged. 
  61.  
  62.    DON'T OUTMRK 
  63.  
  64.       Output marking information will not be exchanged. 
  65.  
  66. 4.  Motivation for the Option 
  67.  
  68.    The security architecture of some military systems identifies a    security level with each Telnet connection.  There is a corresponding    need to display a security banner on visual display devices.    (Reference: Department of Defense Trusted Computer System Evaluation    Criteria, Section 3.1.1.3.2.3, Labeling Human-Readable Output.) 
  69.  
  70.    The output marking is currently done by transmitting the banner as    data within each screen of data.  It would be more efficient to    transmit the data once with instructions and have User-Telnet    maintain the banner automatically without any additional    Server-Telnet action.  This frees Server-Telnet from needing to know    the output device page size. 
  71.  
  72.    Under this proposal Server-Telnet would send an option sequence with    the command, a control flag, and the banner to be used.  While    current systems use the top of the screen, it is conceivable other    systems would want to put the banner at the bottom or perhaps even    the side of the screen.  This is the reason for the control flag. 
  73.  
  74. 5.  Description of the Option 
  75.  
  76.    Either side of the session can initiate the option; however, normally    it will be the server side that initiates the request to perform    output marking.  Either the Server-Telnet sends "WILL OUTMRK" or the    User-Telnet sends a "DO OUTMRK".  The party receiving the initial 
  77.  
  78.  Silverman                                                       [Page 2] 
  79.  
  80.  
  81.  RFC 933                                                     January 1985 Output Marking Telnet Option 
  82.  
  83.     "WILL" (or "DO") would respond with "DO" (or "WILL") to accept the    option.  Then Server-Telnet responds with the marking data.  The    format of this is: 
  84.  
  85.       "IAC SB OUTMRK CNTL data IAC SE" 
  86.  
  87.          CNTL is the Control Flag described below,          the data is in ASCII. 
  88.  
  89.    If this is satisfactory, User-Telnet responds: 
  90.  
  91.       "IAC SB OUTMRK ACK IAC SE" 
  92.  
  93.          ACK is the ASCII ACK (6). 
  94.  
  95.    From this point, User-Telnet will have to translate any command which    uses cursor controls so that the application data is mapped to the    application part of the screen. 
  96.  
  97.    If the data passed in the subnegotiation field is unacceptable to    User-Telnet, then it responds with: 
  98.  
  99.       "IAC SB OUTMRK NAK IAC SE" 
  100.  
  101.          NAK is the ASCII NAK (21). 
  102.  
  103.    It is now up to Server-Telnet to start the sequence over again and    use "more acceptable" data (or possibly take other action such as    connection termination). 
  104.  
  105.    To terminate output marking, Server-Telnet transmits "WON'T OUTMRK". 
  106.  
  107.    If necessary, User-Telnet would notify Server-Telnet about the new    effective page size.  User-Telnet would then map the output data to    the allowed usable space on the screen. 
  108.  
  109.    User-Telnet may request OUTMRK data or initiate setup of this    convention at anytime by transmitting "DO OUTMRK".  If a WILL, DO    OUTMRK exchange is not followed by the OUTMRK subnegotiation of the    marking data, the User-Telnet may terminate the output marking option    by sending a "DON'T OUTMRK". 
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  Silverman                                                       [Page 3] 
  118.  
  119.  
  120.  RFC 933                                                     January 1985 Output Marking Telnet Option 
  121.  
  122.     Control Flag 
  123.  
  124.       The CNTL flag is defined as: 
  125.  
  126.          D = Default, the placement of the markings is up to              User-Telnet.  This is the expected mode for most              interactions. 
  127.  
  128.          T = Top, this banner is to be used as the top of the screen.              If multiple output markings are desired, then T and B (or R              & L ) are to be used. 
  129.  
  130.          B = Bottom, this banner is to be used at the bottom of the              screen. 
  131.  
  132.          L = Left, markings on the left.  (The precise meaning of this              is to be defined.) 
  133.  
  134.          R = Right, marking on right.  (The precise meaning of this is              to be defined.) 
  135.  
  136.    Banner Data 
  137.  
  138.       The use of Carriage Return and Line Feed (CRLF) will be       interpreted as a end of line in the marking banner text.  If the       user wants a multiline banner, CRLF will be used between each       line.  No CRLF is needed at the end of the marking data. 
  139.  
  140.       To use multiple banners, all of the banners will be included in       one subnegotiation command of the form: 
  141.  
  142.          "IAC SB OUTMRK CNTL data GS CNTL data IAC SE" 
  143.  
  144.             where GS is the ASCII Group Separator (29) character. 
  145.  
  146.       User-Telnet will be responsible for positioning the marking banner       data on the screen. 
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  Silverman                                                       [Page 4] 
  159.  
  160.