On Thu, 27 Oct 1994, Steve Dorner wrote:
At 8:54 PM 10/27/94, Mr Rhys Weatherley wrote:
... and NO octets are dropped. Everything goes through unchanged,
including NULs.
Definitely agree with the NULs.
There is still a question in my mind about what you mean by "unchanged", as
Now I'm confused. It was my understanding that binary was intended to
transport things directly that are at the moment are encoded in base64.
If you send a newline in binary it must be CRLF and it must not be messed
with by the transport. This puts a more stringent requirement on the
interaction between the MUA and the MTA. If the MTA says "I have no idea
what CTE:binary is", then the MUA must convert it into something else.
That was the way I always understood it. If the transport is free to mess
with the contents then we will be stuck with base64-grottiness forever.
I'd like to see a gradual progression to a world that can send real
binary parts, labelled as such, and avoid encodings which add 33% to the
size of the message.
well as what 1521 means by "does not obey SMTP CRLF semantics".
To me it means that the contents of a binary body part can be anything.
There could be bare CR's and LF's all over the place and they have to be
left as is. Only when text/* types are being sent is CRLF required to
terminate lines. But that's part of the CT semantics, not the CTE
semantics. You could easily slip in another bare CR or LF, but that's
for the CT processor to worry about, not the CTE processor.
1. Normal text with lines, just very long ones.
If user wishes to send normal text with very long lines, you should either
encode it in quoted-printable, or pick the user up and hang them by the
short and curlies for wanting to do something stupid. CTE:binary
shouldn't be used for this unless the MTA supports it, and in that case
the line endings for subtypes of text must be CRLF and unconvertible. If
we start sending binary things through MTA's that don't support it, then
the real use for binary as an alternative to base64 will be eroded.
RTF is an interesting special case. I'd handle it by canoncialising the
line endings to what the RTF spec thinks is the right line ending (be it
CRLF, LF, CR, or whatever), and then send it as base64 or binary (probably
base64). It's not like RTF text is readable by humans in its native form
anyway.
Cheers,
Rhys.