NOTE: In certain transport domains, the RFC 822 restriction that limits
body-parts to printable ASCII characters may have been removed. Such
removal should be construed as locally extending the definition of
body-part to include octets outside of the ASCII range.
Seems like a good general strategy. Anyone feel like changing a few
words to generalize it, e.g., something like...
NOTE: In certain transport domains, RFC 822 restrictions such as the
one that limits body-parts to printable ASCII characters may have been
removed. Such removal should be construed as locally extending the
definition of body-part to include octets outside of the ASCII range or
other body-part extensions beyond strict reading of RFC 822 as long as
those are supported by the transport and adequately documented in
Content-transfer-encoding information.
Even if things are not generalized in this way, it is useful to recall
that the extension to non-ASCII octets really requires two separate
things:
-- A content-transfer-encoding of 8bit or the equivalent
-- Transport arrangements that legitimize the use of such a c-t-e.
Neither one alone suffices, and it would be possible for someone looking
for justification of bad practice to read the original note as implying
that, if the transport supported 8bit characters, it was not necessary
to specify an 8bit C-T-E, i.e., that 8bit would become the default in
the presence of 8bit transport.
john