GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc933

Network Working Group S. Silverman Request for Comments: 933 MITRE-Washington

                                                          January 1985
                    OUTPUT MARKING TELNET OPTION

Status of this Memo

 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.

Overview

 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.

1. Command Name and Code

 OUTMRK    27

2. Command Meanings

 IAC WILL OUTMRK
    Sender is willing to send output marking information in a
    subsequent sub-negotiation.
 IAC WON'T OUTMRK
    Sender refuses to send output marking information.
 IAC DO OUTMRK
    Sender is willing to receive output marking information in a
    subsequent sub-negotiation.
 IAC DON'T OUTMRK
    Sender refuses to accept output marking information.
 IAC SB OUTMRK CNTL data IAC SE
    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).

Silverman [Page 1]

RFC 933 January 1985 Output Marking Telnet Option

 IAC SB OUTMRK ACK IAC SE
    The sender acknowledges the data and agrees to use it to perform
    output marking (see below).
 IAC SB OUTMRK NAK IAC SE
    The sender objects to using the data to perform output marking
    (see below).

3. Default

 WON'T OUTMRK
    Output marking information will not be exchanged.
 DON'T OUTMRK
    Output marking information will not be exchanged.

4. Motivation for the Option

 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.)
 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.
 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.

5. Description of the Option

 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

Silverman [Page 2]

RFC 933 January 1985 Output Marking Telnet Option

 "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:
    "IAC SB OUTMRK CNTL data IAC SE"
       CNTL is the Control Flag described below,
       the data is in ASCII.
 If this is satisfactory, User-Telnet responds:
    "IAC SB OUTMRK ACK IAC SE"
       ACK is the ASCII ACK (6).
 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.
 If the data passed in the subnegotiation field is unacceptable to
 User-Telnet, then it responds with:
    "IAC SB OUTMRK NAK IAC SE"
       NAK is the ASCII NAK (21).
 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).
 To terminate output marking, Server-Telnet transmits "WON'T OUTMRK".
 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.
 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".

Silverman [Page 3]

RFC 933 January 1985 Output Marking Telnet Option

 Control Flag
    The CNTL flag is defined as:
       D = Default, the placement of the markings is up to
           User-Telnet.  This is the expected mode for most
           interactions.
       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.
       B = Bottom, this banner is to be used at the bottom of the
           screen.
       L = Left, markings on the left.  (The precise meaning of this
           is to be defined.)
       R = Right, marking on right.  (The precise meaning of this is
           to be defined.)
 Banner Data
    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.
    To use multiple banners, all of the banners will be included in
    one subnegotiation command of the form:
       "IAC SB OUTMRK CNTL data GS CNTL data IAC SE"
          where GS is the ASCII Group Separator (29) character.
    User-Telnet will be responsible for positioning the marking banner
    data on the screen.

Silverman [Page 4]

/home/gen.uk/domains/wiki.gen.uk/public_html/data/pages/rfc/rfc933.txt · Last modified: 1992/09/23 19:43 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki