[RFCs/IDs] [Plain Text]
EXPERIMENTAL
Network Working Group R. Nelson
Request for Comments: 1312 Crynwr Software
Obsoletes: RFC 1159 G. Arnold
Sun Microsystems, Inc.
April 1992
Message Send Protocol 2
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Discussion
The Message Send Protocol is used to send a short message to a given
user on a given terminal on a given host. Unix's write command
offers a limited form of this service through its host-local write
command. This service is also known on some hosts as "SEND".
As the Internet grows, more and more people are using hosts that do
not run Internet protocols at all times. These hosts may be able to
use a simple protocol that can be implemented using UDP and IP. The
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 to
a user's terminal. SMTP's SEND is not useful in this instance
because SMTP's SEND is not implemented by the majority of vendors at
this time, and is difficult to use by unskilled users. For the
purposes of standardization, we will include a TCP based Message Send
Service.
Message Syntax
The message consists of several parts, all of which must be present
The first part is a single octet indicating the protocol revision,
currently decimal 66, 'B'. The remaining parts are null-terminated
sequences of eight-bit characters in the ISO 8859/1 alphabet. Some
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 to
any user of the destination system.
RECIP-TERM The name of the terminal to which the message is to be
delivered. The syntax and semantics of terminal names
are outside the scope of this specification. If this
part is empty, the "right" terminal is chosen. This is
a system-dependent function. If this part consists of
the string "*", all terminals on the destination
system are implied. If the RECIPIENT part is empty
but the RECIP-TERM is not, the message is written on
the specified terminal. If both the RECIPIENT and
RECIP-TERM parts are empty, the message should be
written on the "console", which is defined as some
place where the message is most likely to be seen by a
human operator or administrator.
MESSAGE The actual message. The server need not preserve the
formatting and white-space content of the message if
this is necessary to display it. New lines should be
represented using the usual Netascii CR + LF.
(Following the Internet tradition, a server should
probably be prepared to accept a message in which some
other end-of-line convention is followed, but a
conforming client must use CR + LF.)
The message text may only contain printable characters
from the ISO 8859/1 set, which is upward compatible
from USASCII, plus CR, LF and TAB. No other control
codes or escape sequences may be included: the client
should strip them from the message before it is
transmitted, and the server must check each incoming
message for illegal codes. (A server may choose to
display the message after stripping out such codes, or
may reject the entire message.) If the MESSAGE part is
empty, the message may be discarded by the server.
SENDER The username of the sender. (This and subsequent parts
were not present in version 1 of the Message Send
Protocol.) This part should not be empty. A server may
choose to accept, reject or ignore messages in which
the SENDER part is empty.
SENDER-TERM The name of the sending user's terminal. This part may
be empty. The intention is that a recipient may reply
Nelson & Arnold [Page 2]
RFC 1312 Message Send Protocol 2 April 1992
to a message by sending the reply to the user SENDER
at terminal SENDER-TERM on the originating system.
(The sender's hostname should be retrieved from the
transport software.)
COOKIE A magic cookie. This part must be present in all
messages, but is only of significance for the UDP
service. The combination of the sender's UDP port
number and this cookie should be unique. A client may
elect to transmit a particular message several times
to increase the chances of its reception; a server may
use the cookie and port to identify duplicate messages
and discard them. A reasonable cookie is the time of
day represented in a readable format. The maximum
length of a cookie is 32 octets, excluding the
terminating null.
SIGNATURE A token which, if present, may be used by the server
to verify the identity of the sender. The use of the
SIGNATURE part is discussed further in the section on
Security, below.
The total length of the message shall be less than 512 octets. This
includes all eight parts, and any terminating nulls. UDP packets are
limited to 512 octets.
If this protocol is changed, the revision number will be changed.
TCP Based Message Send Service
One Message Send Service is defined as a connection based application
on TCP. A server listens for TCP connections on TCP port 18. Once a
connection is established a message is sent by the client over the
connection.
The serv