1 - 2 - 7 - 8 - A - B - C - D - E - F - G - H - I - J - L - M - N - O - P - Q - R - S - T - U - V - W - X
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
...
