As per Relevance of the word security, we have this rfc below:







Network Working Group S.
Request for Comments: 933 MITRE-
January 1985

OUTPUT MARKING TELNET


Status of this

This RFC proposes a new option for Telnet for the ARPA-
community, and requests discussion and suggestions for improvements
Distribution of this memo is unlimited



This proposed option would allow a Server-Telnet to send a banner
a User-Telnet so that this banner would be displayed on
workstation screen independently of the application software
in the Server-Telnet

1. Command Name and

OUTMRK 27

2. Command

IAC WILL

Sender is willing to send output marking information in
subsequent sub-negotiation

IAC WON'T

Sender refuses to send output marking information

IAC DO

Sender is willing to receive output marking information in
subsequent sub-negotiation

IAC DON'T

Sender refuses to accept output marking information

IAC SB OUTMRK CNTL data IAC

The sender requests receiver to use the data in
subnegotiation as a marking for the normally transmitted
data until further notice. The CNTL octet indicates the
of the marking (see below).



Silverman [Page 1]



RFC 933 January 1985
Output Marking Telnet


IAC SB OUTMRK ACK IAC

The sender acknowledges the data and agrees to use it to
output marking (see below).

IAC SB OUTMRK NAK IAC

The sender objects to using the data to perform output
(see below).

3.

WON'T

Output marking information will not be exchanged

DON'T

Output marking information will not be exchanged

4. Motivation for the

The security architecture of some military systems identifies
security level with each Telnet connection. There is a
need to display a security banner on visual display devices
(Reference: Department of Defense Trusted Computer System
Criteria, Section 3.1.1.3.2.3, Labeling Human-Readable Output.)

The output marking is currently done by transmitting the banner
data within each screen of data. It would be more efficient
transmit the data once with instructions and have User-
maintain the banner automatically without any
Server-Telnet action. This frees Server-Telnet from needing to
the output device page size

Under this proposal Server-Telnet would send an option sequence
the command, a control flag, and the banner to be used.
current systems use the top of the screen, it is conceivable
systems would want to put the banner at the bottom or perhaps
the side of the screen. This is the reason for the control flag

5. Description of the

Either side of the session can initiate the option; however,
it will be the server side that initiates the request to
output marking. Either the Server-Telnet sends "WILL OUTMRK" or
User-Telnet sends a "DO OUTMRK". The party receiving the


Silverman [Page 2]



RFC 933 January 1985
Output Marking Telnet


"WILL" (or "DO") would respond with "DO" (or "WILL") to accept
option. Then Server-Telnet responds with the marking data.
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
uses cursor controls so that the application data is mapped to
application part of the screen

If the data passed in the subnegotiation field is unacceptable
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
use "more acceptable" data (or possibly take other action such
connection termination).

To terminate output marking, Server-Telnet transmits "WON'T OUTMRK".

If necessary, User-Telnet would notify Server-Telnet about the
effective page size. User-Telnet would then map the output data
the allowed usable space on the screen

User-Telnet may request OUTMRK data or initiate setup of
convention at anytime by transmitting "DO OUTMRK". If a WILL,
OUTMRK exchange is not followed by the OUTMRK subnegotiation of
marking data, the User-Telnet may terminate the output marking
by sending a "DON'T OUTMRK".








Silverman [Page 3]



RFC 933 January 1985
Output Marking Telnet


Control

The CNTL flag is defined as

D = Default, the placement of the markings is up
User-Telnet. This is the expected mode for
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
& L ) are to be used

B = Bottom, this banner is to be used at the bottom of
screen

L = Left, markings on the left. (The precise meaning of
is to be defined.)

R = Right, marking on right. (The precise meaning of this
to be defined.)

Banner

The use of Carriage Return and Line Feed (CRLF) will
interpreted as a end of line in the marking banner text. If
user wants a multiline banner, CRLF will be used between
line. No CRLF is needed at the end of the marking data

To use multiple banners, all of the banners will be included
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
data on the screen












Silverman [Page 4]








if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.




RFC documents can be found at I.E.T.F.



Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX







Spectrum