idnits 2.17.1 draft-ietf-notary-mime-report-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 49 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 16, 1995) is 10686 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 54 looks like a reference -- Missing reference section? '1' on line 127 looks like a reference -- Missing reference section? '5' on line 101 looks like a reference -- Missing reference section? '2' on line 130 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 2 Internet Draft Octel Network Services 3 Expires: July 16, 1995 January 16, 1995 5 The Multipart/Report Content Type 6 for the Reporting of 7 Mail System Administrative Messages 9 11 Changes since last revision: 13 1) Multipart/Report is required to be the outermost MIME content-type to 14 facilitate automatic detection and processing by a UA via RFC 822 header 15 parsing. 17 2) The third section of the multipart may be any labeled MIME content-type 18 necessary to return the content of the message. 20 3) A new mime content type is defined for the return of the headers only in 21 the third body part. While headers are a subset of the Message/RFC822 22 content-type, the semantics are different. 24 1. Status of this Memo 26 This document is an Internet Draft. Internet Drafts are working documents 27 of the Internet Engineering Task Force (IETF), its Areas, and its Working 28 Groups. Note that other groups may also distribute working documents as 29 Internet Drafts. 31 Internet Drafts are valid for a maximum of six months and may be updated, 32 replaced, or obsoleted by other documents at any time. It is inappropriate 33 to use Internet Drafts as reference material or to cite them other than as 34 a "work in progress". 36 2. The multipart/report MIME content-type 38 The multipart/report MIME content-type is a general "family" or "container" 39 type for electronic mail reports of any kind. Although this memo defines 40 only the use of the multipart/report content-type with respect to delivery 41 status reports, mail processing programs will benefit if a single content- 42 Internet Draft Multipart/Report 1/16/95 44 The multipart/report content-type is defined as follows: 46 MIME type name: multipart 47 MIME subtype name: report 48 Required parameters: boundary, report-type 49 Optional parameters: none 50 Encoding considerations: 7bit should always be adequate 51 Security considerations: see section 7 of this memo. 53 The syntax of multipart/Report is identical to the Multipart/Mixed content 54 type defined in [3]. When used to send a report, the multipart/report 55 content-type must be the top-level MIME content type for any report 56 message. 58 A user agents and gateways must be able to automatically determine 59 that a message is a mail system report and should be processed as 60 such. Placing the multipart/report as the outermost content provides 61 a mechanism whereby an auto-processor may detect through parsing the 62 RFC 822 headers that the message is a report. 64 The multipart/report content-type contains either two or three sub-parts, 65 in the following order: 67 (1) [required] The first body part is a text/plain body part containing 68 explanatory text. This text may be in any MIME standards-track 69 charset, and in any language. The purpose of this text is to provide, 70 for a human reader who may not have an user agent capable of 71 interpreting a message/report, an easily-understood description of the 72 condition(s) that caused the report to be generated. 74 This body part may also be used to send detailed trace information that 75 cannot be easily formatted into a message/report body part. 77 (2) [required] A message/report body part containing an account of the 78 reported message handling event. The purpose of this body part is to 79 provide a machine-readable description of the condition(s) which caused 80 the report to be generated, along with details not present in the 81 text/plain body part that may be useful to human experts. 83 (3) [optional] A body part containing the returned message or a portion 84 thereof. This information may be useful to aid human experts in 85 diagnosing problems. (Although it may also be useful to allow the 86 sender to identify the message which the report was issued, it is hoped 87 that the envelope-id and original-recipient-address returned in the 88 message/report body part will replace the traditional use of the 89 returned content for this purpose.) 91 The Message/Report body part contains the specific service report 92 information, such as error reports, read-receipts, and service reports. 93 This content-type is defined in [1]. 95 Return of content may be wasteful of network bandwidth and a variety of 96 implementation strategies can be used. Generally the sender should choose 97 the appropriate strategy and inform the recipient of the required level of 98 Internet Draft Multipart/Report 1/16/95 100 returned content required. In the absence of an explicit request for level 101 of return of content such as that provided in [5], the agent which 102 generated the delivery service report should return the full message 103 content. 105 The Message/RFC822-Headers MIME content-type 3. 107 The Message/RFC822-Headers MIME content-type provides a mechanism to label 108 and return only the headers of a failed message. These headers are not the 109 complete message and should not be returned as a Message/RFC822. The 110 returned headers are useful for correlating the erred message and for 111 diagnostics based on the received-from: lines. 113 The Message/RFC822-Headers content-type is defined as follows: 115 MIME type name: Message 116 MIME subtype name: RFC822-Headers 117 Required parameters: None 118 Optional parameters: none 119 Encoding considerations: 7 bit is sufficient 120 Security considerations: see section 7 of this memo. 122 The message/RFC822-headers body part must contain all the RFC822 header 123 lines from the message which caused the report. 125 References 4. 127 [1] Moore, K., Vaudreuil, G., "An Extensible Message Format for Delivery 128 Status Reports", Internet-Draft. 130 [2] Crocker, D., "Standard for the format of ARPA Internet Text Messages", 131 STD 11, RFC 822, UDEL, August 1982. 133 [3 Borenstein, N., Freed, N., "Multipurpose Internet Mail Extensions", RFC 134 1341, Bellcore, Innosoft, June 1992. 136 Security Consideration 5. 138 Multipart/Report introduces no security threats beyond those already 139 present in Internet mail. Automated use of report types without 140 authentication may increase the opportunities for denial-of-service 141 attacks. 143 6. Author's Address 145 Gregory M. Vaudreuil 146 Octel Network Services 147 17060 Dallas Parkway 148 Dallas, TX 75248-1905 149 Greg.Vaudreuil@ONS.Octel.com