Section 2: Content-Type Header Field
1. In addition to the proposed standard types, RFC-XXXX should include a
"822-message" type. This "822-message" type indicates the enclosed
document consist of an entire embedded RFC-822 compliant message
(i.e. header fields, blank line and body). Note, it is different
from MAILASCII which only refers to the default message body type.
2. A while ago an issue was brought up that there was a need to identify
the character-set in a separate header field, instead of overloading
the Content-Type field. The issue may not be obvious to the
human-language text message body, but it becomes obvious when
non-US-ASCII characters are embedded in some human readable typed
message (such as TROFF.)
The whole idea is to use Content-Type to bring up a proper editor,
viewer or text processor and use a new field (e.g. Codeset) to
identify the character set for additional information. This
generalized idea also extends to any human-language text body part.
The value of "Codeset" may be in "ISO-IR-x" format, or the
registered names for ISO10646 or Unicode, or "X-"atom. If this field
does not exist, the original contents will be assumed to be in human
non-readable format.
In following example, "text" is picked arbitrarily to identify the
human-language text body part in IA5-TEXT. And troff is in US-ASCII.
--gc0p4Jq0M2Yt08jU534c0p
Content-Type: troff; null; tbl
Codeset: ISO-IR-6
......
--gc0p4Jq0M2Yt08jU534c0p
Content-Type: text
Codeset: ISO-IR-2
......
--gc0p4Jq0M2Yt08jU534c0p
3. Content-Type should not contain different name-spaces for compressed
data. It is because compression is an operation, not a data type.
If compressed information is needed, it should be in a separated
header field. See additional comment in Section 3. If this concept
is acceptable, RFC-XXXX should state this clearly.
4. U-LAW and A-LAW. Should it be typed as "audio" and put "U-LAW"/"A-LAW"
in the resource-ref field?
5. How do we encapsulate X.400 body parts? Should Content-Type just identify
the type and use "Content-Encoding" to say that it's ASN.1 encoded?
6. There is typo in DES-MESSAGE paragraph (page 5):
"encrytped" -> "encrypted".
Section 3: The Content-Encoding Header Field
1. Since "BASE64" is a better encoding scheme than "HEXDECIMAL", we would
recommend to drop "HEXDECIMAL". It is understood that "HEX" converter
is easily implemented and may be widely available. Here is the
concerns: people may use the same argument to say that "uuencode" is
also widely available, so RFC-XXXX should include it. In general,
we would like to keep the number of encoding operations as small as
possible.
2. Hopefully, the following chart may provide a clearer definition of
encoding for UA's and gateways.
TRANSPORT| BINARY-SMTP 8BIT-SMTP 7BIT-SMTP
SOURCE DATA |
-------------------------------------------------------------
7-bit data | 7BIT 7BIT 7BIT
8-bit data | 8BIT 8BIT QUOTED-PRINTABLE
Binary data | BINARY BASE64 BASE64
3. There are 2 types of encodings: transport dependent and data
dependent. "Transport Dependent" encoding is an encoding scheme to
work around the limitation of transport protocol. And
"Content-Encoding" header field describes the transport dependent
encoding.
4. "Data dependent" encoding (conversion) may include encryption,
compression or ASN.1 encoding. This type of encoding is totally
independent from the transport protocol. We encourage that RFC-XXXX
to propose a new header field for data dependent encoding, e.g.
"Content-Conversion". This field may be multi-valued.
Note, during the encoding operations, all operations specified in
"Content-Conversion" must be performed prior to the operation in
"Content-Encoding". During the decoding operations, the reverse
operation in "Content-Encoding" must be performed before
"Content-Conversion."
Section 4: The "Multipart" Content-Type
1. "1-S" and "1-P". I can sympathize with the wish to include hints
about how to display the attachment stream, but I don't think that
serial vs parallel is enough information. Given this, I'm against
putting in half a solution.
Should someone be able to complete a design that would take
advantage of parallel display of the body parts, we could add that
in later. This new design could define new message headers with the
proper information, like Parallel-headers: <aaa>, <bbb> where aaa
and bbb are content-id fields from the various body parts.
2. From the previous lengthy dicussions about "prefix" area, there were
some strong reasons that "prefix" and "postfix" areas should be
dropped.
Section 5: A Complex Multipart Example
1. In the example, there shouldn't be any "From: ..." and "Subject: ..."
in the SGML body part.
Section 6: The Encoded-Variable Header Field
1. In the example,
Encoded-Variable: Keld_JXrn_Simonsen = quoted-printable, iso646,
Keld_J&0Crn_Simonsen
Shouldn't "iso646" be replaced by "ISO-IR-x" format? I think having
a uniform name space for character set is important.
Section Appendix A: The Character Set for the MAILASCII Content-Type
1. State clearly that the five-point section on page 21 documents the
common non-compliant implementations of SMTP that we are working
around; it is *not* a set recommended practices. It is a hall of
shame, not a hall of fame.
2. (4) should be rewritten as:
Lines longer than 80 characters may be wrapped *or truncated* in some
environments. Line wrapping *and truncation* are STRONGLY DISCOURAGED...
3. (5) should be added with:
Discarding trailing "white space" is STRONGLY DISCOURAGED.
Addtional comment:
1. An *optional* "Content-Label" header field in each body part is
proposed here. This field allows the user to specify a name for a
body part and to refer a body part by name in other context.
-Vincent Lau & Neil Katin