summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1756.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1756.txt')
-rw-r--r--doc/rfc/rfc1756.txt619
1 files changed, 619 insertions, 0 deletions
diff --git a/doc/rfc/rfc1756.txt b/doc/rfc/rfc1756.txt
new file mode 100644
index 0000000..4444975
--- /dev/null
+++ b/doc/rfc/rfc1756.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group T. Rinne
+Request for Comments: 1756 HUT
+Category: Experimental January 1995
+
+
+ REMOTE WRITE PROTOCOL - VERSION 1.0
+
+Status of this Memo
+
+ This memo defines an Experimental Protocol for the Internet
+ community. This memo does not specify an Internet standard of any
+ kind. Discussion and suggestions for improvement are requested.
+ Distribution of this memo is unlimited.
+
+1. Background
+
+ It is often convenient to use electronic communication somewhat
+ lighter than electronic mail. Sometimes even the use of the talk(1)
+ *) program seems like overkill. We like to offer to user something
+ like UNIX **) command write(1) ***) except that it can also pass
+ messages through the network instead of the single host.
+
+ There have been few programs offering this kind of service, but they
+ have either based on SUN-RPC protocol or used a strictly undocumented
+ protocol.
+
+ This document describes a simple Remote Write Protocol (RWP) that
+ should have been documented at least 10 years ago. But late is
+ better than never. Version number of the RWP protocol in this
+ document is 1.0.
+
+2. Overview
+
+ RWP is a simple protocol that can be used to relay short messages
+ through the network to other users. RWP looks pretty much like
+ Simple Mail Transfer Protocol (SMTP) ****) though it is a bit more
+ complicated due to the interactive nature of the RWP session.
+
+ The idea behind the RWP session is that client program that is
+ relaying message to the host in which the target user is logged in
+ opens the tcp or udp connection to the server program running in the
+ target machine Then the client gives the sender's and recipient's
+ identification (usually login ids), actual message body and tells the
+ server to deliver a message to the user. On tcp-connection server
+ returns a status from each action taken. On udp-connection no
+ responses are sent. RWP sessions through udp are implemented to
+ support message broadcasting.
+
+
+
+
+Rinne [Page 1]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+ Message delivering methods are not defined within this document, but
+ the basic method could be a simple write to users terminal. This is
+ basically what UNIX command write(1) does. Depending on server
+ implementation, the delivery method could be configurable personally
+ by each user.
+
+3. Description
+
+ Server program answers to each command submitted by a response. All
+ responses have two parts: three number unique response code and a
+ short textual explanation of the response. Also whenever the server
+ is ready to accept new commands a notification is submitted to the
+ client.
+
+ There are three kinds of commands in RWP. The first group is for
+ querying a status of the server. The second group is actual message
+ handling commands and the last set of commands are for RWP session
+ control.
+
+ When the server is ready to receive a command from the client, it
+ sends a message code 100 to the client. This message is for example
+ as follows:
+
+ 100 Ready.
+
+ Server commands are as follows:
+
+ Status Query
+
+ HELP Gives a short help message that contains legal
+ RWP commands. Help lines have code 510. Example RWP
+ implementation *****) gives a following response to
+ HELP command:
+
+ 510 Valid commands are:
+ 510 BYE, DATA, HELP, HELO,
+ 510 RSET, SEND, PROT, QUIT,
+ 510 VRFY, VER
+ 510 FROM senderlogin
+ 510 FHST senderhost
+ 510 TO recipentlogin [tty]
+ 510 FWDS current_hop_count
+
+ HELO Says hello to the server. Server response to HELO
+ command has code 500. For example:
+
+ 500 Hello remote.host. This is local.host speaking.
+
+
+
+
+Rinne [Page 2]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+ PROT Asks the RWP protocol version from the server.
+ Response code to PROT command is 502. Protocol
+ version described in this document is RWP 1.0 and the
+ response is as follows:
+
+ 502 RWP version 1.0.
+
+ VRFY After the recipient of the message is set by to command
+ described later, the possibility of message delivery
+ can be queried by VRFY command. If message can be
+ delivered the response code is 108. If message is
+ about to be forwarded the response code is 110 and
+ message is either form:
+
+ 110 Recipient ok to forward.
+
+ or if the server can tell the destination of the
+ forwarding:
+
+ 110 Recipient ok to forward <user@host.domain>.
+
+ Other possible response codes are 669, 670, 671, 674
+ and 677 and they all indicate that message delivery is
+ by one way or another currently impossible.
+ Description of the codes is later in this document.
+
+ After the SEND command the server may also give
+ autoreply from the remote user before the actual
+ response code. Autoreply lines are ones of code 300.
+
+ VER Asks the version of the server program. Response code
+ to VER command is 501 and the textual part of the
+ response is the name and the version number of the RWP
+ server, for example:
+
+ 501 Rwrited version 1.0.
+
+ Message Handling:
+
+ FROM senderlogin
+ Tells the server the identification information of the
+ sender of the message. Usually this id information is
+ user's login id. Response code to successful FROM
+ command is 105, for example:
+
+ 105 Sender ok.
+
+
+
+
+
+Rinne [Page 3]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+ TO recipentlogin [tty]
+ Tells the server the identification information of the
+ intended recipient of the message. Usually this id
+ information is user's login id. If tty is submitted,
+ the message is delivered to that tty. If tty is
+ submitted between brackets '[]' the tty given is
+ treated as a hint only. Response code to successful
+ TO command is 106.
+
+ FHST original.host [forwarder1.host forwarder2.host ...]
+ Tells the server the host name that the message
+ originates to and the path of the hosts that has
+ forwarded the message. The host name of the machine
+ that is currently submitting the message to the server
+ should not be in the path list.
+
+ This information is relevant if message is forwarded
+ and it is not originally coming from the host that is
+ forwarding it. Response code to successful FHST
+ command is 111.
+
+ DATA Tells the server to start receive the body of the
+ message. Response code to DATA command is 200, for
+ example:
+
+ 200 Enter message. Single dot '.' on line terminates.
+
+ After response 200 the message lines are submitted to
+ the server one after another. Message is terminated
+ by the line that contains a single dot '.'. The
+ termination of the message is acknowledged by the
+ server with the response code 107. Server does not
+ notify client about receiving the single message
+ lines. If empty message is submitted (i.e. single dot
+ is on the first line) the response code is 672 and
+ DATA command only cancels possible previous DATA
+ command. Because of this all dots or at least dots
+ that are standing alone in the line have to be quoted.
+
+ SEND Sends the message. If commands FROM, TO and DATA are
+ successfully given before SEND command, the message is
+ delivered to the target user. If delivery is
+ successful the response code is 103. If message is
+ not delivered directly to the target user but instead
+ forwarded to another host the response code is 104.
+ Response codes 669, 670 and 671, 677 indicate an error
+ on message delivery and codes 673, 674, 675 indicate
+ that either command FROM, TO or DATA has not been
+
+
+
+Rinne [Page 4]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+ successfully given before SEND command. After the
+ SEND command the server may also give autoreply from
+ the remote user before the actual response code.
+ Autoreply lines are ones of code 300.
+
+ FWDS n Tells the server that message has been forwarded n
+ times. If the server forwards the message to the
+ another server, it increments the counter and tells
+ the remote server the current count of forwards.
+ Response code to the FWDS command is 110 if n is less
+ than the server specific forward limit. If this limit
+ is exceeded the response code is 676. If the response
+ code is 676 the client can either quit the session and
+ fail the message or it can give the message to the
+ server despite the fact that the forward limit is
+ exceeded. If the message is given when forward limit
+ is exceeded, the server tries to deliver it, but does
+ not forward it to another server. If forward count is
+ given as -1, the message is considered as a autoreply
+ and never forwarded.
+
+ Session Control:
+
+ RSET Resets the RWP session. FROM, TO and DATA -commands
+ that are given before are canceled and they have to
+ be given again before SEND command can be used. Also
+ possible FWDS and FHST commands are canceled.
+
+ BYE Terminates the RWP session. Server gives a response
+ code 101 and closes the connection.
+
+ QUIT Is the synonym to bye, but it's a lot more impolite.
+ Response code is however 101 as in bye.
+
+ Server specific command:
+
+ QUOTE command
+
+ Relay a command to the server. If the QUOTE command
+ is successfully completed response code 112 is
+ returned. If QUOTE command is failed the response
+ code is 678. If RWP server doesn't recognize the
+ given QUOTE command the response code is 679.
+
+ Currently reserved QUOTE commands are AGENT, CHARSET,
+ IDENT, KEY and KEYID.
+
+
+
+
+
+Rinne [Page 5]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+4. Response Codes
+
+ Here are all legal response codes of RWP server followed by short
+ textual explanation. Only the numeral codes are important and texts
+ can contain practically anything, however in response code 110 there
+ is possibly useful information between '<' and '>' characters. No
+ characters '<' or '>' should be present in other responses. Also
+ response 502 has possibly interesting information about the RWP
+ protocol version the server supports.
+
+ 100 Ready.
+
+ The RWP server is ready to accept next command.
+
+ 101 Goodbye.
+
+ The RWP server is closing connection.
+
+ 103 Message delivered.
+
+ The SEND command is successfully completed and the message is
+ delivered directly to its destination.
+
+ 104 Message forwarded.
+
+ The SEND command is completed and message is forwarded to the
+ user.
+
+ 105 Sender ok.
+
+ The FROM command successful.
+
+ 106 Recipient ok.
+
+ The TO command successful.
+
+ 107 Message ok.
+
+ The DATA command successful.
+
+ 108 Recipient ok to send.
+
+ The VRFY command successful and direct message delivery is
+ possible.
+
+ 109 RSET ok.
+
+ The RWP server has received the RSET command and reset itself.
+
+
+
+Rinne [Page 6]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+ 110 Ok to forward.
+
+ or
+
+ 110 Ok to forward <user@host.domain>.
+
+ The VRFY command successful and direct message delivery by
+ forwarding is possible. If response has also forwarding
+ address the client can either forward the message itself or
+ give it to server for forwarding.
+
+ 111 Original sender host ok.
+
+ The FHST command successful and original sender host is set as
+ given by the client.
+
+ 200 Enter message. Single dot '.' on line terminates.
+
+ The RWP server is ready to receive the message. Single dot on
+ message line terminates the message.
+
+
+ 300 |I'm not in right now but I'll be back tomorrow
+ 300 |at 8 o'clock a.m.
+
+ Automatical response to the delivered message. Every line of
+ this user defined reply message is delivered in its own 300
+ line. Response code 300 lines may appear only after SEND
+ command before response code 103 (message delivered). Client
+ receiving autoreply 300 should show the text of the autoreply
+ to the user. Actual autoreply line begins after the '|'
+ -character in the line.
+
+ 500 Hello remote.host. This is local.host speaking.
+
+ Response to the HELO command. This message can also occur in
+ the beginning of the conversation without the VER command and
+ it can be ignored.
+
+ 501 Rwrited version X.X.
+
+ Response to the VER command. This message can also occur in
+ the beginning of the conversation without the VER command and
+ it can be ignored.
+
+
+
+
+
+
+
+Rinne [Page 7]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+ 502 RWP version 1.0.
+
+ Response to the VER command. This message can also occur in
+ the beginning of the conversation without the VER command and
+ it can be ignored.
+
+ 510 Valid commands are:
+ 510 BYE, DATA, HELP, HELO,
+ 510 RSET, SEND, PROT, QUIT,
+ 510 VRFY, VER
+ 510 FROM senderlogin
+ 510 FHST senderhost
+ 510 TO recipentlogin
+ 510 FWDS current_hop_count
+
+ Response to the HELP command.
+
+ 511 Information to the user.
+
+ Server specific informational response. These responses may
+ occur anytime during the conversation. The client can ignore
+ them.
+
+ 512 Debug information to the user.
+
+ Server specific informational response. Reserved for server
+ debugging. These messages may occur anytime during the
+ conversation. The client can ignore them.
+
+ 666 FATAL ERROR!
+
+ The RWP server got into the fatal error situation and is about
+ to exit immediately. Client programs are strongly encouraged
+ to close the connection.
+
+ 668 Syntax error.
+
+ The RWP server has received an invalid command.
+
+ 669 Permission denied.
+
+ The RWP server is unable to deliver the message because the
+ target user has denied the send permission.
+
+ 670 User not logged in.
+
+ The RWP server is unable to deliver the message because the
+ target user is not logged in.
+
+
+
+Rinne [Page 8]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+ 671 No such user.
+
+ The RWP server is unable to deliver the message because the
+ target user does not exist. Error code 670 can be used to
+ replace this message.
+
+ 672 No message.
+
+ The DATA command is terminated with empty message body. No
+ SEND command can be executed before a new DATA command is
+ given.
+
+ 673 FROM command required.
+
+ Tried to give the SEND command before FROM.
+
+ 674 TO command required.
+
+ Tried to give the SEND command before TO.
+
+ 675 DATA command required.
+
+ Tried to give the SEND command before DATA.
+
+ 676 Forward limit exceeded.
+
+ Response to the FWDS command that had an argument that
+ exceeded the server specific limit of message forwarding
+ steps.
+
+ 677 Unable to forward message.
+
+ or
+
+ 677 Unable to forward message to <user@host.domain>.
+
+ Response to the SEND or VRFY command if message forwarding is
+ attempted and the server specific limit of message forwarding
+ steps has been exceeded or if message forwarding has otherwise
+ failed. If message forwarding fails with message 669, 670 or
+ 671, server will not use response 667 but gives response but
+ instead it gives the response analogous with the error
+ occured. If message 677 includes address the message was to
+ be forwarded, the client may try to deliver it itself.
+
+ 698 Unknown error.
+
+ RWP server has faced an internal error that is not fatal.
+
+
+
+Rinne [Page 9]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+ 699 Unknown error.
+
+ RWP server has faced an unknown error that is not fatal.
+
+5. RWP Compliant Software
+
+ Simple RWP 1.0 compliant server and client software RWrite-1.1 will
+ be available during the fall 1994.
+
+6. Security of RWP
+
+ RWP version 1.0 does not offer any mean to verify the identity of the
+ user connecting the RWP server program. It's possible to identify
+ the sender using ident-service, but not all hosts currently support
+ that. This vulnerability is analogous with the weakness of the SMTP
+ protocol. Cryptographic user verification and message hiding method
+ is under development and is to be defined in RWP version 2.0 during
+ the year 1995.
+
+ RWP server also may offer a way to the intruder to get to know user
+ ids within the target host by trying the TO and VRFY commands. This
+ vulnerability is also present in SMTP. It is however possible to
+ build servers so that they never give message 671 (no such user) but
+ use response 670 (user not logged in) instead.
+
+ Another way to increase security even within RWP-1.0 described in the
+ document is to design RWP servers so that they do not deliver
+ messages directly to user but instead connect to some kind of RWP
+ agent process that is executed by each user willing to receive RWP
+ messages. This user configurable message agent could then decide
+ whether to deliver the message to the user and which way of delivery
+ to use. Message agent is the best way to prevent hostile user from
+ sending uncontrolled message flood to the user's terminal.
+
+ Sample implementation (RWrite-1.0) of the RWP server includes the
+ support for user configuration files in which each user can either
+ allow or deny messages from some user(s), host(s) or network
+ domains(s). Support for message agents is currently under
+ development.
+
+ The user that is receiving the message should be able to define
+ characters to be stripped from the incoming messages to prevent
+ terminal mess-up.
+
+
+
+
+
+
+
+
+Rinne [Page 10]
+
+RFC 1756 Remote Write Protocol January 1995
+
+
+7. RWP Connection Type
+
+ It is suggested that tcp (and udp) port 18 should be allocated for
+ rwp in future versions of RFCs listing the reserved tcp/udp/rpc
+ ports. Currently port 18 is assigned to the service called Message
+ Send Protocol (msp) that is not known to be implemented. Actually
+ port 18 is not currently defined at all in the /etc/services -file of
+ the any common UNIX-like system. Entry for /etc/services -file is as
+ follows
+
+ rwrite 18/udp # RWP rwrite
+ rwrite 18/tcp # RWP rwrite
+
+ Given that RWP compliant daemon program is /usr/sbin/rwrited the
+ entry for /etc/inetd.conf -file would be:
+
+ rwrite stream tcp nowait nobody /usr/sbin/rwrited rwrited
+
+8. Character quotation
+
+ To offer a safe method to transfer various character sets RWP defines
+ a method to quote characters in both message and autoreply. RWP uses
+ quotation similar to MIME `quoted-printable' encoding. Quoted
+ character is presented as a '=' -sign followed by a two character hex
+ code. This means also that all '='-signs have to be quoted.
+ Quotation is also needed when message contains a line with only a
+ single dot '.' in it.
+
+ For example:
+ '.' -> =2E
+ '=' -> =3D
+ '\a' -> =07
+ '\t' -> =09
+
+9. Security Considerations
+
+ Security issues are not discussed in this memo.
+
+10. Author's Address
+
+ Timo J. Rinne
+ Helsinki University of Technology.
+ Cirion oy
+ PO-BOX 250
+ FIN-00121
+ Helsinki, Finland
+
+ EMail: Timo.Rinne@hut.fi
+
+
+
+Rinne [Page 11]
+