Re: Lastest drfat of RFC-XXXX

[Craig_Everhart@xxxxxxxxxxxx]

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.