[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Lastest drfat of RFC-XXXX
Excerpts from transarc.system.ietf-smtp: 20-Mar-91 Re: Lastest drfat of
RFC-XXXX Neil Rickert@cs.niu.edu (1149)
> > The valid encoding types that generate seven-bit ASCII output are:
> > o BASE64
> > o HEXADECIMAL
> > o QUOTED-PRINTABLE
> > o NONE
> In the listed encoding types, three are encoding types for characters
> or 8 bit bytes. The remaining one, BASE64, is an encoding for a bit-stream.
> There needs to be a clarification on the conversion between a bit stream and
> a character stream. I presume this was intended to follow the Internet
> standard of most significant bit first - but it unless properly clarified
> it will likely be interpreted by some as following the conventions of
> RS232 with the least significant bit first.
This is a good point.
I'd argue that any of the (here-unspecified) ``encoding'' operators that
don't produce seven-bit ASCII (i.e. that require further encodings, like
tar, compress, and my suggested ``signature'' one) need this kind of
interface within which they can be specified--viewing at least their
outputs as a bit-stream or a character-stream or whatever. That is, to
construct or interpret (or even to specify) a piped encoding, you have
to know what form the input and output for each stage takes.