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.
Actually, you are both correct. Both the media type text/* and the 7bit and
8bit encodings prohibit UTF-16 content. That is, you aren't allowed to use
UTF-16 with text/plain even if you use base64 or binary encoding. This is
explicit and intentional.
This requirement arises from the need to be able to switch from one encoding to
another without incident, not directly from the 7bit and 8bit encodings
themselves. But regardless of origin, the requirement is there for both things.
And I see no harm with reiterating this requirement here. But if it is
done both halves need to be reiterated.
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.
It is required that such transcoding be possible. But it is less from the
need to be able to trancode and spit out text/plain; charset=utf-16,
CTE 8bit on the wire than from a need to transcode and be able to put
something into a file that applications can deal with. That is, the
restrictions on 8bit are mostly for backwards compatibility.
(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.)
I prefer to see it as a simple requirement: In text/* CR and LF have to be
represented as 13 and 10 and nulls are prohibited. See RFC 2046, section 4.1.1.
Worrying about why this is so is academically interesting but not especially
relevant to implementations. We can spend lots of time discussing why
a given requirement is there, but at the end of the day the important point
is that it is there and you need to follow it.
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.
Well, it ain't all that subtle. The rules are quite clear; the pitfalls the
direct result of flagrant violations of the rules. You don't need to know
the whys; if you just follow the rules you should be OK.
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.
Correct; if you want to use UTF-16 with, say, HTML, you are supposed to use
application/html, not text/html. Even in HTTP, although it is weakened to
a SHOULD not a MUST.
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.
The only case I can see for this being as nonobvious and people seem to
think is that the requirements, although clearly stated, are scattered
throughout a set of very large documents. If that's the problem then the way
to fix it is to have a separate document that collects all of this stuff
and explains how to do these various sorts of transcodings. And hiding
that in the BINARYMIME specification isn't markedly more useful than
hiding it in the MIME specification itself.
Somewhere I have the text that originally was to be in the 8bitMIME
document that explained how to transcode (the working group forced me to
remove it); I suppose I could resurrect it if need be. I do note, however,
that the 8bitMIME transcoding experience has been remarkably free of
broken implementations; while there are lots of problems with MIME
coding out there I don't think I've ever traced one back to a transcoder.
Ned