ietf-822
[Top] [All Lists]

Re: Last Call: SMTP Service Extensions for Transmission of Large and Binary MIME Messages to Proposed Standard

2000-05-26 07:02:55
This is a useful protocol and I support it moving to Proposed Standard.
However, I would suggest adding text covering two boundary conditions.  I do
not believe these changes are large enough to require a new Last Call.

First, I would add text stating that this extension IS suitable for use on
the Submission port, as described in Section 7 of RFC 2476.  This is
requested by RFC 2476 for all new SMTP Service Extensions.

I concur.  It's important that messages intended to be transmitted 
as BINARYMIME be submitted as BINARYMIME.

Second (and less important), I would state that although CR and LF do not
represent line endings in BDAT chunks, the RFC 2781 prohibition against
using a UTF-16 charset within the text top-level media type remains.  This
is because a gateway transformation of such a text object from BinaryMIME to
7bit or 8bit MIME would result in an improperly formatted MIME object that
could cause many existing mailers to fail.

Not that I disagree with the 2781 prohibition, but I think it has more to 
do with the content-transfer-encoding than the text/* media type.  A 
UTF-16 object encoded as base64 works just fine regardless of media type,
but a UTF-16 object encoded as 7bit or 8bit will fail regardless of
media type.

The problem with text/*, I suppose, is that a MTA converting the
message might decide that if an object originally encoded in 
base64 or binary is labelled as text/*, one of { 7bit, 8bit or 
quoted-printable } is an appropriate encoding for the converted 
object.  (actually quoted-printable is okay as long as 
it never contains "hard line breaks", but an encoder that assumes
that the input is text will probably generate hard line breaks for
CR LF sequences in the input.)

all of which illustrates (along with my earlier comment to iesg) that
re-encoding of MIME messages is subtle and has a number of pitfalls.
 
If the second point is considered obvious, feel free to leave it out.
However, HTTP/1.1 is exempted from this restriction in section 19.4.2 of RFC
2616, and one argument for that exemption is that HTTP is a binary-safe
transport.  

this isn't (intended to be) quite the same thing as you are saying.  
2616 is meant to allow text/* parts that normally use CRLF for 
line endings to use either bare CR or bare LF instead when they
are transmitted in HTTP.  but it doesn't (is not intended to) allow
the definition of new text parts that don't use CRLF as line endings.

There will clearly be much more gatewaying between BinaryMIME
MTAs and non-binary capable ones than from HTTP servers to non-binary
capable MTAs, so I believe that this (existing) restriction should be
reiterated.

not sure where it will fit in the document, but a discussion of
re-encoding subtleties, including a reference to RFC 2781, does
seem appropriate.

Keith