Ned Freed <NED(_at_)innosoft(_dot_)com> writes:
If you want to address particular uses of the term "body part" you
are going to have to do them on a case by case basis, and I'll warn
you right now that I will be VERY reluctant to change any of them.
I have reread the discussion you had with Alain Fontaine on this list
and have analyzed the current draft document. In short, I believe I
understand what it is you are trying to accomplish with the definition
of "body part" in section 4.4 of the message bodies document, but I do
not understand the definition itself nor how it accomplishes what you
are trying to do.
Here is the requested case-by-case analysis:
Message bodies, Section 4.3: The term "body" would be more
appropriate. Failing that, "entity".
Message bodies, Section 4.4: The "content headers and contents of a
message" part of the definition is the only object defined in MIME
which is not necessarily represented as a contiguous sequence of
octets. The "the content headers and contents of one of the parts in
the body of a multipart entity" part of the definition is similar to,
but distinctly different than the object corresponding to the
"body-part" nonterminal in the multipart grammar. The latter object
may contain "X-" and other non-content headers, which are excluded
from this definition of "body part".
Message bodies, Section 4.5: Since objects corresponding to the
"body-part" nonterminal can have non-content headers, such objects do
not qualify for the term "entity".
Message bodies, Section 5 (2): this use of "body part" is specific to
Message bodies, Section 6: this use of "body part" is specific to
Message bodies, Section 8.4, paragraph 1: this use of "body part" is
specific to multiparts.
Message bodies, Section 8.4: the term "enclosed parts" has no
definition, should probably be "enclosed entities".
Media types, section 5 (composite 2): this use of "body part" is
specific to multiparts.
Media types, section 7.1: all uses of "body part" are specific to
``The body must then contain one or more "body parts,"
each preceded by a boundary delimiter line, and the last one
followed by a closing boundary delimiter line.After its
boundary delimiter line, each body part then consists of a
header area, a blank line, and a body area. Thus a body part
is similar to an RFC 822 message in syntax, but different in
-- Refers to the body-part BNF nonterminal, not the
definition in the message bodies document.
``The only header fields that have defined meaning for body
parts are those the names of which begin with "Content-". All
other header fields are generally to be ignored in body parts.
Although they should generally be retained if at all possible,
they may be discarded by gateways if necessary. Such other
fields are permitted to appear in body parts but must not be
-- Ditto. This use of the term "body part" actually
contradicts the definition in message bodies section 4.4,
since the latter excludes non-"Content-" headers by
For brevity, I won't list all the other occurences of the term "body
part" in 7.1.
Message bodies, Section 7.2.1, I've previously mentioned that this
needs to be "entity" or "body", I'll deal with this later in this
Registration, Section 6: Should be "entity", to be consistent with the
external-body wording in the Media Types document.
Conformance, Section 4 (4): all uses of "body part" are specific to
Conformance, Appendix A (6): neutral w.r.t. this issue
Conformance, Appendix A (7): this use of "body part" is specific to
Conformance, Appendix A (8): this use of "body part" is specific to
The problem is that we define rules for body parts that have to
apply to both the multipart and single part cases but don't apply to
Could you give me an example of such a rule?
I'm wondering if the problem is the definition of "entity". It
probably should be defined as a primitive type, not in terms of
"message" or "body part". My attempt would be "zero or more headers,
optionally followed by a blank line and a body", with a BNF of
entity = *field [ CRLF *OCTET ]
It then follows that "message" and "body-part" are subsets of
The intent was always to tie this definition into the body-part BNF, but the
change slipped through the cracks. I've therefore changed the BNF for
to read as follows:
body-part := MIME-part-headers *( CRLF *text )
; Lines in a body-part must not start
; with the specified dash-boundary and
; the delimiter must not appear anywhere
; in the body part. Note that the
; semantics of a body-part differ from
; the semantics of a message, as
; described in the text.>
bodies are no longer restricted to 7bit data, so "*text" isn't
I actually dislike this change, putting the restrictions after
semicolons instead of angle brackets is just asking for some cretin to
claim that they are not strictly part of the definition of body-part.
I really don't see the purpose of defining MIME-part-headers, it just
perpetuates the idea that a body-part is a fundamentally different
type than a message, instead of them both being subtypes of the same
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.
Disagree. It doesn't necessarily make sense to restrict the CTE of
messages in general, since not all messages are MIME messages. It is
entirely possible for there to be a non-MIME usage of a
content-transfer-encoding header where a message ends up with some
other CTE. (I would oppose any attempt to specify such usage, but
that's beside the point.)
The use of the term "body part" here stays.
The difference between the terms "body parts" and "entities" is a
difference in the type of enclosing object. Regardless of whether or
not it is necessary to prohibit encodings on a given set of objects at
all, it does not make any sense to prohibit encodings when a given
object is contained in a multipart, but not prohibit encodings when a
given object is contained in a (message bodies 4.3 definition)
Now, it just so happens that I have a big problem with allowing
encodings on any subtype of the "message" top-level content type, but
that's a separate issue. I will deal with that in a separate message,
once I dig up and go through all the relevant archives.
_.John G. Myers Internet: jgm+(_at_)CMU(_dot_)EDU