Messages specify either that X.400 non-textual body parts must beĬonverted to (not encoded in) an ASCII format, or that they must beĭiscarded, notifying the RFC 822 user that discarding has occurred. The current standards for the mapping of X.400 messages to RFC 822 Inclusion of non-textual body parts within electronic mail messages. The limitations of RFC 822 mail become even more apparent as gatewaysĪre designed to allow for the exchange of mail messages between RFC 822 hosts and X.400 hosts. Scheme specified in RFC 1421, the Andrew Toolkit Representation Internet include pure hexadecimal, uuencode, the 3-in-4 base 64 Examples of such encodings currently used in the This forces users toĬonvert any non-textual data that they may wish to send into seven-īit bytes representable as printable ASCII characters before invokingĪ local mail UA (User Agent, a program with which human users sendĪnd receive mail). Relatively short lines of seven-bit ASCII. The fact that they limit the contents of electronic mail messages to One of the notable limitations of RFC 821/822 based mail systems is
Since RFC 822 does not specify mechanisms for mailĬontaining audio, video, Asian language text, or even text in mostĮuropean languages, additional specifications are needed. Languages require the use of character sets richer than US ASCII However, RFC 822 is inadequate for the needs of mail users whose Non-text messages, such as multimedia messages that might includeĪudio or images, are simply not mentioned. RFC 822 was intended to specify a format for text messages. Increasingly restrictive for the user community. As theįormat has seen wider use, a number of limitations have proven Internet SMTP transport defined by STD 10, RFC 821. Wholly or partially, well beyond the confines of the Internet and the Success has been such that the RFC 822 format has been adopted, The standard format of textual mail messages on the Internet. Since its publication in 1982, STD 11, RFC 822 has defined 74 Appendix G - Canonical Encoding Model. 73 Appendix F - Summary of the Seven Content-types.
#Adapted base64 encoding java registration#
72Į.2 Registration of New Access-type Valuesįor Message/external-body. 72 E.1 Registration of New Content-type/subtype Values. RFC 1521 MIME September 1993 Appendix E - IANA Registration Procedures. 63 Appendix C - A Complex Multipart Example. 60 Appendix B - General Guidelines For Sending Email Data. 58 Appendix A - Minimal MIME-Conformance. The Application/Octet-Stream (primary) subtype. Optional Content-Description Header Field. Quoted-Printable Content-Transfer-Encoding. The Content-Transfer-Encoding Header Field. Notations, Conventions, and Generic BNF Grammar. Significant differencesįrom RFC 1341 are summarized in Appendix H.ġ. This document does NOT extend Internet mail header fields to permitĪnything other than US-ASCII text data. In character sets other than US-ASCII, to represent formatted multi-įont text messages, to represent non-textual material such as imagesĪnd audio fragments, and generally to facilitate later extensionsĭefining new types of Internet mail for use by cooperating mail Include multiple objects in a single message, to represent body text In particular, this document is designed to provide facilities to Because RFC 822 said so little about message bodies, thisĭocument is largely orthogonal to (rather than a revision of) RFC 822. This is based on earlier workĭocumented in RFC 934 and STD 11, RFC 1049, but extends and revises Textual and non-textual message bodies to be represented andĮxchanged without loss of information. Thisĭocument redefines the format of message bodies to allow multi-part The message content, or message body, as flat ASCII text. Specifies considerable detail about message headers, but which leaves STD 11, RFC 822 defines a message representation protocol which Official Protocol Standards" for the standardization state and status Please refer to the current edition of the "Internet Internet community, and requests discussion and suggestions for This RFC specifies an Internet standards track protocol for the MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
Updated by: 1590 Network Working Group N. RFC 1521: MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies
0 kommentar(er)
