[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
> > Good point.
> > Regardless of what 1521 says, I believe that 8bit c-t-e was intended
> > for "plain text" in so-called "8-bit character sets" that are similar
> > to ASCII, and will probably be treated that way.
> Similar to ASCII, sure.
Similar to ASCII in that the 8-bit character set contains the
ascii character set as a subset, and uses the same code points
for CR and LF.
> On the other hand, there are no, documented nor defacto, definition of
> what code points constitutes "plain text".
What's your point?
> > > OK. You insist that there are various kinds of "8bit" CTEs.
> > NO I DO NOT. Where did you get that idea?
> If some 8bit VTE can pass some character and some can't, they are of
> different kind.
There is only one content-transfer-encoding named "8bit".
> If an MTU receives a 8bit mail from 0-255 channel and relay it to
> somewhere else through 1-255 channel, what happens?
If the message contains 8bit character text, nothing bad will happen.
Anything else should not have the content-transfer-encoding of 8bit,
at least not if it needs to get transmitted without loss.
> Should the MTU read the whole content of the mail to check whether
> a NULL byte is included in the message or not?
No. The whole point of the c-t-e distinction between binary/8bit/7bit
is that the USER AGENT does the labelling. That way the MTAs don't
have to do two passes.
But I don't think it is important to have a c-t-e that says
"this body part can contain any octets between 1 and 255 inclusive"
as opposed to one that says
"this body part can contain any octets between 0 and 255 inclusive".
We don't need things to be that fine-grained.
What we have now is one that was intended to say (something like):
"this body part can contain any octets which are used to represent
printable characters in iso 8859/* character sets, plus the octets
used for control characters (1-31) in the ascii character set.
it must consist of line-oriented text with the lines no more than
1000 characters in length, but the lines may be wrapped to a
shorter length in transit. horizontal tab characters may appear
in the original, but they may get translated to spaces. lines
may be terminated with any of cr, lf, or crlf, but the line endings
may be altered during transmission."
and so forth.
Expressed in a different way, mail with c-t-e 8bit may be subjected
to the same tortures as was traditionally the case with 7bit mail,
except that the 0x80 bit cannot be stripped.
Of course this is my opinion. Others may think it was intended
to encompass something a bit broader.
I think we would certainly do well to tighten up the definition
of 8bit in the next version of MIME.