Fully interoperable email uses 7-bit ASCII, although some email
handling paths directly support 8-bit ASCII. Emoji characters are
drawn from the space outside of 7-bit ASCII. For email handling
paths that are 8-bit clean, the an emoji character does not need
special encoding. If the path from author to recipients is not
to be 8-bit clean, The emoji character SHOULD be encoded using
Emoji and any other code points outside the ASCII range MUST be encoded
using [MIMEencode], unless the message is Internationalized [RFC6532].
This thread is prompting a meta-thought. The thought is mostly driven by
the need for simplicity, especially across multiple specifications. The
specific directive applicable here is that normative redundancy is bad.
A specification which is only providing usage detail, within an
established context, rather than providing new context rules, SHOULD NOT
make additional normative declarations, within that context. Normative
language is needed only if the new specification is /changing/ that context.
Addition of normative declarations that merely replicate established
normative declarations invites errors.
Consequently, I'll now suggest this wording, for this specification:
Fully interoperable email uses 7-bit ASCII, although some email handling
paths directly support 8-bit ASCII. Emoji characters are drawn from the
space outside of 7-bit ASCII. [IntHdr] covers data encoding for email
header fields, along handling paths that are known to be 8-bit clean.
[MIMEencode] covers encoding for paths that are not known to be 8-bit clean.
ietf-822 mailing list