US-ASCII
Click on the red underlined text to get to the source
...
The default character set, US-ASCII, has been the subject of some
confusion and ambiguity in the past. Not only were there some
...
... character set, but specifies that all octets in the body must be
interpreted as characters according to the US-ASCII character set.
National and application-oriented versions ...
... ISO 646 [ISO-646] are
usually NOT identical to US-ASCII, and in that case their use in
Internet mail is explicitly discouraged. The omission of the ISO ...
... character set from this document is deliberate in this regard. The
character set name of "US-ASCII" explicitly refers to the character
set defined in ANSI X3.4-1986 [US-ASCII ...
... US-ASCII" explicitly refers to the character
set defined in ANSI X3.4-1986 [US-ASCII]. The new international
reference version (IRV) of the 1991 edition of ISO ...
... version (IRV) of the 1991 edition of ISO 646 is identical
to US-ASCII. The character set name "ASCII" is reserved and must not
...
... versions of
ISO 646 than US-ASCII and the 1991 IRV, or using code-switching
procedures (e.g., those of ISO 2022), as well as 8bit ...
... control characters including DEL (0-31, 127) have no
defined meaning in apart from the combination CRLF (US-ASCII values
13 and 10) indicating a new line. Two of the characters have de
facto meanings in wide use: FF ...
... X. Characters with values below 128 in ISO-8859-X have the same
assigned meaning as they do in US-ASCII.
...
... MIME. This document does not
endorse the use of any particular character set other than US-ASCII,
and recognizes that the future evolution of world character sets
...
... denominator" character set possible. For example, if a body contains
only US-ASCII characters, it SHOULD be marked as being in the US-
ASCII character set, not ISO ...
... ISO-8859
family of character sets, is a superset of US-ASCII. More generally,
if a widely-used character set is a subset of another character set ...
... permitted for entities of type "multipart". The "multipart" boundary
delimiters and header fields are always represented as 7bit US-ASCII
in any case (though the header fields may encode non-US-ASCII ...
... US-ASCII
in any case (though the header fields may encode non-US-ASCII header
text as per RFC 2047draft ...
... --simple boundary
This is implicitly typed plain US-ASCII text.
It does NOT end with a linebreak.
--simple boundary
...
... charset=us-ascii
This is explicitly typed plain US-ASCII text.
It DOES end with a linebreak.
...
... transport enclaves, RFC 822std11(-> 2822prop) restrictions such as
the one that limits bodies to printable US-ASCII characters may not
be in force. (That is, the transport domains may exist that resemble
...
... these restrictions should be construed as locally extending the
definition of bodies, for example to include octets outside of the
US-ASCII range, as long as these extensions are supported by the
transport ...
... message
headers or body part headers) allowed to contain anything other than
US-ASCII characters.
...
... entity. The message header fields are
always US-ASCII in any case, and data within the body can still be
encoded, in which case the Content-Transfer-Encoding header field ...
... header field in
the encapsulated message will reflect this. Non-US-ASCII text in the
headers of an encapsulated ...
... tokens that describe external-body
data, such as file names and mail server commands, are required to be
in the US-ASCII character set.
...
... message/external-body" data must be used to declare the media type
of the external body if it is anything other than plain US-ASCII
text, since the external body does not have a header section to
declare its type. Similarly, any Content-transfer-encoding ...