doc: Add RFC documents

1 files changed, 227 insertions, 0 deletions

diff --git a/doc/rfc/rfc1090.txt b/doc/rfc/rfc1090.txt
new file mode 100644
index 0000000..67fd3c1
--- /dev/null
+++ b/doc/rfc/rfc1090.txt
@@ -0,0 +1,227 @@
+
+
+
+
+
+
+Network Working Group                                         R. Ullmann
+Request for Comments: 1090                          Prime Computer, Inc.
+                                                           February 1989
+
+
+                              SMTP on X.25
+
+1. Status of this Memo
+
+   This memo proposes a standard for SMTP on the virtual circuit
+   facility provided by the X.25 standard of the CCITT.
+
+   Distribution of this memo is unlimited.
+
+2. Introduction
+
+   The possibility of using the X.25 virtual circuit (ISO level 3)
+   directly for SMTP is mentioned in RFC 821 ("SIMPLE MAIL TRANSPORT
+   PROTOCOL"), in appendix D.  It suggests that "a reliable end-to-end
+   protocol such as TCP be used on top of X.25 connections".  This was
+   undoubtedly true considering the general reliability of the PSDNs at
+   the time (1981).  The service is now (in 1989) reliable enough to
+   allow practical direct use of the virtual circuit service.
+
+   The procedures given here have proven to be successful in extensive
+   production use, involving 24 PSDNs in 22 different countries.  The
+   resulting service is economical even using some of the more expensive
+   PSDNs.  Operation over private X.25 connections and X.25 LANs has
+   also proven successful.
+
+   An X.25 virtual circuit (VC) is opened for each SMTP session.  The
+   full duplex channel provided by the VC is used for the session.  The
+   VC is then closed, normally by the calling side.
+
+3. Protocol ID and Call User Data
+
+   The first four octets (bytes) of the Call User Data Field, which are
+   commonly used as a protocol identifier, or PRID, should be (hex)
+   C0F70000.  (In decimal, 192 247 0 0.)
+
+   Implementations should, however, provide the ability to configure the
+   call user data on a per-address basis, including the protocol ID
+   field.
+
+4. Data stream
+
+   The SMTP data is divided into (streamed into) packets in any way the
+   sending side prefers.  Sequences with the M bit (more data) set are
+
+
+
+Ullmann                                                         [Page 1]
+
+RFC 1090                      SMTP on X.25                 February 1989
+
+
+   encouraged, and may be up to 2048 bytes in total length.
+
+   It is recommended that SMTP commands and responses be sent as single
+   packets, or single more-data sequences, if only to facilitate
+   debugging the protocol.  This is not a requirement.
+
+5. Qualified data
+
+   Packets with the Q bit set and interrupt packets are not used, and
+   should be ignored if received.
+
+6. Circuit resets
+
+   If a level 3 circuit reset is received, the VC should be cleared, and
+   the SMTP connection attempted again.  The retry may be after some
+   delay, and may be with different call facilities.
+
+7. Call facilities
+
+   Any negotiable features selected by the X.25 call request facilities
+   field may be used.  Implementations should provide the ability to
+   specify facilities for each called address.
+
+8. Character code
+
+   The character code used on X.25 is the full ASCII-8 code, with no
+   escapes or modifications.  Lines are terminated by CRLF (13 10
+   decimal).  Implementations should, if possible, recognize lines
+   terminated only by LF (10 decimal).
+
+9. Closing the connection
+
+   Unlike TCP, X.25 does not provide for synchronous delivery of data in
+   transit when a clear request is in progress; any packets in transit
+   are discarded when the VC is cleared.  Therefore, on X.25, the SMTP
+   session layer is closed by the calling side when the Service Closing
+   message is received, either in response to a QUIT command, or because
+   the service must shut down.
+
+10. Timeouts
+
+   SMTP does not normally provide for timing out a session.  On X.25,
+   the following has proven to be effective:
+
+      10.1. call request
+
+         If a call accept is not received within 100 seconds, or the
+         Service Ready message is not received within (another) 120
+
+
+
+Ullmann                                                         [Page 2]
+
+RFC 1090                      SMTP on X.25                 February 1989
+
+
+         seconds, the call should be cleared and retried later.
+
+      10.2. established
+
+         After the protocol session is established, the circuit should
+         be cleared if no response is received for 10 minutes.
+
+      10.3. closing
+
+         After the QUIT command is issued, the timeout should be
+         shortened to 20 seconds.  This will sometimes cause an
+         ungraceful exit, but this will not affect the SMTP transactions
+         already completed.
+
+      10.4. clearing
+
+         When the X.25 Clear Request packet has been sent, the VC should
+         be timed out in accordance with the X.25 protocol
+         specification.
+
+      11. Other features
+
+         Other features of X.25, such as permanent virtual circuits and
+         D bit selection, are not used.
+
+References
+
+     [1]  Postel, J., "Simple Mail Transfer Protocol", RFC 821, USC
+          Information Sciences Institute, August 1982.
+
+     [2]  CCITT Recommendation X.25, "Interface Between Data
+          Terminal Equipment (DTE) and Data Circuit-Terminating
+          Equipment (DCE) for Terminals Operating in the Packet
+          Mode and Connected to Public Data Networks by Dedicated
+          Circuit", International Telegraph and Telephone Consultative
+          Committee, Fascicle VIII.3, Geneva, 1976; amended at
+          Geneva, 1980 and Malaga-Torremolinos, 1984. ("Red Book")
+
+Author's Address
+
+   Robert Ullmann 23A-32
+   Prime Computer, Inc.
+   Technology Drive
+   Milford, MA 01757
+
+   Phone: +1 508 478 8600 x1736
+
+   Email: Ariel@Relay.Prime.COM
+
+
+
+Ullmann                                                         [Page 3]
+
+RFC 1090                      SMTP on X.25                 February 1989
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ullmann                                                         [Page 4]
+
\ No newline at end of file