Browse Prior Art Database

Message Send Protocol 2 (RFC1312) Disclosure Number: IPCOM000002133D
Original Publication Date: 1992-Apr-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 6 page(s) / 17K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

R. Nelson: AUTHOR [+1]


Status of this Memo

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 16% of the total text.

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


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,

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