Remove RFCs from the trunk, since we don't distribute them anyways. All of the removed RFCs are listed in the design-notes.html file, with the exception of NNTP (RFC977). Also add a link to the "LAN Mail Protocols" document to the design-notes.html file.

svn path=/trunk/; revision=4013

1 files changed, 0 insertions, 227 deletions

diff --git a/RFC/rfc1892.txt b/RFC/rfc1892.txt
deleted file mode 100644
index c4bdbd5f..00000000
--- a/RFC/rfc1892.txt
+++ /dev/null
@@ -1,227 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                       G. Vaudreuil
-Request for Comments: 1892                        Octel Network Services
-Category: Standards Track                                   January 1996
-
-
-                   The Multipart/Report Content Type
-                          for the Reporting of
-                  Mail System Administrative Messages
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  Distribution of this memo is unlimited.
-
-1. The Multipart/Report MIME content-type
-
-   The Multipart/Report MIME content-type is a general "family" or
-   "container" type for electronic mail reports of any kind. Although
-   this memo defines only the use of the Multipart/Report content-type
-   with respect to delivery status reports, mail processing programs
-   will benefit if a single content-type is used to for all kinds of
-   reports.
-
-   The Multipart/Report content-type is defined as follows:
-
-             MIME type name: multipart
-             MIME subtype name: report
-             Required parameters: boundary, report-type
-             Optional parameters: none
-             Encoding considerations: 7bit should always be adequate
-             Security considerations: see section 4 of this memo.
-
-   The syntax of Multipart/Report is identical to the Multipart/Mixed
-   content type defined in [MIME].  When used to send a report, the
-   Multipart/Report content-type must be the top-level MIME content type
-   for any report message.  The report-type parameter identifies the
-   type of report.  The parameter is the MIME content sub-type of the
-   second body part of the Multipart/Report.
-
-      User agents and gateways must be able to automatically determine
-      that a message is a mail system report and should be processed as
-      such.  Placing the Multipart/Report as the outermost content
-      provides a mechanism whereby an auto-processor may detect through
-      parsing the RFC 822 headers that the message is a report.
-
-
-
-
-Vaudreuil                   Standards Track                     [Page 1]
-
-RFC 1892                    Multipart/Report                January 1996
-
-
-   The Multipart/Report content-type contains either two or three sub-
-   parts, in the following order:
-
-   (1) [required]  The first body part contains human readable message.
-       The purpose of this message is to provide an easily-understood
-       description of the condition(s) that caused the report to be
-       generated, for a human reader who may not have an user agent
-       capable of interpreting the second section of the
-       Multipart/Report.
-
-       The text in the first section may be in any MIME standards-track
-       content-type, charset, or language.  Where a description of the
-       error is desired in several languages or several media, a
-       Multipart/Alternative construct may be used.
-
-       This body part may also be used to send detailed information
-       that cannot be easily formatted into a Message/Report body part.
-
-   (2) [required]  A machine parsable body part containing an account
-       of the reported message handling event. The purpose of this body
-       part is to provide a machine-readable description of the
-       condition(s) which caused the report to be generated, along with
-       details not present in the first body part that may be useful to
-       human experts.  An initial body part, Message/delivery-status is
-       defined in [DSN]
-
-   (3) [optional]  A body part containing the returned message or a
-       portion thereof.  This information may be useful to aid human
-       experts in diagnosing problems.  (Although it may also be useful
-       to allow the sender to identify the message which the report was
-       issued, it is hoped that the envelope-id and original-recipient-
-       address returned in the Message/Report body part will replace
-       the traditional use of the returned content for this purpose.)
-
-   Return of content may be wasteful of network bandwidth and a variety
-   of implementation strategies can be used.  Generally the sender
-   should choose the appropriate strategy and inform the recipient of
-   the required level of returned content required.  In the absence of
-   an explicit request for level of return of content such as that
-   provided in [DRPT], the agent which generated the delivery service
-   report should return the full message content.
-
-   When data not encoded in 7 bits is to be returned, and the return
-   path is not guaranteed to be 8-bit capable, two options are
-   available.  The origional message MAY be reencoded into a legal 7 bit
-   MIME message or the Text/RFC822-Headers content-type MAY be used to
-   return only the origional message headers.
-
-
-
-
-Vaudreuil                   Standards Track                     [Page 2]
-
-RFC 1892                    Multipart/Report                January 1996
-
-
-2. The Text/RFC822-Headers MIME content-type
-
-   The Text/RFC822-Headers MIME content-type provides a mechanism to
-   label and return only the RFC 822 headers of a failed message.  These
-   headers are not the complete message and should not be returned as a
-   Message/RFC822.  The returned headers are useful for identifying the
-   failed message and for diagnostics based on the received: lines.
-
-   The Text/RFC822-Headers content-type is defined as follows:
-
-          MIME type name: Text
-          MIME subtype name: RFC822-Headers
-          Required parameters: None
-          Optional parameters: none
-          Encoding considerations: 7 bit is sufficient for normal RFC822
-                 headers, however, if the headers are broken and require
-                 encoding, they may be encoded in quoted-printable.
-          Security considerations: see section 4 of this memo.
-
-   The Text/RFC822-headers body part should contain all the RFC822
-   header lines from the message which caused the report.  The RFC822
-   headers include all lines prior to the blank line in the message.
-   They include the MIME-Version and MIME Content- headers.
-
-3. References
-
-   [DSN] Moore, K., and G. Vaudreuil, "An Extensible Message Format for
-       Delivery Status Notifications", RFC 1894, University of
-       Tennessee, Octel Network Services, January 1996.
-
-   [RFC822] Crocker, D., "Standard for the format of ARPA Internet Text
-       Messages", STD 11, RFC 822, UDEL, August 1982.
-
-   [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
-       Extensions", RFC 1521, Bellcore, Innosoft, June 1992.
-
-   [DRPT] Moore, K., "SMTP Service Extension for Delivery Status
-       Notifications", RFC 1891, University of Tennessee, January 1996.
-
-4. Security Considerations
-
-   Automated use of report types without authentication presents several
-   security issues.  Forging negative reports presents the opportunity
-   for denial-of-service attacks when the reports are used for automated
-   maintenance of directories or mailing lists.  Forging positive
-   reports may cause the sender to incorrectly believe a message was
-   delivered when it was not.
-
-
-
-
-Vaudreuil                   Standards Track                     [Page 3]
-
-RFC 1892                    Multipart/Report                January 1996
-
-
-5. Author's Address
-
-   Gregory M. Vaudreuil
-   Octel Network Services
-   17060 Dallas Parkway
-   Dallas, TX 75248-1905
-
-   Phone: +1-214-733-2722
-   EMail: Greg.Vaudreuil@Octel.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Vaudreuil                   Standards Track                     [Page 4]
-