[Python-3000] should rfc822 accept text io or binary io?

[Jeremy Hylton]

On 8/17/07, Bill Janssen <janssen at parc.com> wrote:
> > Ideally, the package would be well suited not only for wire-to-wire
> > and all-internal uses, but also related domains like HTTP and other
> > RFC 2822-like contexts.
>
> But that's exactly why the internal representation should be bytes,
> not strings.  HTTP's use of MIME, for instance, uses "binary" quite a
> lot.

In the specific case of HTTP, it certainly looks like the headers are
represented on the wire as 7-bit ASCII and could be treated as bytes
or strings by the header processing code it uses via rfc822.py.  The
actual body of the response should still be represented as bytes,
which can be converted to strings by the application.

I assume the current rfc822 handling means that MIME-encoded binary
data in HTTP headers will come back as un-decoded strings.  (But I'm
not sure.)  We don't have any tests in the httplib code for these
cases.  I would expect an application would prefer bytes for the
un-decoded data or strings for the decoded data.  Will email / rfc822
support this?

Jeremy

> > Internally though, I feel fairly strongly that an email
> > message should be represented as strings, though sometimes (certainly
> > for idempotency) you still need to carry around the charset (i.e.
> > encoding).
>
> What if you've got a PNG as one of the multipart components?  With a
> Content-Transfer-Encoding of "binary"?  There's no way to represent that
> as a string.
>
> I wonder if we're misunderstanding each other here.  The "mail
> message" itself is essentially a binary data structure, not a sequence
> of strings, though many of its fields consist of carefully specified
> string values.  Is that what you're saying?  That when decoding the
> message, the fields which are string-valued should be kept as strings
> in the internal Python representation of the message?
>
> Bill
>
> _______________________________________________
> Python-3000 mailing list
> Python-3000 at python.org
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: http://mail.python.org/mailman/options/python-3000/jeremy%40alum.mit.edu
>