Message Send Protocol 2 (RFC1312)
Original Publication Date: 1992-Apr-01
Included in the Prior Art Database: 2019-Feb-11
Internet Society Requests For Comment (RFCs)
R. Nelson: AUTHOR [+1]
The Message Send Protocol is used to send a short message to a given user on a given terminal on a given host. This memo defines an Experimental Protocol for the Internet community.
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.
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.
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...