idnits 2.17.1 draft-ietf-mhtml-info-11.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == 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 1279 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 40 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (March 1999) is 9171 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) == Unused Reference: 'HOSTS' is defined on line 1192, but no explicit reference was found in the text == Unused Reference: 'MIDCID' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'MIME2' is defined on line 1214, but no explicit reference was found in the text == Unused Reference: 'NEWS' is defined on line 1218, but no explicit reference was found in the text == Unused Reference: 'REL' is defined on line 1221, but no explicit reference was found in the text == Unused Reference: 'RELURL' is defined on line 1225, but no explicit reference was found in the text == Unused Reference: 'RFC822' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'SMTP' is defined on line 1231, but no explicit reference was found in the text == Unused Reference: 'URL' is defined on line 1234, but no explicit reference was found in the text == Unused Reference: 'URLBODY' is defined on line 1237, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1806 (ref. 'CONDISP') (Obsoleted by RFC 2183) ** Obsolete normative reference: RFC 1866 (ref. 'HTML2') (Obsoleted by RFC 2854) ** Downref: Normative reference to an Informational RFC: RFC 1945 (ref. 'HTTP') == Outdated reference: A later version (-07) exists of draft-ietf-mhtml-rev-02 ** Obsolete normative reference: RFC 1036 (ref. 'NEWS') (Obsoleted by RFC 5536, RFC 5537) -- Possible downref: Non-RFC (?) normative reference: ref. 'REL' ** Obsolete normative reference: RFC 1808 (ref. 'RELURL') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1738 (ref. 'URL') (Obsoleted by RFC 4248, RFC 4266) Summary: 15 errors (**), 0 flaws (~~), 14 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Jacob Palme 2 Internet Draft Stockholm University/KTH 3 draft-ietf-mhtml-info-11.txt Category-to-be: Informational 4 Expires: September 1998 March 1999 6 Sending HTML in MIME, an informational supplement to the RFC: 7 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance 12 with all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet- 22 Drafts as reference material or to cite them other than as 23 "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Copyright (C) The Internet Society 1998. All Rights Reserved. 33 1. Abstract 35 The memo "MIME Encapsulation of Aggregate Documents, such as HTML 36 (MHTML)" (draft-ietf-mhtml-rev-05.txt) specifies how to send packaged 37 aggregate HTML objects in MIME format. This memo is an accompanying 38 informational document, intended to be an aid to developers. This 39 document is not an Internet standard. 41 Issues discussed are implementation methods, caching strategies, problems 42 with rewriting of URIs, making messages suitable both for mailers which 43 can and which cannot handle Multipart/related and handling recipients 44 which do not have full Internet connectivity. 46 The latest version of this document is available in HTML format at: 47 http://www.dsv.su.se/~jpalme/ietf/mhtml-info.html 49 Differences from the previous versions 9 and 10 of this draft 51 (1) A paragraph about one disadvantage with MAILTO action elements has 52 been added to section 10. 54 (2) A new section 13: Default font size has been added 56 (3) A new temporary section "Issue list" immediately below has been added 58 Issue list 60 Section in Issue description 61 this draft 63 4 Should some more method of communication between html 64 viewer and e-mail program be described? Are the methods 65 correctly described? 67 5 Are there any more problems with rewriting URIs which 68 should be described in section 5? 70 8 Is it OK to say that senders should not assume that 71 recipients will show the value of Content-Description 72 inside Multipart/Related (since HTML has other methods of 73 showing this, for example the