In the Message Bodies document:
Section 3, paragraph 4 uses the term "body part" not in conformance
with the definition in section 4.4. Suggest using the term "objects".
Section 3, paragraph 5, subsection (3) does not mention that the c-t-e
also specifies the domain of the result.
Section 3, paragraph 6, the sentence "In particular, all of these
header fields can incclude RFC 822 comments...". This is incorrect,
the Content-Description header field is an unstructured header field
and thus does not permit free insertion of linear white space and
comments. Also, other unstructured content header fields may be
defined in the future.
Section 4 repeatedly states that the definitions of the terms are
defined "in this document". They are actually definitions for all
MIME documents.
Section 4.2, remove the word "table-based". unicode-1.1-utf-7 is a
legitimate charset which is not table-based, at least for any
meaningful definition of "table-based".
I think we should replace the term "character set" with "charset",
to reduce the conflict with what other communities use the term
"character set" for. Another possibility would be to use the term
"character encoding".
The term "entity" is used in various places with meaning not in
conformance with the definition in 4.5. For example, the document
talks about "registration procedures for MIME-related entities"
I hate to say it, but I disagree with Ned about the new definition of
"body part". The term "body part" is used several places, especially
in section 7.1 of the media types document, to refer exclusively to
the parts of a multipart. Only one use of the term "body part" is
intended to include messages, I mention it later as needing
correction.
Section 4.10, replace the word "text" with "data". Lines are not
necessarily textual.
Section 5, the grammar nonterminal MIME-part-headers is unreferenced.
It does not permit "fields", especially "X-" headers; which are
permitted by section 7.1 of the media types document.
Section 7.1, grammar nonterminal "parameter" needs a comment stating
that matching of attribute is case-insensitive
The documents have uses of the terms "8-bit" and "7-bit" sprinkled
throughout, these should be "8bit" and "7bit".
Section 8.7, the senetence "Since the hyphen character ("-") is
represented as itself in" should replace "is" with "may be".
In the media types document:
Section 7.1 paragraph 4, "in which all parts actually are messages"
replace "all" with "most".
Section 7.2.1, paragraph 2, the term "body parts" should be
"entities", to be consistent with similar wording in section 7.1.
I actually think it makes more sense to talk about encodings for
bodies rather than encodings for entities or body parts.
In the registration procedures document:
There should be aliases for the ietf-types and ietf-charsets lists
established at ISI, forwarding mail to the actual site that runs each
particular list. The aliases should be what are published in the
document.
Section 7.1.4 should use the "7bit data", "8bit data", and "binary
data" terms defined in the message bodies document.
In the conformance document:
Requirement (2) should include a statement that readers must recognize
the "7bit", "8bit", and "binary" transfer encodings.
I had mentioned to Ned at the last IETF that there should be a
requirement for readers to treat bodies that have an unrecognized
Content-Transfer-Encoding as if the Content-Type were
application/octet-stream, regardless of whether or not the reader
recognizes the value of the Content-Type header. This requirement
should be added, probably as item (6), to the conformance document and
should be mentioned somewhere in section 8 of the message bodies
document (either 8.3 or 8.4).
--
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU
LoseNet: ...!seismo!ihnp4!wiscvm.wisc.edu!give!up