RFC 1521:MIME (Multipurpose Internet Mail Extensio...
RFC-Ref

implementor


Click on the red underlined text to get to the source

... standardization state and status of this protocol. Several other RFC documents will be of interest to the MIME implementor, in particular [RFC-1343], [RFC-1344 ...


... BNF notation of RFC 822std11(-> 2822prop). Implementors will need to be familiar with this notation in order to understand this specification, and are referred to RFC 822std11(-> 2822prop) ...


... content-type field if necessary. NOTE TO IMPLEMENTORS: All header fields defined in this document, including MIME-Version ...


... as "text/plain; charset=us-ascii", implementors should remain aware that if a message lacks both the MIME-Version and the ...


... requirements if unencoded. Implementors may, if necessary, define new Content-Transfer-Encoding values, but must use an x-token ...
... encoding. WARNING TO IMPLEMENTORS: If binary data are encoded in quoted- printable, care must be taken to encode CR ...


... begin with "X-". Implementors are discouraged from defining new character sets for mail use unless absolutely necessary. ...
... header field. The use of similar syntax facilitates the conversion of messages to body parts, and vice versa, but the distinction between the two must be understood by implementors. (For the special case in which all parts actually are messages, a "digest" subtype is also defined.) ...
... ever desired. WARNING TO IMPLEMENTORS: The grammar for parameters on the Content- type field is such that it is often necessary to enclose the ...
... boundaries in quotes on the Content-type line. This is not always necessary, but never hurts. Implementors should be sure to study the grammar carefully in order to avoid producing illegal Content-type ...
... an earlier alternative, or both. NOTE: From an implementor's perspective, it might seem more sensible to reverse this ordering, and have the plainest alternative last. However, placing the plainest alternative first ...
... (computational) email. (The latter, in particular, can pose security problems which must be understood by implementors, and are considered in detail in the discussion of the application/PostScript ...
... PostScript interpreters entails serious security risks, and implementors are discouraged from simply sending PostScript email ...
... While it is usually safe to send PostScript to a printer, where the potential for harm is greatly constrained, implementors should consider all of the following before they add interactive display of PostScript ...
... In general, the use of "X-" top-level types is strongly discouraged. Implementors should invent subtypes of the existing types whenever possible. The invention of new types is intended to be restricted primarily to the development of new media types ...


... character sets. Additional optional header fields provide mechanisms for certain extensions deemed desirable by many implementors. Finally, a number of useful Content-Types are defined for general use by ...


... Security issues are discussed in Section 7.4.2 and in Appendix F. Implementors should pay special attention to the security implications of any mail content-types that can cause the remote ...



Google
Web
RFC-Ref