idnits 2.17.1 draft-ietf-notary-mime-report-00.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-24) 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 1 longer page, the longest (page 1) being 60 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 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 28 instances of too long lines in the document, the longest one being 42 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 (August 1, 1994) is 10859 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? '1' on line 67 looks like a reference -- Missing reference section? '2' on line 70 looks like a reference -- Missing reference section? '3' on line 73 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 5 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: 1-25-95 August 1, 1994 4 Multipart/Report 6 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working documents 11 of the Internet Engineering Task Force (IETF), its Areas, and its Working 12 Groups. Note that other groups may also distribute working documents as 13 Internet Drafts. 15 Internet Drafts are valid for a maximum of six months and may be updated, 16 replaced, or obsoleted by other documents at any time. It is inappropriate 17 to use Internet Drafts as reference material or to cite them other than as 18 a "work in progress". 20 1. Introduction 22 This memo defines a generic packaging mechanism for mail system reports. 23 The Multipart/Report is a convention for interpersonal message 24 notifications for MIME. 26 2. Multipart/Report 28 Mime type name: Multipart 29 Mime Sub-Type name: Report 30 Required Parameters: Boundary, Report-type 31 Optional Parameters: None 32 Encoding Considerations: 7bit should always be adequate. 34 The syntax of a Multipart/Report is identical to the Multipart\Mixed 35 content type. The Report may contain up to three body parts. The 36 Multipart/Report must always be the outer-most MIME content. The semantics 37 of a Multipart/Report which is not the outermost content type such as a 38 forwarded Multipart/Report are undefined. The report-type parameter 39 indicates the type of Report. Expected Report types include delivery 40 status and read receipts. 42 The Multipart/Report is required to be the outermost content type so 43 that existing final delivery agents which can route messages based on 44 RFC 822 heasder fields may detect the multipart/report header and 45 provide automated processing of reports. 47 The first body part is intended to be a single text/plain or 48 multipart/alternative set of text/plain body parts describing the report in 49 human readable form. This text may be in any character set or language as 50 appropriate for the environment. 52 The second body part is a machine parseable description of the Report such 53 as a message/delivery-report. This body part is described in a separate 54 report is to be privacy enhanced, this body part may be packaged in a a 55 multi-part security content. 57 Note that multipart security body parts which operate on the entirity 58 of the multipart/report will violate the reqirement that the 59 multipart/report be the top-level content-type on the message. 61 The third body part may be of any content-type and contains the returned 62 message for which the delivery report is defined. This may include 63 Message/RFC822 but is not restricted to be such. 65 References 3. 67 [1] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", 68 STD 11, RFC 822, UDEL, August 1982. 70 [2] Borenstein, N., Freed, N. "Multipurpose Internet Mail Extensions", RFC 71 1341, Bellcore, Innosoft, June 1992. 73 [3] Moore, K., Vaudreuil, G., An Extensible Message Format for Delivery `` 74 Status Reports'' , Internet-Draft, Work In Progress. 76 4. Security Consideration 78 Multipart/Report introduces no security threats beyond those already 79 present in Internet mail. Automated use of report types without 80 authentication may present opportunities for denial-of-service attacks. 82 5. Author's Address 84 Gregory M. Vaudreuil 85 Octel Network Services 86 17080 Dallas Parkway 87 Dallas, TX 75248-1905 88 USA 89 Greg.Vaudreuil@Octel.Com