diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt | 784 | ||||
| -rw-r--r-- | Documentation/en/I-D/draft-palme-mhtml-info-01.txt | 1446 | ||||
| -rw-r--r-- | Documentation/en/I-D/index.html | 289 |
3 files changed, 2389 insertions, 130 deletions
diff --git a/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt b/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt new file mode 100644 index 00000000..4217b315 --- /dev/null +++ b/Documentation/en/I-D/draft-klyne-msghdr-registry-01.txt @@ -0,0 +1,784 @@ + + +Network Working Group G. Klyne +Internet-Draft MIMEsweeper Group +Expires: July 5, 2002 Jan 4, 2002 + + + Registration procedures for message headers + draft-klyne-msghdr-registry-01 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on July 5, 2002. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This specification defines registration procedures for the message + headers used by Internet mail, newsgroup feeds, HTTP and other + Internet applications. + +Discussion of this document + + Please send comments to <ietf-822@imc.org>. To subscribe to this + list, send a message with the body 'subscribe' to <ietf-822- + request@imc.org>. + + + + + + +Klyne Expires July 5, 2002 [Page 1] + +Internet-Draft Message header registration Jan 2002 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Structure of this document . . . . . . . . . . . . . . . . . 3 + 1.2 Document terminology and conventions . . . . . . . . . . . . 4 + 2. Message headers . . . . . . . . . . . . . . . . . . . . . . 4 + 2.1 Standard and non-standard headers . . . . . . . . . . . . . 4 + 2.2 Definitions of message headers . . . . . . . . . . . . . . . 5 + 2.2.1 Application-specific message headers . . . . . . . . . . . . 5 + 3. Registration procedure . . . . . . . . . . . . . . . . . . . 5 + 3.1 Header specification . . . . . . . . . . . . . . . . . . . . 6 + 3.2 Registration templates . . . . . . . . . . . . . . . . . . . 6 + 3.2.1 Normative header template . . . . . . . . . . . . . . . . . 6 + 3.2.2 Provisional header template . . . . . . . . . . . . . . . . 7 + 3.3 Submission of registration . . . . . . . . . . . . . . . . . 8 + 3.4 Change control . . . . . . . . . . . . . . . . . . . . . . . 8 + 3.5 Comments on header definitions . . . . . . . . . . . . . . . 8 + 3.6 Location of message header registry . . . . . . . . . . . . 9 + 4. Initial registrations . . . . . . . . . . . . . . . . . . . 9 + 5. IANA considerations . . . . . . . . . . . . . . . . . . . . 9 + 6. Security considerations . . . . . . . . . . . . . . . . . . 9 + 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 + References . . . . . . . . . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . 12 + A. Revision history . . . . . . . . . . . . . . . . . . . . . . 12 + A.1 draft-klyne-msghdr-registry-01 . . . . . . . . . . . . . . . 12 + A.2 draft-klyne-msghdr-registry-00 . . . . . . . . . . . . . . . 12 + B. Todo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 + + + + + + + + + + + + + + + + + + + + + + +Klyne Expires July 5, 2002 [Page 2] + +Internet-Draft Message header registration Jan 2002 + + +1. Introduction + + This specification defines registration procedures for the message + headers used by Internet mail, newsgroup feeds, HTTP and other + Internet applications. + + Benefits of a central registry for message headers include: + + o to provide a single point of reference for standardized headers; + + o to provide a central point of discovery for established headers, + and easy location of their defining documents; + + o to discourage multiple definitions of a header name for different + purposes; + + o to help those proposing new headers discern established trends and + conventions, and avoid names that might be confused with existing + ones; + + o to encourage convergence of header name usage across multiple + applications/protocols. + + The primary specification for Internet message headers is the + Internet mail message format specification, RFC 2822 [22], but there + are many other Internet standards track documents that define + additional headers within the same namespace, notably MIME [7] and + related specifications. Other Internet applications that use MIME, + such as newsgroup feeds (RFC 1036 [1]) and HTTP web access (RFC 2616 + [19]), also use many of the same headers. + + Although in principle each application defines its own set of valid + headers, exchange of messages between applications (e.g. mail to + news gateways), common use of MIME encapsulation, and the possibility + of common processing for various message types (e.g. a common + message archive and retrieval facility) makes it desirable to have a + single point of reference for standardized headers. The message + header registry defined here serves that purpose. + +1.1 Structure of this document + + Section Section 2 discusses the purpose of this specification, and + indicates some sources of information about defined message headers. + + Section Section 3 defines the message header registry, and sets out + requirements and procedures for creating entries in it. + + + + + +Klyne Expires July 5, 2002 [Page 3] + +Internet-Draft Message header registration Jan 2002 + + +1.2 Document terminology and conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [10]. + + NOTE: indented comments like this provide additional nonessential + information about the rationale behind this document. + + [[[Editorial comments and questions about outstanding issues are + provided in triple brackets like this. These working comments should + be resolved and removed prior to final publication.]]] + +2. Message headers + +2.1 Standard and non-standard headers + + Many message headers are defined in standards-track documents, which + means they have been subjected to a process of community review and + achieved consensus that they provide a useful and well-founded + capability. Many other headers have been defined and adopted for + private use; some of these have found widespread use. + + The registry defined here is intended to cater for all of these + headers, while maintaining a clear distinction and status for those + which have community consensus. To this end, the registry is defined + in two parts (or maybe as two separate registries): + + o Normative Message Headers, intended for headers defined in IETF + standards-track documents, or those that have achieved a + comparable level of community review. The assignment policy for + such registration is "IETF Consensus", as defined by RFC 2434 + [18]. + + o Provisional Message Headers, intended for any header proposed by + any developer, without making any claim about the usefulness + quality of its definition. The assignment policy for registration + of these is "Private Use", per RFC 2434 [18]. + + Note that there exist at least two other sources information about + message headers: + + o RFC 2076 [8], as updated [25], contains a list of commonly used + message headers, and + + o Dan Bernstein maintains a list of standard and non-standard mail + message headers [26]. + + + + +Klyne Expires July 5, 2002 [Page 4] + +Internet-Draft Message header registration Jan 2002 + + +2.2 Definitions of message headers + + RFC 2822 [22] defines a general syntax for Internet message headers. + It also defines a number of headers for use with Internet mail. + Additional header names are defined in a variety of standards-track + RFC documents, including: RFC 1036 [1], RFC 1496 [2], RFC 1505 [3], + RFC 1766 [5], RFC 1864 [6], RFC 2156 [12], RFC 2183 [13], RFC 2045 + [7], RFC 2110 [9], RFC 2298 [14], RFC 2369 [15], RFC 2421 [17], RFC + 2616 [19], RFC 2821 [21], RFC 2912 [23] and RFC 2919 [24]. + +2.2.1 Application-specific message headers + + Internet applications that use message headers include Internet mail + [21][22], NNTP newsgroup feeds [1], HTTP web access [19] and any + other that uses MIME [7] encapsulation of message content. + + In some cases (notably HTTP [19]), the header syntax and usage is + redefined for the specific application. This registration is + concerned only with the allocation and specification of header names, + and not with the details of header implementation in specific + protocols. + + In some cases, the same header name may be specified differently (by + different documents) for use with different application protocols + [[[example?]]]. In other cases, a header name may have a common + specification across multiple protocols (ignoring protocol-specific + lexical and character set conventions); e.g. this is generally the + case for MIME headers with names of the form 'Content-*'. + + Thus, we need to accommodate application-specific headers, while + recognizing the commonality of other headers across multiple + applications. Common registries are used for all applications, and + each registered header specifies the application protocol(s) for + which the registered definition applies. A given header name may + have multiple registry entries for different protocols; in the + Normative Message Headers registry, a given header name may be + registered only once for any given protocol. + +3. Registration procedure + + The procedure for registering a message header is: + + 1. Construct a header specification + + 2. Prepare a registration template + + 3. Submit the registration template + + + + +Klyne Expires July 5, 2002 [Page 5] + +Internet-Draft Message header registration Jan 2002 + + +3.1 Header specification + + Registration of a new message header starts with construction of a + proposal that describes the syntax, semantics and intended use of the + header. This proposal MUST be published as an RFC. + + A registered header name MUST conform at least to the syntax defined + by RFC 2822, section 3.6.8, for "field name". + + Further, the "." character is reserved to indicate a naming sub- + structure and MUST NOT be included in any registered header name. + Currently, no specific sub-structure is defined; if used, any such + structure MUST be defined by a standards track RFC document. + + It is further RECOMMENDED that characters in a registered message + header name are restricted to those characters that can be used + without escaping in a URI [16] or URN [11], namely upper- or lower- + case ASCII letters, decimal digits, "(", ")", "+", ",", "-", "=", + "@", ";", "$", "_", "!", "*" and "'". Of course, a header name must + also conform to any applicable rules of the protocol(s) with which it + may be used. Many headers names may find some use in conjunction + with XML, in which case the name characters should be further + restricted to just letters, digits, hyphen ('-') and underscore ('_') + characters, with the first character being a letter or underscore. + +3.2 Registration templates + + The registration template for a message header may be contained in + the defining document, or prepared separately. + +3.2.1 Normative header template + + An header registered as a Normative Message Header MUST be defined + according to "IETF Consensus" rules (per RFC 2434 [18]), and MUST + have a name which is unique among all the Normative Message Headers + that may be used with the same application protocol(s). The header + name MUST NOT start with "X-" or "x-". + + The registration template contains the following information: + + NORMATIVE HEADER REGISTRATION TEMPLATE: + + Header name: + The name requested for the new header. This MUST conform to the + header specification details above. + + Applicable protocol(s): + Specify "mail", "news", "http", or cite any other standards-track + + + +Klyne Expires July 5, 2002 [Page 6] + +Internet-Draft Message header registration Jan 2002 + + + RFC defining the protocol with which the header is intended to be + used. + Alternatively, specify "any" to indicate that there is no + specified restriction on the protocol with which the registered + header may be used; in this case, the header name must be unique + within the Normative Message Header registry. + + Specification document(s): + Reference to the RFC(s) that specify the header for use with the + indicated protocol(s). + + Related information: + Optionally, citations to additional documents containing further + relevant information. + + +3.2.2 Provisional header template + + Registration as a Provisional Message Header does not imply any kind + of endorsement by the IETF, IANA or any other body. + + The only requirement for a header to be registered as a Provisional + Message Header is that it MUST have a citable specification. + + The registration template contains the following information: + + PROVISIONAL HEADER REGISTRATION TEMPLATE: + + Header name: + The name requested for the new header. This SHOULD conform to the + header specification details above. + + Applicable protocol(s): + Specify "mail", "news", "http", or cite any other standards-track + RFC defining the protocol with which the header is intended to be + used. + Alternatively, specify "any" to indicate that there is no + specified restriction on the protocol with which the registered + header may be used. + + Specification document(s): + Reference to document(s) that specifies the header for use with + the indicated protocol(s). + + Related information: + Optionally, citations to additional documents containing further + relevant information. + + + + +Klyne Expires July 5, 2002 [Page 7] + +Internet-Draft Message header registration Jan 2002 + + + + The name and email address of the author, and person who may + authorize changes to or retraction of the registration. + + +3.3 Submission of registration + + The registration is submitted for incorporation in the IANA message + header registry by one of the following means: + + o An IANA considerations section in a defining RFC, calling for + registration of the message header and referencing the + registration template within the same document. Registration of + the header is processed as part of the RFC publication process. + + o Sending the registration template in an email to the designated + email address [27]. IANA will register the message header if the + requested name and the specification document meet the criteria + stated. + + +3.4 Change control + + Change control of a header registration is subject to the same + condition as the initial registration; i.e. publication of an IESG- + approved RFC for a Normative Message Header, or on request of the + indicated author/cgange controller for a Provisional Message Header. + + In addition, retraction of Provisional Message Header registration + may be requested by the IESG. + + It is intended that entries in the Normative Header Registry may be + used in the construction of URNs (per RFC 2141 [11]) which have + particular requirements for uniqueness and persistence (per RFC 1737 + [4]). Therefore, once an entry is made in the Normative Message + Header registry, the combination of the header name and any + applicable protcol MUST NOT subsequently be registered for any other + purpose. (This is not to preclude revision of the applicable + specification(s) within the appropriate IETF Consensus rules, and + corresponding updates to the specification citation in the header + registration.) + +3.5 Comments on header definitions + + [[[Review this]]] + + Comments on registered Normative Message Headers should be sent to + the IETF-822 email discussion list [27]. + + + +Klyne Expires July 5, 2002 [Page 8] + +Internet-Draft Message header registration Jan 2002 + + + Comments on proposed message headers should preferably be sent to the + discusion forum for the specification concerned. They may also be + sent to the IETF-822 list [27] if they concern wider implications + than are addressed by the specification document. + +3.6 Location of message header registry + + The message header registry is accessible from IANA's web site [28]. + +4. Initial registrations + + [[[I am currently minded to prepare two companion documents that + template the normative and provisional headers from RFC 2076, rather + than try to have them all in this document.]]] + + This specification calls for initial registration of all message + headers defined in existing standards-track documents. A list of + such headers can be found in RFC 2076 [8] and updates [25]. Section + Section 2.2 of this document contains a list of standards-track + specifications that define message headers. + + [[[Need to provide list of headers+documents here for initial + registration?]]] + +5. IANA considerations + + This specification calls for: + + o A new two-part IANA registry for message headers per section + Section 3 of this document. The policies for inclusion in the + registry are described in sections Section 3.1 and Section 3.2. + + o [[[Details TBD: Initial message header registrations, per section + Section 4 of this document.]]] + + +6. Security considerations + + No security considerations are introduced by this specification + beyond those already inherrent in the use of message headers. + +7. Acknowledgements + + The author gratefully acknowledges the contributions of: Charles + Lindsey, [[[...]]] + +References + + + + +Klyne Expires July 5, 2002 [Page 9] + +Internet-Draft Message header registration Jan 2002 + + + [1] Horton, M. and R. Adams, "Standard for interchange of USENET + messages", RFC 1036, December 1987. + + [2] Alvestrand, H., Jordan, K. and J. Romaguera, "Rules for + downgrading messages from X.400/88 to X.400/84 when MIME + content-types are present in the messages", RFC 1496, August + 1993. + + [3] Costanzo, A., Robinson, D. and R. Ullmann, "Encoding Header + Field for Internet Messages", RFC 1505, August 1993. + + [4] Masinter, L. and K. Sollins, "Functional Requirements for + Uniform Resource Names", RFC 1737, December 1994. + + [5] Alvestrand, H., "Tags for the Identification of Languages", RFC + 1766, March 1995. + + [6] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC + 1864, October 1995. + + [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message Bodies", + RFC 2045, November 1996. + + [8] Palme, J., "Common Internet Message Headers", RFC 2076, + February 1997. + + [9] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of + Aggregate Documents, such as HTML (MHTML)", RFC 2110, March + 1997. + + [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [11] Moats, R., "URN Syntax", RFC 2141, May 1997. + + [12] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping + between X.400 and RFC 822/MIME", RFC 2156, January 1998. + + [13] Moore, K., Troost, R. and S. Dorner, "Communicating + Presentation Information in Internet Messages: The Content- + Disposition Header Field", RFC 2183, August 1997. + + [14] Fajman, R., "An Extensible Message Format for Message + Disposition Notifications", RFC 2298, March 1998. + + [15] Baer, J. and G. Neufeld, "The Use of URLs as Meta-Syntax for + Core Mail List Commands and their Transport through Message + + + +Klyne Expires July 5, 2002 [Page 10] + +Internet-Draft Message header registration Jan 2002 + + + Header Fields", RFC 2369, July 1998. + + [16] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 2396, August + 1998. + + [17] Parsons, G. and G. Vaudreuil, "Voice Profile for Internet Mail + - version 2", RFC 2421, September 1998. + + [18] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + + [19] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., + Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- + HTTP/1.1", RFC 2616, June 1999. + + [20] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, + August 1999. + + [21] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April + 2001. + + [22] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + + [23] Klyne, G., "Indicating Media Features for MIME Content", RFC + 2912, September 2000. + + [24] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and + Namespace for the Identification of Mailing Lists", RFC 2919, + April 2001. + + [25] Palme, J., "Common Internet Message Header Fields", Internet + draft draft-palme-mailext-headers-05, May 2001, + <http://search.ietf.org/internet-drafts/draft-palme-mailext- + headers-05.txt>. + + [26] Bernstein, D., "Internet mail field name index", + <http://cr.yp.to/immhf/index.html>. + + [27] "Mail address for submission of header registration template", + <mailto:[[[ietf-message-headers]]]@iana.org>. + + [28] "IANA list of registered message headers", + <http://www.iana.org/[[[ToBeDefined]]]>. + + + + + + +Klyne Expires July 5, 2002 [Page 11] + +Internet-Draft Message header registration Jan 2002 + + +Author's Address + + Graham Klyne + MIMEsweeper Group + 1310 Waterside + Arlington Business Park + Theale, Reading RG7 4SA + UK + + Phone: +44 118 903 8000 + Fax: +44 118 903 9000 + EMail: Graham.Klyne@MIMEsweeper.com + +Appendix A. Revision history + + (This section to be removed on final publication) + +A.1 draft-klyne-msghdr-registry-01 + + 01a 04-Jan-2002: + + * In response to feedback from interested parties, expanded the + registry to cover Normative and Provisional message header + registrations. + + * Defined a formal role for the applicable protocol(s) in the + registry: the combination of header name and any applicable + protocol must be unique for a Normative Message Header. + + * Noted further constraints to the header name format for XML + name compatibility. + + * Fixed registration policy for a Normative Message Header to be + "IETF Consensus". + + +A.2 draft-klyne-msghdr-registry-00 + + 00a 27-Sep-2001: + + * Document initially created. + + +Appendix B. Todo + + (This section to be removed on final publication) + + o Finalize initial registrations. + + + +Klyne Expires July 5, 2002 [Page 12] + +Internet-Draft Message header registration Jan 2002 + + + o Finalize email address for submission of registration templates. + + o Finalize web address for registry. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Klyne Expires July 5, 2002 [Page 13] + +Internet-Draft Message header registration Jan 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Klyne Expires July 5, 2002 [Page 14] + diff --git a/Documentation/en/I-D/draft-palme-mhtml-info-01.txt b/Documentation/en/I-D/draft-palme-mhtml-info-01.txt new file mode 100644 index 00000000..6535bacd --- /dev/null +++ b/Documentation/en/I-D/draft-palme-mhtml-info-01.txt @@ -0,0 +1,1446 @@ +Network Working Group Jacob Palme +Internet Draft Stockholm +draft-palme-mhtml-info-01.txt University/KTH + December 2001 +Category-to-be: +Informational +Expires: June 2001 + + + + Sending HTML in MIME, + an informational supplement to the RFC: + MIME Encapsulation of Aggregate Documents, + such as HTML (MHTML) + + +Status of this Memo + + +This document is an Internet-Draft and is in full +conformance with all provisions of Section 10 of RFC2026. + +Internet-Drafts are working documents of the Internet +Engineering Task Force (IETF), its areas, and its working +groups. Note that other groups may also distribute working +documents as Internet-Drafts. + +Internet-Drafts are draft documents valid for a maximum of +six months and may be updated, replaced, or obsoleted by +other documents at any time. It is inappropriate to use +Internet- Drafts as reference material or to cite them +other than as "work in progress." + +The list of current Internet-Drafts can be accessed at +http://www.ietf.org/ietf/1id-abstracts.txt + +The list of Internet-Draft Shadow Directories can be +accessed at http://www.ietf.org/shadow.html. + +Copyright (C) The Internet Society 2001. All Rights +Reserved. + + +1. Abstract + +The memo "MIME Encapsulation of Aggregate Documents, such +as HTML (MHTML)" [RFC 2557] specifies how to send packaged +aggregate HTML objects in MIME format. This memo is an +accompanying informational document, intended to be an aid +to developers. This document is not an Internet standard. + +Issues discussed are implementation methods, caching +strategies, problems with rewriting of URIs, making +messages suitable both for mailers which can and which +cannot handle Multipart/related and handling recipients +which do not have full Internet connectivity. + + +2. Table of Contents + +1. Abstract +2. Table of Contents +3. Introduction +4. Implementation Methods +4.1 Method 1: Combining Viewer And MIME Receiving Program +4.2 Method 2: Rewriting The HTML +4.3 Method 3: Using A Translation Table +4.4 Method 4: Using A Proxy HTTP Server To Retrieve + Referenced Body Parts +4.5 Method 5: Putting The Mail Client Into A Proxy HTTP + Server +4.6 Other Methods +4.7 Combined Methods +4.8 Communication Between Document Viewer And Mail Client +5. Problems with Rewriting URIs when Copying HTML + Documents +6. Caching of Body Parts +7. "Save as" Command +8. Recipients which cannot Handle the Multipart/related + Content-Type +9. Use of the Content-Type: Multipart/alternative +9.1 Multipart/alternative inside Multipart/related +9.2 Multipart/alternative outside Multipart/related +9.3 Comparing the Two Methods +9.4 Reducing the Download Time +10. Writing Readable HTML +11. Textual Alternatives to HTML Forms +11.1 Form in HTML Format +11.2 The same Form In Textual Format +12. Recipient may not have Full Internet Connectivity +13. Encoding of Non-Ascii Characters +14. Conversion from HTTP to MIME +15. Default Font Size +16. Copyright and Disclaimer +17. Acknowledgments +18. References +19. Author's Address + + +Mailing List Information + +Further discussion on this document should be done through +the mailing list MHTML@SEGATE.SUNET.SE. + +To subscribe to this list, send a message to + LISTSERV@SEGATE.SUNET.SE +which contains the text +SUB MHTML <your name (not your email address)> + +Archives of this list are available by anonymous ftp from + FTP://SEGATE.SUNET.SE/lists/MHTML/ +The archives are also available by email. Send a message to +LISTSERV@SEGATE.SUNET.SE with the text "INDEX MHTML" to get +a list of the archive files, and then a new message "GET +<file name>" to retrieve the archive files. + +Comments on less important details may also be sent to the +editor, Jacob Palme <jpalme@dsv.su.se>. + +More information may also be available at URL: +HTTP://dsv.su.se/jpalme/ietf/mhtml.html + + +3. Introduction + +[MHTML] specifies how to send packaged aggregate HTML +objects in MIME multipart format. This memo is an +accompanying informational document, intended to be an aid +to developers. This document is not an Internet standard. + +The latest revised version of this document can be find in +plain text +and HTML format at +http://dsv.su.se/jpalme/ietf/mhtml.html#info. + + +4. Implementation Methods + +The [MHTML] standard has been intentionally written to be +implementable both in cases where a HTML document viewer +(web browser) and a program receiving MIME objects, such as +an email program, are combined, and when they are separate +programs. Implementation is of course easier if the +document viewer is combined with the MIME receiving client. + +Below are described different implementation methods. Real +implementations may sometimes combine ideas from more than +one of the different methods described below. + +Note: Some document viewers can take a whole document of +"Content-Type: message" or "Content-Type: multipart" as one +single file to be displayed. When such viewers are known to +be used, the problems described below become much easier to +handle, just submit the whole combined MIME message as a +single file to the viewer. + +4.1 Method 1: Combining Viewer And MIME Receiving Program + +This is the architecturally simplest approach. A +web-browser with a built in MIME receiving program (such as +an email program) will be able to use its own document +viewer capabilities to display HTML-formatted messages. +Since it is the same program, that program will more easily +be able to connect a URL in the HTML text to a body part in +the message. + +4.2 Method 2: Rewriting The HTML + + +----------+ +--------+ + | Document | | Mail | + | viewer | | client | + +-------+--+ +-+------+ + | | + +--+-------------------------------+--+ + | +----------+ +--+ +--+ | + | | Start | | | | | Related | Figure 1 + | | HTML | | | | | body part | + | | document | | | | | parts | + | +----------+ +--+ +--+ | + +-------------------------------------+ + +If the document viewer is separate from the MIME receiving +client, the MIME client might turn over the HTML body part +to the document viewer and ask it to display it (Figure 1). +One way of doing this is to store the HTML body part in a +file, and ask the document viewer to display this file. If +multipart/related is used, this can be implemented by +storing all the body parts within the multipart/related in +an otherwise empty folder/directory. + +The mail client may have to rewrite the HTML, replacing +URI-s with (possibly relative) URL-s which the Document +viewer can resolve as file names in the same +directory/folder where the HTML document itself is stored +when turning it over to the Document viewer. Problems with +such rewriting of URIs is discussed in section 5 below. + +4.3 Method 3: Using A Translation Table + + +----------+ +--------+ + | Document | | Mail | + | viewer | | client | + +-------+--+ +-+------+ + | | + +--+------------------------------+-+ + | +--------+ +--+ +--+ | + | | Trans- + | | | | | Related | Figure 2 + | | lation | | | | | body part | + | | table | | | | | parts | + | +--------+ +--+ +--+ | + +-----------------------------------+ + +An alternative to rewriting the HTML file before turning it +over to the Document viewer may be to use a translation +table, in case the Document viewer has the capability to +use such a table to rewrite URL-s on the fly while +displaying the document (Figure 2). This requires that the +Document viewer is capable of receiving CID: URL-s and +resolving them using this translation table in the same way +as for other URL-s. + +4.4 Method 4: Using A Proxy HTTP Server To Retrieve +Referenced Body Parts + + +--------+ +-----------+ +--------+ + | Proxy | | Data base | | Mail | + | web |-------| of cached |-------| server | + | server | | objects | | | + +----+---+ +-----------+ +----+---+ + | | + +----+-----+ +----+---+ + | Document | | Mail | + | viewer | | client | + +-------+--+ +-+------+ + | | + +--+------------------------------+-+ + | Start HTML object | Figure 3 + +-----------------------------------+ + +Yet another method is to use a proxy web server, to which +the document viewer requests are sent, and which will then +use the cached body parts instead of normal web retrieval +from the network (Figure 3). If the Document viewer is set +to use this proxy server for all URL-s, including CID +URL-s, no rewriting of the HTML will be necessary. + +4.5 Method 5: Putting The Mail Client Into A Proxy HTTP +Server + + +--------+--------+ + | Proxy | Mail | + | HTTP | client | + | server | | + +--------+--------+ + | + HTTP protocol Figure 4 + | + +----+-----+ + | Document | + | Viewer | + +----------+ + +A mail client can also be included in an HTTP server +(Figure 4). The user will then not have to install any mail +client software in his personal computer; all the mail +functionality is mapped on HTTP and HTML elements. + +4.6 Other Methods + +The mail client and the document viewer can of course +communicate in other ways, such as using inter-process +communication. + +4.7 Combined Methods + +Several of the methods described above can also be +combined. The mailer might for example display simpler HTML +documents itself, but automatically or manually transfer +the HTML documents to a separate HTML viewer for more +complex documents. + +A common practice in HTML viewers is to simply ignore all +markups which the viewer does not understand. This +practice, if implemented in a mailer with limited HTML +viewing capabilities, might mean that the user is shown a +very incomplete message without any warning that +information is missing. In this case, it is better to give +the user some kind of warning, combined with a command to +view the letter with a separate HTML viewer, or turn the +document over automatically to a separate viewer when the +document contains markup which the mailer cannot render +itself. + +4.8 Communication Between Document Viewer And Mail Client + +Many document viewers (web browsers) have API-s to allow +other programs to communicate with them. There is however +no accepted real or de-facto standard for such API-s, which +means that a mail program which relies on such API-s will +only be able to use those document viewers, whose API they +support. + +Note however, that most of the methods described above can +be implemented with a very minimal such API. The only API +function needed is to be able to tell a document viewer, +when it is started, to open a particular file. And this API +function is a standardized part of the operating system on +most platforms. In particular, method 1 and 3 above uses +the functionality that a relative URL is resolved with the +location of the base document as base. This means that if +the base document is a file, relative URL-s will be +resolved as FILE URL-s in the same directory/folder where +the HTML document itself is placed. + +There is a need for buttons in the Web page which the user +can use to get back to the mail program again after reading +the mail with the document viewer. A common technique to +achieve this is to define a new MIME data type for this +button. The document viewer is then configured to transfer +control to the mail client when the user pushes this +button; i.e. downloads a file of this new MIME type. + + +5. Problems with Rewriting URIs when Copying HTML +Documents + +Sending of HTML-formatted messages is based on the +assumption that an HTML documents, together with in-line +objects like images, applets and frames, can be copied into +a MIME message. Such copying may require rewriting of URIs +containing references between the different message parts. +The MHTML standard [MHTML] has been carefully prepared to +allow existing web pages to be copied without such +rewriting, through the use of the Content-Location MIME +content heading field. + +There is however a problem if the source HTML document +contains relative URIs in parameters to objects and +applets, such as in the example below: +From: foo1@bar.net +To: foo2@bar.net +Subject: A simple example +Mime-Version: 1.0 +Content-Type: multipart/related; +boundary="boundary-example-1"; + type=Text/HTML +Content-Base: "http://www.ietf.cnri.reston.va.us" + +--boundary-example 1 +Content-Type: Text/HTML; charset=US-ASCII + + ... text of the HTML document... +<OBJECT + CLASSID = "clsid:5220cb21-c88d-11cf-b347-00aa00a28331"> + <PARAM NAME="imageurl" VALUE="image.gif"> +</OBJECT> +...etc... + +--boundary-example-1 +Content-Location: "image.gif" +Content-Type: IMAGE/GIF +Content-Transfer-Encoding: BASE64 + +R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk +5 +..etc... + +--boundary-example-1-- + +From: foo1@bar.net +To: foo2@bar.net +Subject: A simple example +Mime-Version: 1.0 +Content-Type: multipart/related; +boundary="boundary-example-1"; + type=Text/HTML +Content-Base: "http://www.ietf.cnri.reston.va.us" + +--boundary-example 1 +Content-Type: Text/HTML; charset=US-ASCII + + ... text of the HTML document... +<OBJECT + CLASSID = "clsid:5220cb21-c88d-11cf-b347-00aa00a28331"> + <PARAM NAME="imageurl" VALUE="image.gif"> +</OBJECT> +...etc... + +--boundary-example-1 +Content-Location: "image.gif" +Content-Type: IMAGE/GIF +Content-Transfer-Encoding: BASE64 + +R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk +5 +..etc... + +--boundary-example-1-- + + + +Only the object might know that the imageurl parameter is +a relative URI. It's nearly impossible for the HTML parser +to understand that the parameter is a relative URI. Simply +searching for "image.gif" is not robust, as the string +"image.gif" may be used elsewhere. URIs in scripts can also +have similar problems. + +One might envisage even more difficult cases, an applet +might take a parameter "subject" and another parameter +"range" and when subject="auto" and range="1-5" it could +compute, and try to use auto1.gif, auto2.gif ... auto5.gif +as relative URLs. + +Some implementation methods described in section 4 above, +for example method 2 described in section 4.2, may require +rewriting of the URIs in the HTML document. + +There is no perfect solution to this problem. + +One way of alleviating the problem is to produce the +original document using only absolute URIs, preferably of +the CID type, since they are more easily identifiable. + +Another way of alleviating the problem is to make all URIs +and Content-Locations into simple relative URIs containing +file names only (without paths, preferably using a file +name format common to most platforms, i.e. 1-6 ascii +letters or digits, a period, and 1-3 extension ascii +letters or digits). An implementation using method 2 +described in section 4.2 above can then just store the +parts as files in an empty directory on the recipient +computer with the Content-Locations as file names. It can +then turn the start HTML file over to a document viewer, +and need not rewrite the URIs at all. This simple variant +of use of the MHTML standard is probably most robust, and +those implementors who can control the production of the +HTML documents to be sent are thus recommended to use this +variant. + + +6. Caching of Body Parts + +Suppose a message contains body parts with the +Content-Location header as defined in [MHTML]. A receiving +agent might then put this body part into a web cache, with +the URI in the Content-Location as its name, so that later +retrievals of this URI use the cached body parts. There is +however no guarantee that such a cached item is correct. +Such caching is thus not recommended for use in other ways +than for resolution of links within one particular MIME +message. + +The MHTML standard does not cover links between different +messages, but if you want to implement this, use of Content- +ID and/or Message-ID, rather than Content-Location, is +recommended. + +If incoming messages are stored in a store where messages +can be automatically deleted (purged), purging of body +parts should not occur before purging of the whole message, +to which they belong. + +If an incoming message contains a body part which is linked +via Content-Location, then no HTTP lookup should be +performed to check if the body part is recent. The message +should thus still contain the old HTML document, even if +the HTTP-available document has been revised. (Example: +"Here is the weather map of October 29, 1997"). Exception +from this is: + +(a) If the linked document is not enclosed in the message, +but referred + to via Content-Type: message/external-body, then the +latest version + should be shown using ordinary HTTP caching +conventions. + +(b) If a new message is sent with a Supersedes reference to +the old + message, the old message should still show the old +version of all + the body parts, but it might be wise to inform the user +that a + superseding message is available. + + +7. "Save as" Command + +Many HTML viewers have a "Save as" command to save an HTML +document in a local file. Usually, this command has two +variants, "Save as text" which converts the HTML document +to plain text before saving it, and "Save as source" which +saves the HTML document as an HTML-formatted document. + +These two variants may not be enough in the case of MHTML +documents. There is a third option, which might be named +"Save as aggregate". This option would save the HTML plus +all related parts in a file with the Content-Type: +Multipart/related. The file would thus begin with the +heading of the Multipart/related body part. + +There are two variants of this: Saving the document as it +looked like when you got it, or saving the document +including all inline body parts, even those you had to +retrieve from the Internet when showing the message to the +user. The second format is of special value, because it +provides an archiving format of the full document, allowing +the user to view it in the future as it looked like at one +particular time, even though web content may change in the +future. + +Finally, a user may also want to save the e-mail or http +heading fields of an incoming message. This is sometimes +the same as "Save as aggregate", but may include additional +body parts before or outside of the mulitpart/related +aggregate. + +To indicate whether such a saved document was received by e- +mail or http, it might be saved with an additional +surrounding body part of content-type message/rfc822 or +message/http. + +Example, suppose you receive by e-mail the following +message: + + MAIL FROM:<alice@bar.net> + RCPT TO:<bob@foo.net> + DATA + From: Alice <alice@bar.net> + To: Bob <bob2@foo.net> + Date: 23 Jan 1998 10:51 + Subject: A simple example + Mime-Version: 1.0 + Content-Type: multipart/related; boundary="boundary-example-1"; + type="text/html"; start=<foo3@foo1@bar.net> + + --boundary-example-1 + Content-Type: text/html;charset=US-ASCII + Content-ID: <foo3@foo1@bar.net> + + Here is the IETF logo with white background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo.gif" + ALT="IETF logo with white background"> + And here is the IETF logo with transparent background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo2e.gif" + <ALT="IETF logo with transparent background"> + + --boundary-example-1 + Content-Location: ietflogo.gif + Content-Base: http://www.ietf.cnri.reston.va.us/images/ + Content-Type: IMAGE/GIF + Content-Transfer-Encoding: BASE64 + + + R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 + + NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A + etc... + + --boundary-example-1-- + + + +Saving the above message as text might give the following +file: + + From: Alice <alice@bar.net> + To: Bob <bob2@foo.net> + Date: 23 Jan 1998 10:51 + Subject: A simple example + + Here is the IETF logo with white background: + IETF logo with white background + And here is the IETF logo with transparent +background: + IETF logo with transparent background + +Saving the same text as html source might give the +following file: + + Here is the IETF logo with white background: + <IMG +SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif" + ALT="IETF logo with white background"> + And here is the IETF logo with transparent background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo2e.gif" + <ALT="IETF logo with transparent background"> + +Saving the same text as aggregate might give the following +file + + From: Alice <alice@bar.net> + To: Bob <bob2@foo.net> + Date: 23 Jan 1998 10:51 + Subject: A simple example + Mime-Version: 1.0 + Content-Type: multipart/related; boundary="boundary-example-1"; + type="text/html"; start=<foo3@foo1@bar.net> + + --boundary-example-1 + Content-Type: text/html;charset=US-ASCII + Content-ID: <foo3@foo1@bar.net> + + Here is the IETF logo with white background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo.gif" + ALT="IETF logo with white background"> + And here is the IETF logo with transparent background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo2e.gif" + <ALT="IETF logo with transparent background"> + + --boundary-example-1 + Content-Location: ietflogo.gif + Content-Base: http://www.ietf.cnri.reston.va.us/images/ + Content-Type: IMAGE/GIF + Content-Transfer-Encoding: BASE64 + + + R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 + NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A + etc... + + --boundary-example-1-- + + + +Saving the same text as archiving aggregate might give the +following file (where the missing body part is fetched +through http and added to the saved file): + + From: Alice <alice@bar.net> + To: Bob <bob2@foo.net> + Date: 23 Jan 1998 10:51 + Subject: A simple example + Mime-Version: 1.0 + Content-Type: multipart/related; boundary="boundary-example-1"; + type="text/html"; start=<foo3@foo1@bar.net> + + --boundary-example-1 + Content-Type: text/html;charset=US-ASCII + Content-ID: <foo3@foo1@bar.net> + + Here is the IETF logo with white background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo.gif" + ALT="IETF logo with white background"> + And here is the IETF logo with transparent background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo2e.gif" + <ALT="IETF logo with transparent background"> + + --boundary-example-1 + Content-Location: ietflogo.gif + Content-Base: http://www.ietf.cnri.reston.va.us/images/ + Content-Type: IMAGE/GIF + Content-Transfer-Encoding: BASE64 + + + R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 + NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A + etc... + + --boundary-example-1 + Content-Location: ietflogo2e.gif + Content-Base: http://www.ietf.cnri.reston.va.us/images/ + Content-Type: IMAGE/GIF + Content-Transfer-Encoding: BASE64 + + + R0lGODlhGAGgANX/ACkpKTExMTk5OUJCQkpKSlJSUlpaWmNjY2tra3Nzc3t7e4 + SEhIyMjJSUlJycnKWlpa2trbW1tcDAwM7Ozv/eQnNzjHNzlGtrjGNjhFpae1pa + etc... + + --boundary-example-1-- + + + +Saving the same message as message might give the following +file: + + from:<alice@bar.net> + To:<bob@foo.net> + Mime-Version: 1.0 + Content-Type: Message/rfc822; + boundary="boundary-example-2" + + --boundary-example-2 + From: Alice <alice@bar.net> + To: Bob <bob2@foo.net> + Date: 23 Jan 1998 10:51 + Subject: A simple example + Mime-Version: 1.0 + Content-Type: multipart/related; +boundary="boundary-example-1"; + type="text/html"; start=<foo3@foo1@bar.net> + + --boundary-example-1 + Content-Type: text/html;charset=US-ASCII + Content-ID: <foo3@foo1@bar.net> + + Here is the IETF logo with white background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo.gif" + ALT="IETF logo with white background"> + And here is the IETF logo with transparent background: + <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ + ietflogo2e.gif" + <ALT="IETF logo with transparent background"> + --boundary-example-1 + Content-Location: ietflogo.gif + Content-Base: http://www.ietf.cnri.reston.va.us/images/ + Content-Type: IMAGE/GIF + Content-Transfer-Encoding: BASE64 + + R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5 + NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A + etc... + + --boundary-example-1-- + --boundary-example-2-- + + + +8. Recipients which cannot Handle the Multipart/related +Content-Type + +A message sent according to the specifications in [MHTML] +may have recipients, whose mailers cannot handle the +Multipart/related Content-Type in the way specified in +[MHTML]. + +According to [MIME1] a mailer which encounters an unknown +subtype to Multipart, should handle this as +Multipart/mixed. + +To improve this, Multipart/alternative can be used as +discussed in section 9 of this memo. + +Content-Disposition, as specified in [CONDISP] and in +[MHTML], section 10, can also be used as an aid to mailers +which do not understand Multipart/related. + +Captions on images, which are included in the HTML text, +might for non-HTML-capable recipients be found in the +Content-Description header [CONDISP]. Do not assume, +however, that HTML-capable user agents will display the +Content-Description header, they may assume that this +information is included in the HTML text instead. + + +9. Use of the Content-Type: Multipart/alternative + +If the message is sent to recipients, all of which may not +have mailers capable of handling the Text/HTML +content-type, then the "Content-Type: +Multipart/Alternative" [MIME1] can be used in two ways: + +9.1 Multipart/alternative inside Multipart/related + +The Multipart/alternative is put inside the "Content-Type +Multipart/related", body parts can be specified with +"Content-Type: Text/plain" as the first choice, and +"Content-Type: Text/HTML" as the second choice. + +Example: + + Content-Type: Multipart/related; +boundary="boundary-example-1"; + type=MULTIPART/ALTERNATIVE + + --boundary-example 1 + Content-Type: MULTIPART/ALTERNATIVE + Boundary: boundary-example-2 + + --boundary-example-2 + Content-Type: Text/plain + + ... plain text version of the document for recipients + whose mailers cannot handle Text/HTML ... + + --boundary-example-2 + Content-Type: Text/HTML; charset=US-ASCII + Content-ID: content-id-example@example.host + + ... text of the HTML document ... + + --boundary-example-2-- + --boundary-example-1 + Content-Type: Image/GIF + + ... a body part, to which the HTML document has a link ... + --boundary-example-1-- + + + +Note that the type parameter of Multipart/related in this +case should be Multipart/alternative and not Text/HTML. + + +9.2 Multipart/alternative outside Multipart/related + +The multipart/alternative is put outside the +Multipart/Related, with Multipart/Related as one +alternative and Multipart/Mixed as the other alternative. +Note however that the [MHTML] does not recommend links from +inside Multipart/Related to objects outside of the +Multipart/Related, so putting inline images outside the +Multipart/Related is not suitable. Instead, such inline +images may have to repeated in both branches of the +multipart/alternative with this method. + +Example: + + Content-Type: MULTIPART/ALTERNATIVE + Boundary: boundary-example-1 + + --boundary-example-1 + Content-Type: Multipart/mixed; boundary="boundary-example-3" + + --boundary-example-3 + Content-Type: Text/plain; charset=US-ASCII + + ... plain text version of the message for recipients + whose mailers cannot handle Text/HTML ... + + --boundary-example-3 + Content-Type: Image/GIF + + ... A picture associated with the plain text message ... + --boundary-example-3-- + + --boundary-example-1 + Content-Type: Multipart/related; boundary="boundary-example-1"; + type=Text/HTML + + --boundary-example 2 + Content-Type: Text/HTML; charset=US-ASCII + Content-ID: content-id-example@example.host + + ... text of the HTML document ... + + --boundary-example-2 + Content-Type: Image/GIF + + ... a body part, to which the HTML document has a link ... + --boundary-example-2-- + --boundary-example-1-- + + +9.3 Comparing the Two Methods + +When choosing between these two methods of employing +multipart/alternative, note the following: + + (1) Clients which do not support Multipart/related, + and which thus will interpret it as + Multipart/mixed, will with choice 9.1 display the + inline objects. Thus, a recipient whose mailer + can handle image/gif but not multipart/related + will still be shown the images, they will not be + suppressed by being inside a suppressed branch of + the Multipart/alternative. + +(2) Choice 9.2 will not show inline images in the + Multipart/Related, unless this information is + repeated in both branches of the + Multipart/Alternative. + +A general warning: Some mailers do not support +"Content-Type: Multipart/alternative", and may then +interpret it as Multipart/mixed, even though support of +multipart/alternative is required for MIME conformance. + + +9.4 Reducing the Download Time + +If a message is sent as multipart/alternative, this would +normally mean that the mail client downloads both variants, +and then shows only one of the to the user. This will thus +increase the download time. A way of avoiding this problem +is to use the FETCH command of IMAP, which allows a client +to download only certain body parts from a multipart +message. + + +10. Writing Readable HTML + +An alternative to use of multipart/alternative is to +produce HTML code which is is easy to read as it is. This +alternative only works if you restrict the use of HTML +features, for example if you have a special program to +generate the HTML text. + +Below is an example of such a readable HTML text: + +<p> This is an example of HTML code, which is written + so as to be readable for people who read it as + plain text. + +<p> Here is the second paragraph, which contains a + <a href="cid:456*foo@bar.net"> link +</a> to a separate body part. +<p> Here is an embedded picture: + +<p> <img src="cid:123*foo@bar.net" width="13" height="13"> + +<p> End of this HTML-formatted message. + + + +11. Textual Alternatives to HTML Forms + +One important usage of HTML in e-mail is to send forms, +which the recipients fill in and return. It is then +problematic how to handle recipients whose mailers do not +support HTML. One way is to use textual encoding of the +forms. This encoding is done so that the user action needed +to send in the form is made simple also for those who have +only textual e-mail systems. Important is that the textual +users are not forced to write complex commands in special +command languages. Instead, the form should be written so +that the user need only make simple changes to the form +before sending it back, like deleting or adding single +characters. + +Below is an example which shows how this can be done. The +main principle is that every line beginning with ";" is an +explanation for the reader, and every line beginning with +"!" is a text, which the user can convert into a command by +just deleting the "!" in front of the line. + +The users will thus have to learn a very simple rule of +filling in forms: Just delete the "!" in front of your +selections. + +Technically, the recipient of a filled-in textual form +should regard all lines beginning with ";" or "!" as +comment, and interpret all other lines as commands. + +11.1 Form in HTML Format + +<FORM action="mailto:meeting-scheduling@ietf.org" +method="POST"> + +<P>Which meeting date do you prefer? + +<P>1 December 1997 <SELECT NAME="19971201"> + <OPTION>Very good + <OPTION>Good + <OPTION>Acceptable + <OPTION>Bad + <OPTION>Very bad +</SELECT> + +<P>7 December 1997 <SELECT NAME="19971207"> + <OPTION>Very good + <OPTION>Good + <OPTION>Acceptable + <OPTION>Bad + <OPTION>Very bad +</SELECT> + +<P>14 December 1997 <SELECT NAME="19971214"> + <OPTION>Very good + <OPTION>Good + <OPTION>Acceptable + <OPTION>Bad + <OPTION>Very bad +</SELECT> + +<P>21 December 1997 <SELECT NAME="19971221"> + <OPTION>Very good + <OPTION>Good + <OPTION>Acceptable + <OPTION>Bad + <OPTION>Very bad +</SELECT> + +<P>Who should be the chairman? + +<P><INPUT TYPE="radio" NAME="chairman" VALUE="Mary">Mary + +<P><INPUT TYPE="radio" NAME="chairman" VALUE="John">John + +<P>Do you want simultaneous translation during the meeting? + +<P><INPUT TYPE="checkbox" NAME="translation" +VALUE="English">To and +from English + +<P><INPUT TYPE="checkbox" NAME="translation" +VALUE="French">To and +from French + +<P><INPUT TYPE="checkbox" NAME="translation" +VALUE="Japanese">To and +from Japanese + +<P>Please propose issues to discuss during the meeting: + +<P><TEXTAREA NAME="issues" ROWS=7 COLS=66></TEXTAREA> + +<P><INPUT TYPE="submit" NAME="Submit" +VALUE="Submit"><INPUT TYPE="reset" VALUE="Reset"> + + +11.2 The same Form In Textual Format + +; This is a computer-generated form. Please fill it in and return it +; to meeting-scheduler@ietf.org. To fill in the form, just copy its +; text into your reply and remove the exclamation mark (!) in front +; of your choices. + +; If your mailer adds ">" or "> " in front of lines, you can keep +; these or remove them as you prefer. + +Question 1: Which meeting date do you prefer? + +Option 1.1: 1 December 1997 +! Very good +! Good +! Acceptable +! Bad +! Very bad + +Option 1.2: 7 December 1997 +! Very good +! Good +! Acceptable +! Bad +! Very bad + +Option 1.3: 14 December 1997 +! Very good +! Good +! Acceptable +! Bad +! Very bad + +Option 1.4: 21 December 1997 +! Very good +! Good +! Acceptable +! Bad +! Very bad + +Question 2: Who should be the chairman? +! Mary +! John + +Question 3: Do you want simultaneous translation during the +meeting? + +Option 3.1: To and from English +! Yes +! No + +Option 3.2: To and from French +! Yes +! No + +Option 3.3: To and from Japanese +! Yes +! No + +Question 4: Please propose issues to discuss during the +meeting. +Write your proposal on the empty lines below. + + + + + + +-- End of Question 4 + + + +12. Recipient may not have Full Internet Connectivity + +The recipient of a message sent by email may not always +have full Internet connectivity. The recipient may be +behind a gateway or firewall which prohibits or restricts +Internet connectivity. + +This means that the recipient may not be able to resolve +URI-s in an email message, unless the referred-to documents +are included in the email message itself. Thus, it is often +suitable to include in an email message all documents which +are referred to (directly or indirectly) by URI-s in the +message. This may of course not always be possible, in some +cases the set of referred-to documents (directly or +indirectly) may be the whole WWW document space, i.e. +millions of documents. A choice must then be made how much +to include. Of course, it is most important to include all +inline objects, i.e. objects linked by such hyperlinks as +IMG, etc., which specify that the linked objects are to be +shown to the user immediately. + +In the case of ACTION elements in HTML forms, by making +these ACTION elements of the "mailto:" URL type, rather +than the "http:" URL type, you will enable also recipients +without full Internet connectivity to fill in and send in +your forms. The HTML specification [HTML2] allows default +action when no ACTION element is included, but this default +action may not be suitable when sending the HTML document +via email. Thus, it is better to always put an explicit +ACTION element into HTML forms sent by email. + +A disadvantage with the "mailto:" URL as ACTION, however, +is that this may not work if the user has not specified his +e-mail address in the preferences of this HTML viewer. This +is common for multi-user workstations. + +Including URLs, which have to resolved over the Internet, +typically referring to 1x1 pixel transparent images, is a +known method for spammers to get information about the +recipient of e-mail. It is possible that some mailers will +restrict or disallow this in order to stop this method of +information-gathering by spammers. + + +Encoding of Non-Ascii Characters + + Displayed text Displayed text + | ^ + V | + +-------------+ +----------------+ + | HTML editor | | HTML viewer | + | | | or Web browser | + +-------------+ +----------------+ + | ^ + V | + HTML markup HTML markup + | ^ + V | + +---------+ +---------------+ +-------------+ +---------------+ + | MIME | | MIME content- | | MIME | | MIME content- | + | encap- | | transfer- | | heading | | transfer- | + | sulator | | encoder | | interpreter | | decoder | + +---------+ +---------------+ +-------------+ +---------------+ + | | ^ ^ + V V +-----------+ | | +MIME heading + MIME content->| Transport |->MIME heading + MIME content + +-----------+ + + Figure 5 + +Definitions (see Figure 5): + +Displayed A visual representation of the intended +text text. + +HTML markup A sequence of characters formatted + according to the HTML specification + [HTML2]. + +MIME content A sequence of octets physically forwarded + via email, may use MIME content-transfer- + encoding as specified in [MIME1]. + +HTML editor Software used to produce HTML markup. + +MIME content- Software used to encode non-US-ASCII +transfer- charactersr as specified in [MIME1]. +encoder + +MIME content- Software used to decode non-US-ASCII +transfer- characters as specified in [MIME1]. +decoder + +MIME heading Software used to interpret the information +interpreter in MIME headings. + +HTML viewer Software used to display HTML documents to + recipients. + +Some implementations may have a choice of whether to +represent non-ascii characters at the HTML layer (using "&" +entity references or numeric character references as +defined in [HTML2] section 3.2.1) or at the MIME layer +(using Content-Transfer-Encoding as defined in [MIME1] +section 5). + +In choosing between these two representation methods, note +the following effects: + +(1) Modifying HTML markup may disrupt security content + integrity checksums. If the checksums are computed + between the HTML editor and the MIME encapsulator, + then making the encoding in the MIME encapsulator + will not break the checksums. + +(2) The choice of modifying HTML markup may be more + suitable for recipients whose mailers do not + support MIME. + +(3) Using MIME Content-Transfer-Encoding may be more + suitable for recipients who have MIME-compliant + mailers but do pass the text over to a document + viewer (web browser). + + +14. Conversion from HTTP to MIME + +Information received or retrieved using HTTP cannot always +be sent unchanged as email using the "Content-Type: +Text/HTML", because of the restrictions which MIME places +on the format of "Content-Type: Text/HTML". The same +problem may occur for documents retrieved via HTTP, which +are in other textual formats than HTML. In particular, note +the following: + +(a) Content-encodings allowed in HTTP, but not allowed in + MIME, must be removed. + +(b) HTTP allows line breaks as bare CRs or bare LFs or + something else, while MIME only allows line breaks as + CRLF in subtypes of the Text content-type. + +(c) HTTP allows character sets like Unicode-1-1, which do + not represent line breaks as CRLFs, such text may have + to be rewritten to character sets like + Unicode-1-1-UTF-7 in which line breaks are represented + as CRLFs. + +A good overview of the differences, with regard to the use +of "Content-Type: Text", between MIME and HTTP, can be +found in [HTTP] appendix C. + +If you want to provide web documents, which can be sent +through e-mail without modification (which might break +integrity checksums), then you SHOULD provide them up in +the canonical form, with line breaks as CRLF, and avoid +lines longer than 76 characters/line. + +If you want to send HTTP unchanged via email, you might +consider using the "Content-Type: Message/HTTP" instead of +the "Content-Type: Text/HTML". Note that with this Content- +Type, the whole object, as sent through HTTP, can be +encoded as a single object with, for example, BASE64 +encoding. After decoding of the BASE64, the resulting +object can have HTTP peculiar formats, like single LF or +single CR between lines. However, some mailers may not be +capable of handling the Message/HTTP Content-Type. + +Example, the binary part of the following message + + Content-Type: message/http + Content-Transfer-Encoding: base64 + + +SFRUUC8xLjEgMjAwIE9LDURhdGU6IFNhdCwgMTQgRmViIDE5OTggMTM6MDM +6MzggR01U + +DVNlcnZlcjogQXBhY2hlLzEuMi40DUxhc3QtTW9kaWZpZWQ6IFdlZCwgMjM +gSnVsIDE5 + ... ... ... + + +might, when the base64 encoding above is decoded, yield: + + HTTP/1.1 200 OK + Date: Sat, 14 Feb 1998 13:03:38 GMT + ETag: "43788-124-33d658c5" + Content-Length: 292 + Accept-Ranges: bytes + Content-Type: text/html + + ... <HTML data with only LF between lines> ... + + + +15. Default Font Size + +Many HTML editors and viewers allow the user to specify the +size of the default font (<FONT SIZE=3> or <FONT SIZE="+0"> +according to personal wishes, for example 10 pt or 12 pt or +14 pt depending on eye sight and screen distance. This +setting should *not* cause a change in the FONT SIZE= value +in the generated HTML which is produced and sent. The +reason for this is that otherwise users may inadvertently +send whole letters with the text in <FONT SIZE=1> or <FONT +SIZE=2>, which may be easy to read for the sender but +difficult to read for some recipients. + +Similarly, a user choice of default FONT, to for example +GENEVA or ARIAL, should not cause <FONT FACE=GENEVA> or +<FONT FACE=ARIAL> to be sent. User who wish to send e-mail +with <FONT SIZE=2> or <FONT FACE=GENEVA> must explicitly +specify this, for example using a FONT command in their +HTML editor or e-mail text editor. + + +16. Copyright and Disclaimer + +The IETF takes no position regarding the validity +or scope of any intellectual property or other +rights that might be claimed to pertain to the +implementation or use of the technology described +in this document or the extent to which any license +under such rights might or might not be available; +neither does it represent that it has made any +effort to identify any such rights. Information on +the IETF's procedures with respect to rights in +standards-track and standards-related documentation +can be found in BCP-11. Copies of claims of rights +made available for publication and any assurances +of licenses to be made available, or the result of +an attempt made to obtain a general license or +permission for the use of such proprietary rights +by implementors or users of this specification can +be obtained from the IETF Secretariat." + +The IETF invites any interested party to bring to +its attention any copyrights, patents or patent +applications, or other proprietary rights which may +cover technology that may be required to practice +this standard. Please address the information to +the IETF Executive Director. + +Copyright (C) The Internet Society (date). All +Rights Reserved. + +This document and translations of it may be copied +and furnished to others, and derivative works that +comment on or otherwise explain it or assist in its +implmentation may be prepared, copied, published +and distributed, in whole or in part, without +restriction of any kind, provided that the above +copyright notice and this paragraph are included on +all such copies and derivative works. However, this +document itself may not be modified in any way, +such as by removing the copyright notice or +references to the Internet Society or other +Internet organizations, except as needed for the +purpose of developing Internet standards in which +case the procedures for copyrights defined in the +Internet Standards process must be followed, or as +required to translate it into languages other than +English. + +The limited permissions granted above are perpetual +and will not be revoked by the Internet Society or +its successors or assigns. + + +17. Acknowledgments + +Harald Tveit Alvestrand, Richard Baker, Dave Crocker, +Martin J. Duerst, Roy Fielding, Lewis Geer, Al Gilman, Paul +Hoffman, Alexander Hopmann, Mark K. Joseph, Greg Herlihy, +Valdis Kletnieks, Daniel LaLiberte, Ed Levinson, Jay +Levitt, Albert Lunde, Larry Masinter, Keith Moore, Gavin +Nicol, Pete Resnick, Jon Smirl, Einar Stefferud, Jamie +Zawinski and several other people have helped us with +preparing this memo. I alone take responsibility for any +errors which may still be in the memo. + + +18. References + +Temporary note: This list contains some references to +Internet drafts. It is anticipated that these Internet +drafts will become RFC-s before this memo. The references +will then in this memo be changed to refer to the +corresponding RFC instead. This list also includes some +RFC-s which are not up to date, and which will be replaced +by new memos presently in ietf draft status. + +Ref. Author, title +--- ------------- + +[CONDISP] R. Troost, S. Dorner: "Communicating + Presentation Information in Internet Messages: + The Content- Disposition Header", RFC 1806, June + 1995. + +[HOSTS] R. Braden (editor): "Requirements for Internet + Hosts -- Application and Support", STD-3, RFC + 1123, October 1989. + +[HTML2] T. Berners-Lee, D. Connolly: "Hypertext Markup + Language - 2.0", RFC 1866, November 1995. + +[HTTP] J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. + Berners-Lee: 2616 Hypertext Transfer Protocol -- + HTTP/1.1. R. Fielding, J. Gettys, RFC 2616, June + 1999. + +[MHTML] J. Palme, A. Hopmann, N. Shelness: MIME + Encapsulation of Aggregate Documents, such as + HTML (MHTML). RFC 2557, March 1999. + +[MIDCID] E. Levinson.: Content-ID and Message-ID Uniform + Resource Locators. RFC 2392, August 1998. + +[MIME1] N. Freed & N. Borenstein: "MIME (Multipurpose + Internet Mail Extensions) Part One: Mechanisms + for Specifying and Describing the Format of + Internet Message Bodies", RFC 2045, November + 1996. + +[MIME2] N. Freed & N. Borenstein: "Multipurpose Internet + Mail Extensions (MIME) Part Two: Media Types". + RFC 2046, November 1996. + +[NEWS] M.R. Horton, R. Adams: "Standard for interchange + of USENET messages", RFC 1036, December 1987. + +[REL] E. Levinson.: The MIME Multipart/Related Content- + type. RFC 2387, August 1998. + +[RELURL] R. Fielding: "Relative Uniform Resource + Locators", RFC 1808, June 1995. + +[MSGFMT] P. Resnick: "Internet Message Format" STD 11, + RFC 2822, April 2001. + +[SMTP] J. Klensin: "Simple Mail Transfer Protocol", RFC + 2821, April 2001. + +[URL] T. Berners-Lee, L. Masinter, M. McCahill: + "Uniform Resource Locators (URL)", RFC 1738, + December 1994. + +[URLBODY] N. Freed and Keith Moore: "Definition of the URL + MIME External-Body Access-Type", RFC 2017, + October 1996. + +19. Author's Address + +Jacob Palme Phone: +46-8-16 16 67 +Stockholm University and KTH Fax: +46-8-783 08 29 +Electrum 230 Email: jpalme@dsv.su.se +S-164 40 Kista, Sweden + +Working group chairman: + +Einar Stefferud <stef@nma.com> diff --git a/Documentation/en/I-D/index.html b/Documentation/en/I-D/index.html index 4bdcd528..862dd8a6 100644 --- a/Documentation/en/I-D/index.html +++ b/Documentation/en/I-D/index.html @@ -1,13 +1,6 @@ <UL> <LI> A (autosub) <UL> <LI> - <A HREF="draft-palme-autosub-07.txt"> - draft-palme-autosub-07.txt - </A> - This Internet-Draft has been deleted. - - - <LI> <A HREF="draft-palme-autosub-03.txt"> draft-palme-autosub-03.txt </A> @@ -17,6 +10,13 @@ Loop control for the Auto-Submitted e-mail header + <LI> + <A HREF="draft-palme-autosub-07.txt"> + draft-palme-autosub-07.txt + </A> + This Internet-Draft has been deleted. + + </UL><LI> B (bsmtp) <UL> <LI> <A HREF="draft-freed-bsmtp-02.txt"> @@ -55,6 +55,13 @@ <LI> + <A HREF="draft-ietf-drums-mail-followup-to-01.txt"> + draft-ietf-drums-mail-followup-to-01.txt + </A> + This Internet-Draft has been deleted. + + + <LI> <A HREF="draft-ietf-drums-smtpupd-09.txt"> draft-ietf-drums-smtpupd-09.txt </A> @@ -64,16 +71,6 @@ <LI> - <A HREF="draft-ietf-drums-mail-followup-to-00.txt"> - draft-ietf-drums-mail-followup-to-00.txt - </A> - Internet Draft Stockholm University/KTH - draft-ietf-drums-mail-followup-to-00.txt - Expires: May 1998 November 1997 - The ''Mail-Followup-To'' header - - - <LI> <A HREF="draft-ietf-drums-smtpupd-13.txt"> draft-ietf-drums-smtpupd-13.txt </A> @@ -86,14 +83,13 @@ <A HREF="draft-palme-e-mail-translation-03.txt"> draft-palme-e-mail-translation-03.txt </A> - This Internet-Draft has been deleted. - - - <LI> - <A HREF="draft-bernstein-eplf-06.txt"> - draft-bernstein-eplf-06.txt - </A> - This Internet-Draft has been deleted. + Internet Draft Stockholm + draft-palme-e-mail-translation-03.txt University/KTH + Sweden + Category-to-be: Proposed standard Date: December 2001 + Expires: June 2001 + Support for Language Translation + in E-Mail and Netnews <LI> @@ -104,16 +100,8 @@ <LI> - <A HREF="draft-melnikov-esmtp-lang-00.txt"> - draft-melnikov-esmtp-lang-00.txt - </A> - Internet Draft
- SMTP Language Extension
- - - <LI> - <A HREF="draft-ward-esmtp-slide-04.txt"> - draft-ward-esmtp-slide-04.txt + <A HREF="draft-bernstein-eplf-06.txt"> + draft-bernstein-eplf-06.txt </A> This Internet-Draft has been deleted. @@ -126,26 +114,23 @@ <A HREF="../rfc/rfc3030.txt">RFC3030</A> -</UL><LI> F (fax) -<UL> <LI> - <A HREF="draft-ietf-fax-esmtp-conneg-01.txt"> - draft-ietf-fax-esmtp-conneg-01.txt + <LI> + <A HREF="draft-ward-esmtp-slide-04.txt"> + draft-ward-esmtp-slide-04.txt </A> - Internet Draft D. Crocker, Brandenburg - draft-ietf-fax-esmtp-conneg-01.txt November 2001 - Expires: May 2002 - SMTP Service Extension - for Content Negotiation of Internet Fax + This Internet-Draft has been deleted. <LI> - <A HREF="draft-ietf-fax-smtp-capabilities-01.txt"> - draft-ietf-fax-smtp-capabilities-01.txt + <A HREF="draft-melnikov-esmtp-lang-00.txt"> + draft-melnikov-esmtp-lang-00.txt </A> - This Internet-Draft has been deleted. + Internet Draft
+ SMTP Language Extension
- <LI> +</UL><LI> F (fax) +<UL> <LI> <A HREF="draft-ietf-fax-smtp-session-04.txt"> draft-ietf-fax-smtp-session-04.txt </A> @@ -158,6 +143,24 @@ draft-ietf-fax-smtp-session-04.txt + <LI> + <A HREF="draft-ietf-fax-smtp-capabilities-01.txt"> + draft-ietf-fax-smtp-capabilities-01.txt + </A> + This Internet-Draft has been deleted. + + + <LI> + <A HREF="draft-ietf-fax-esmtp-conneg-01.txt"> + draft-ietf-fax-esmtp-conneg-01.txt + </A> + Internet Draft D. Crocker, Brandenburg + draft-ietf-fax-esmtp-conneg-01.txt November 2001 + Expires: May 2002 + SMTP Service Extension + for Content Negotiation of Internet Fax + + </UL><LI> H (hcmssc) <UL> <LI> <A HREF="draft-bernstein-hcmssc-02.txt"> @@ -233,7 +236,7 @@ Anti-UBE and Anti-UCE Keywords in SMTP Banners -</UL><LI> M (mail mailext maillist mhregistry mpls msgtrk) +</UL><LI> M (mail mailext maillist mhregistry mhtml mpls msghdr msgtrk) <UL> <LI> <A HREF="draft-bernstein-mail-loops-war-02.txt"> draft-bernstein-mail-loops-war-02.txt @@ -249,6 +252,14 @@ <LI> + <A HREF="draft-ietf-mailext-mail-attributes-07.txt"> + draft-ietf-mailext-mail-attributes-07.txt + </A> + A new Request for Comments is now available in online RFC libraries. + <A HREF="../rfc/rfc2076.txt">RFC2076</A> + + + <LI> <A HREF="draft-palme-mailext-headers-06.txt"> draft-palme-mailext-headers-06.txt </A> @@ -261,14 +272,6 @@ <LI> - <A HREF="draft-ietf-mailext-mail-attributes-07.txt"> - draft-ietf-mailext-mail-attributes-07.txt - </A> - A new Request for Comments is now available in online RFC libraries. - <A HREF="../rfc/rfc2076.txt">RFC2076</A> - - - <LI> <A HREF="draft-palme-maillist-01.txt"> draft-palme-maillist-01.txt </A> @@ -286,46 +289,36 @@ <LI> - <A HREF="draft-bernstein-mpls-sonet-01.txt"> - draft-bernstein-mpls-sonet-01.txt - </A> - This Internet-Draft has been deleted. - - - <LI> - <A HREF="draft-ietf-msgtrk-smtpext-03.txt"> - draft-ietf-msgtrk-smtpext-03.txt + <A HREF="draft-palme-mhtml-info-01.txt"> + draft-palme-mhtml-info-01.txt </A> - Internet Draft E. Allman - draft-ietf-msgtrk-smtpext-03.txt Sendmail, Inc. - Valid for six months T. Hansen - Updates: RFC 1891 AT&T Laboratories - November 2, 2001 - SMTP Service Extension - for Message Tracking - <draft-ietf-msgtrk-smtpext-03.txt> + Internet Draft Stockholm + draft-palme-mhtml-info-01.txt University/KTH + December 2001 + Category-to-be: + Informational + Expires: June 2001 + Sending HTML in MIME, + an informational supplement to the RFC: + MIME Encapsulation of Aggregate Documents, + such as HTML (MHTML) <LI> - <A HREF="draft-ietf-msgtrk-trkstat-03.txt"> - draft-ietf-msgtrk-trkstat-03.txt + <A HREF="draft-bernstein-mpls-sonet-01.txt"> + draft-bernstein-mpls-sonet-01.txt </A> - Internet Draft E. Allman - draft-ietf-msgtrk-trkstat-03.txt Sendmail, Inc. - Valid for six months November 2, 2001 - Updates: RFC 1893 - The Message/Tracking-Status MIME Extension - <draft-ietf-msgtrk-trkstat-03.txt> + This Internet-Draft has been deleted. <LI> - <A HREF="draft-jones-msgtrk-def-02.txt"> - draft-jones-msgtrk-def-02.txt + <A HREF="draft-klyne-msghdr-registry-01.txt"> + draft-klyne-msghdr-registry-01.txt </A> - This Internet-Draft has expired and is no longer available. - Unrevised documents placed in the Internet-Drafts directories have a - maximum life of six months. After that time, they must be updated, or - they will be deleted. This document was deleted on March 20, 2000. + Internet-Draft MIMEsweeper Group + Expires: July 5, 2002 Jan 4, 2002 + Registration procedures for message headers + draft-klyne-msghdr-registry-01 <LI> @@ -368,6 +361,42 @@ <LI> + <A HREF="draft-jones-msgtrk-def-02.txt"> + draft-jones-msgtrk-def-02.txt + </A> + This Internet-Draft has expired and is no longer available. + Unrevised documents placed in the Internet-Drafts directories have a + maximum life of six months. After that time, they must be updated, or + they will be deleted. This document was deleted on March 20, 2000. + + + <LI> + <A HREF="draft-ietf-msgtrk-trkstat-03.txt"> + draft-ietf-msgtrk-trkstat-03.txt + </A> + Internet Draft E. Allman + draft-ietf-msgtrk-trkstat-03.txt Sendmail, Inc. + Valid for six months November 2, 2001 + Updates: RFC 1893 + The Message/Tracking-Status MIME Extension + <draft-ietf-msgtrk-trkstat-03.txt> + + + <LI> + <A HREF="draft-ietf-msgtrk-smtpext-03.txt"> + draft-ietf-msgtrk-smtpext-03.txt + </A> + Internet Draft E. Allman + draft-ietf-msgtrk-smtpext-03.txt Sendmail, Inc. + Valid for six months T. Hansen + Updates: RFC 1891 AT&T Laboratories + November 2, 2001 + SMTP Service Extension + for Message Tracking + <draft-ietf-msgtrk-smtpext-03.txt> + + + <LI> <A HREF="draft-ietf-msgtrk-protocol-05.txt"> draft-ietf-msgtrk-protocol-05.txt </A> @@ -421,34 +450,34 @@ <LI> - <A HREF="draft-bernstein-nrudt-06.txt"> - draft-bernstein-nrudt-06.txt - </A> - This Internet-Draft has been deleted. - - - <LI> <A HREF="draft-bernstein-nrudt-02.txt"> draft-bernstein-nrudt-02.txt </A> Notice-Requested-Upon-Delivery-To (NRUDT) -</UL><LI> O (owner) -<UL> <LI> - <A HREF="draft-bernstein-owner-hack-05.txt"> - draft-bernstein-owner-hack-05.txt + <LI> + <A HREF="draft-bernstein-nrudt-06.txt"> + draft-bernstein-nrudt-06.txt </A> This Internet-Draft has been deleted. - <LI> +</UL><LI> O (owner) +<UL> <LI> <A HREF="draft-bernstein-owner-hack-01.txt"> draft-bernstein-owner-hack-01.txt </A> The Owner Hack + <LI> + <A HREF="draft-bernstein-owner-hack-05.txt"> + draft-bernstein-owner-hack-05.txt + </A> + This Internet-Draft has been deleted. + + </UL><LI> P (palme pirp) <UL> <LI> <A HREF="draft-ietf-palme-select-00.txt"> @@ -477,17 +506,17 @@ </UL><LI> Q (qmtp qsbmf) <UL> <LI> - <A HREF="draft-bernstein-qmtp-01.txt"> - draft-bernstein-qmtp-01.txt + <A HREF="draft-bernstein-qmtp-05.txt"> + draft-bernstein-qmtp-05.txt </A> - Quick Mail Transfer Protocol (QMTP) + This Internet-Draft has been deleted. <LI> - <A HREF="draft-bernstein-qmtp-05.txt"> - draft-bernstein-qmtp-05.txt + <A HREF="draft-bernstein-qmtp-01.txt"> + draft-bernstein-qmtp-01.txt </A> - This Internet-Draft has been deleted. + Quick Mail Transfer Protocol (QMTP) <LI> @@ -506,22 +535,22 @@ </UL><LI> R (rfc2487bis) <UL> <LI> - <A HREF="draft-hoffman-rfc2487bis-00.txt"> - draft-hoffman-rfc2487bis-00.txt + <A HREF="draft-hoffman-rfc2487bis-06.txt"> + draft-hoffman-rfc2487bis-06.txt </A> Internet Draft Paul Hoffman - <draft-hoffman-rfc2487bis-00.txt> Internet Mail Consortium - April 15, 1999 + draft-hoffman-rfc2487bis-06.txt Internet Mail Consortium + November 4, 2001 SMTP Service Extension for Secure SMTP over TLS <LI> - <A HREF="draft-hoffman-rfc2487bis-06.txt"> - draft-hoffman-rfc2487bis-06.txt + <A HREF="draft-hoffman-rfc2487bis-00.txt"> + draft-hoffman-rfc2487bis-00.txt </A> Internet Draft Paul Hoffman - draft-hoffman-rfc2487bis-06.txt Internet Mail Consortium - November 4, 2001 + <draft-hoffman-rfc2487bis-00.txt> Internet Mail Consortium + April 15, 1999 SMTP Service Extension for Secure SMTP over TLS @@ -541,6 +570,13 @@ <LI> + <A HREF="draft-bose-smtp-integrity-00.txt"> + draft-bose-smtp-integrity-00.txt + </A> + CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS + + + <LI> <A HREF="draft-hoffman-smtp-ssl-09.txt"> draft-hoffman-smtp-ssl-09.txt </A> @@ -551,13 +587,6 @@ <LI> - <A HREF="draft-bose-smtp-integrity-00.txt"> - draft-bose-smtp-integrity-00.txt - </A> - CHECKING OF MESSAGE INTEGRITY DURING SMTP TRANSACTIONS - - - <LI> <A HREF="draft-khanna-smtp-mail-transfer-reliability-01.txt"> draft-khanna-smtp-mail-transfer-reliability-01.txt </A> @@ -644,18 +673,17 @@ <LI> - <A HREF="draft-ietf-vpim-pndn-01.txt"> - draft-ietf-vpim-pndn-01.txt + <A HREF="draft-ema-vpim-pndn-04.txt"> + draft-ema-vpim-pndn-04.txt </A> This Internet-Draft has been deleted. <LI> - <A HREF="draft-burger-vpim-pc-01.txt"> - draft-burger-vpim-pc-01.txt + <A HREF="draft-ietf-vpim-pndn-01.txt"> + draft-ietf-vpim-pndn-01.txt </A> - This document has been replaced by draft-ietf-vpim-hint-00.txt.
- For more information or a copy of the document, contact the author directly.
+ This Internet-Draft has been deleted. <LI> @@ -681,10 +709,11 @@ <LI> - <A HREF="draft-ema-vpim-pndn-04.txt"> - draft-ema-vpim-pndn-04.txt + <A HREF="draft-burger-vpim-pc-01.txt"> + draft-burger-vpim-pc-01.txt </A> - This Internet-Draft has been deleted. + This document has been replaced by draft-ietf-vpim-hint-00.txt.
+ For more information or a copy of the document, contact the author directly.
</UL></UL> |