As per Relevance of the word terminal, we have this rfc below:
Network Working Group R.
Request for Comments: 1312 Crynwr
Obsoletes: RFC 1159 G.
Sun Microsystems, Inc
April 1992
Message Send Protocol 2
Status of this
This memo defines an Experimental Protocol for the
community. Discussion and suggestions for improvement are requested
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
The Message Send Protocol is used to send a short message to a
user on a given terminal on a given host. Unix's write
offers a limited form of this service through its host-local
command. This service is also known on some hosts as "SEND".
As the Internet grows, more and more people are using hosts that
not run Internet protocols at all times. These hosts may be able
use a simple protocol that can be implemented using UDP and IP.
Message Send Protocol is one such protocol
Note that a message sending protocol is already defined using TCP
The SMTP protocol includes a "SEND" command that will direct mail
a user's terminal. SMTP's SEND is not useful in this
because SMTP's SEND is not implemented by the majority of vendors
this time, and is difficult to use by unskilled users. For
purposes of standardization, we will include a TCP based Message
Service
Message
The message consists of several parts, all of which must be
The first part is a single octet indicating the protocol revision
currently decimal 66, 'B'. The remaining parts are null-
sequences of eight-bit characters in the ISO 8859/1 alphabet.
parts may be empty. All comparisons of parts (e.g., recipient
Nelson & Arnold [Page 1]
RFC 1312 Message Send Protocol 2 April 1992
cookie, etc.) are case-insensitive. The parts are as follows
RECIPIENT The name of the user that the message is directed to
If this part is empty, the message may be delivered
any user of the destination system
RECIP-TERM The name of the terminal to which the message is to
delivered. The syntax and semantics of terminal
are outside the scope of this specification. If
part is empty, the "right" terminal is chosen. This
a system-dependent function. If this part consists
the string "*", all terminals on the
system are implied. If the RECIPIENT part is
but the RECIP-TERM is not, the message is written
the specified terminal. If both the RECIPIENT
RECIP-TERM parts are empty, the message should
written on the "console", which is defined as
place where the message is most likely to be seen by
human operator or administrator
MESSAGE The actual message. The server need not preserve
formatting and white-space content of the message
this is necessary to display it. New lines should
represented using the usual Netascii CR + LF
(Following the Internet tradition, a server
probably be prepared to accept a message in which
other end-of-line convention is followed, but
conforming client must use CR + LF.)
The message text may only contain printable
from the ISO 8859/1 set, which is upward
from USASCII, plus CR, LF and TAB. No other
codes or escape sequences may be included: the
should strip them from the message before it
transmitted, and the server must check each
message for illegal codes. (A server may choose
display the message after stripping out such codes,
may reject the entire message.) If the MESSAGE part
empty, the message may be discarded by the server
SENDER The username of the sender. (This and subsequent
were not present in version 1 of the Message
Protocol.) This part should not be empty. A server
choose to accept, reject or ignore messages in
the SENDER part is empty
SENDER-TERM The name of the sending user's terminal. This part
be empty. The intention is that a recipient may
Nelson & Arnold [Page 2]
RFC 1312 Message Send Protocol 2 April 1992
to a message by sending the reply to the user
at terminal SENDER-TERM on the originating system
(The sender's hostname should be retrieved from
transport software.)
COOKIE A magic cookie. This part must be present in
messages, but is only of significance for the
service. The combination of the sender's UDP
number and this cookie should be unique. A client
elect to transmit a particular message several
to increase the chances of its reception; a server
use the cookie and port to identify duplicate
and discard them. A reasonable cookie is the time
day represented in a readable format. The
length of a cookie is 32 octets, excluding
terminating null
SIGNATURE A token which, if present, may be used by the
to verify the identity of the sender. The use of
SIGNATURE part is discussed further in the section
Security, below
The total length of the message shall be less than 512 octets.
includes all eight parts, and any terminating nulls. UDP packets
limited to 512 octets
If this protocol is changed, the revision number will be changed
TCP Based Message Send
One Message Send Service is defined as a connection based
on TCP. A server listens for TCP connections on TCP port 18. Once
connection is established a message is sent by the client over
connection
The server replies with a single character indicating positive ("+")
or negative ("-") acknowledgment, immediately followed by an
message of explanation, terminated with a null. The
acknowledgement means that the message was successfully delivered
some user/terminal, and that the negative acknowledgement means
the message was NOT delivered to any terminal
The positive acknowledgement message can contain information
what user and terminal the message was delivered to in the case
incomplete user/terminal fields in the message. The
acknowledgement can contain information about WHY the message was
delivered (no such user/terminal, system failure, user doesn't
Nelson & Arnold [Page 3]
RFC 1312 Message Send Protocol 2 April 1992
messages, etc).
Multiple messages can be sent over the same channel. The
should close first (the server may/should not close directly
the acknowledgement is sent) and the server may close after
timeout on the order of minutes. If the sever is unable to decode
message, or no message is received within a suitable timeout, it
close the channel (on the assumption that the sender may
formatted the data incorrectly).
UDP Based Message Send
Another Message Send Service is defined as a datagram
application on UDP. A server listens for UDP datagrams on UDP
18. When a datagram is received by the server, an answering
may be sent back to the client. If the message was addressed to
particular user (i.e., the RECIPIENT part was non-empty) and
successfully delivered to that user, a positive
should be sent (as described above). If the message was directed
any user (i.e., the RECIPIENT part is empty), or if the message
not be delivered for some reason, no reply is sent
The reason for this policy is that the UDP service may be used
broadcast messages addressed to a particular user on an
system or all users on all systems. In either case, it
inappropriate for all servers to send replies. An
approach might have been to require that a server only send a
if a message was addressed explicitly to that system and was
broadcast. Unfortunately, the most popular network programming
does not provide an easy way for an application to determine this
furthermore such a policy would provide no feedback to the sender
a broadcast message to a particular recipient. The approach
here provides a reasonable compromise
Example of Message
Consider a situation in which the user "sandy" is logged into
console of system "alpha", and wishes to send a message to the
"chris". "chris" is known to be logged in on the system "beta"
the exact terminal is unknown. The message consists of two lines
text, "Hi" followed by "How about lunch?".
The message would be encoded as follows
Nelson & Arnold [Page 4]
RFC 1312 Message Send Protocol 2 April 1992
+--------+---------+---------+---------+
0 | B | c | h | r |
+--------+---------+---------+---------+
4 | i | s | | |
+--------+---------+---------+---------+
8 | H | i | | |
+--------+---------+---------+---------+
12 | H | o | w | |
+--------+---------+---------+---------+
16 | a | b | o | u |
+--------+---------+---------+---------+
20 | t | | l | u |
+--------+---------+---------+---------+
24 | n | c | h | ? |
+--------+---------+---------+---------+
28 | | s | a | n |
+--------+---------+---------+---------+
32 | d | y | | c |
+--------+---------+---------+---------+
36 | o | n | s | o |
+--------+---------+---------+---------+
40 | l | e | | 9 |
+--------+---------+---------+---------+
44 | 1 | 0 | 8 | 0 |
+--------+---------+---------+---------+
48 | 6 | 1 | 2 | 1 |
+--------+---------+---------+---------+
52 | 3 | 2 | 5 | |
+--------+---------+---------+---------+
56 | |
+--------+
Note that the RECIP-TERM and SIGNATURE parts are empty. The
is the string "910806121325", which in this implementation
that the message was sent at 12:13:25 on the 6th of August, 1991.
The identity if the sending and receiving systems is not included
the message; the server must obtain this information from
transport service
Client and server implementations must follow the character
restrictions noted in the MESSAGE part description. Failure to do
may have undesirable effects on the operation of the receiver'
terminal; more seriously, it may open up a significant
Nelson & Arnold [Page 5]
RFC 1312 Message Send Protocol 2 April 1992
"hole". The checks must be made on any part of the message which
be displayed, including the sender's name and terminal. This is
case where the admonition to "be liberal in what you accept" is
applicable. A server may chose to apply additional checks to
incoming message, and to reject any message which may pose a
risk. For example, a system using a PostScript-based display
reject a message which might be interpreted as an
PostScript program
The underlying transport, whether TCP or UDP, is expected to
checksums for the message and any response
The semantics of the various RECIPIENT and RECIP-TERM
may be confusing. The introduction of the "*" wildcard designation
the RECIP-TERM part makes it possible to send a message to
terminals on the designated system (if RECIPIENT is empty), or to
terminals at which a particular recipient has logged in
A positive acknowledgement may indicate only that the Message
server was able to successfully invoke a local message
service. It may not be possible for true end-to-end semantics to
inferred
For example, a Message Send server may employ a local
mechanism which calls upon the services of a window system to
the message in a pop-up window. This process may take
significant time to complete, and it is unclear whether it is
for the server to wait for an indeterminate period before
an acknowledgement. Therefore, this specification does not
whether the acknowledgement is associated with delivery of
message to the local service, the display of the message,
confirmation by the user that the message has been read by, e.g.,
dismissing the pop-up window
Security
Those who plan to implement this service must ensure that
following issues are reflected in the documentation of
products, and that their implementations include
configuration controls to allow systems and network administrators
achieve the appropriate levels of usability and security
First, this service may allow someone to write on a user's
without the user giving his or her permission. Where possible,
should be provided with a mechanism for disabling this
Second, it is extremely important for implementors to observe
rules for filtering message text as discussed under Message
Nelson & Arnold [Page 6]
RFC 1312 Message Send Protocol 2 April 1992
above. Failure to do this may introduce major security holes
The third issue concerns the verification of the sender's identity
If the recipient is fooled into believing that a message is from
particular user, various security issues may arise. For example,
recipient may send a reply containing confidential material
This service is primarily intended for "open" environments
controlled local area networks used by reasonably
participants, in which security considerations may be relaxed in
interests of ease of use and administration. In such an
it is appropriate to trust the user name and source IP address
identifying the actual sender of the message
Within more security-conscious environments, this assumption
probably unacceptable. As has been widely noted, there is no
within the current Internet architecture to ensure that the
address of an IP datagram is correct. Hence it is entirely
for someone to spoof the IP address
The obvious, and simplest, answer is to disallow the use of
protocol in such situations. However a more constructive approach
to incorporate within the protocol some mechanism by which a
can reliably identify the sender
In this version of the protocol specification, we define a
part within a message. If this part is empty, the identity of
sender cannot be verified, and the server implementation may elect
reject all such requests. If the part is not empty, it is treated
a case-insensitive text encoding of some security token. This
does not define the encoding or interpretation of this token.
expect that such matters will form part of future RFCs on
and privacy issues; at an appropriate time, this RFC will be re
issued to include references to these RFCs
PostScript is a trademark of Adobe Systems, Inc
Nelson & Arnold [Page 7]
RFC 1312 Message Send Protocol 2 April 1992
Authors'
Russell
Crynwr
11 Grant St
Potsdam, NY 13676
Phone: (315) 268-1925
EMail: nelson@crynwr.
Geoff
Sun Microsystems, Inc
2 Federal
Billerica, MA 01821
Phone: (508) 671-0317
EMail: geoff@east.sun.
Nelson & Arnold [Page 8]
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
