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.
Then suggest alternative prose. We're years past the point where such
generalities are acceptable input.
Here is the requested case-by-case analysis:
Message bodies, Section 4.3: The term "body" would be more
appropriate. Failing that, "entity".
Agreed and changed.
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".
I sort of agree with you about non-content headers actually being allowed in
body parts. They are allowed syntactically but they have no sematics
associated with them. And this in turn gets at the root of the problem --
there's a confusion between syntactic entities, where all sorts of nonsense is
allowed, and the semantics that are derived from that syntax, where the
requirement is that certain things (e.g. non-content header fields) have to be
ignored.
You tend to see things almost exclusively in terms of syntax. I do not. I see
the various aspects of MIME in terms of the abstractions they are intended to
represent and how their semantics tie in with those abstractions. Syntax then
follows as secondary (or tertiary) concern. And there is quite clearly a HUGE
difference in the abstract between a body part and a message. The fact that
they have nearly identical syntax does not mean that they are in fact the same
-- they aren't. As such, trying to tie these things down using syntax as a
distinguishing factor clouds the issues rather than clarifying anything.
Part of the problem surrounding the term "body part" is that this term has a
well understood meaning semantically. It always has. But our definition tied
the term to syntax that was at odds with how it was actually used, both in the
MIME specification as well as elsewhere.
Anyway, I'm perfectly willing to try to make this more precise and cover all
the bases. How about:
The term "body part" refers to headers and contents of either a message or one
of the parts in the body of a multipart entity. Any sort of header may be
present but only the content headers actually have any meaning in the context
of a body part. A body part has a header and a body, so it makes sense to speak
about the body of a body part.
Is this acceptable?
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".
Again, syntax and semantics are getting confused. Body parts can have
non-content headers, but such headers do not tie into the body in any way.
(They may of course be associated with the message itself, but that's quite a
different matter.)
The solution therefore is to fix the definition of body part to make a
distinction between what can be present and what actually has meaning.
Message bodies, Section 8.4, paragraph 1: this use of "body part" is
specific to multiparts.
Incorrect. CTE headers appear in contexts other than multiparts.
Message bodies, Section 8.4: the term "enclosed parts" has no
definition, should probably be "enclosed entities".
Changed.
Media types, section 5 (composite 2): this use of "body part" is
specific to multiparts.
Also incorrect. However, it would be better to simply say entities here instead
of "messages and body parts".
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
message.
Registration, Section 6: Should be "entity", to be consistent with the
external-body wording in the Media Types document.
There's nothing inconsistent about the *term* here. The media types document
talks about message/external-body entities, which is somewhat nonspecific but
acceptable. (Using the term body part, which is a bit more precise, in this
context with all of the other uses of the term "body" floating around makes the
prose very hard to follow.) However, the registration document speaks
of messages containing body parts of the message/external-body media type,
which is also fine.
The only thing that's inconsistent here is the prose around the terms, rather
than the terms themselves. I'll change the related prose so the same terms
can be used in both places.
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
all entities.
Could you give me an example of such a rule?
Any rule that defines something specific to MIME represents such an example.
Entities can be messages and messages don't have to be MIME messages, hence
MIME rules don't necessarily apply to all entities.
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
"entity".
This is OK syntactically, but loses seriously on the semantics front. I
don't see any way of making this change without making things even more
confusing.
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
body-part
to read as follows:
bodies are no longer restricted to 7bit data, so "*text" isn't
appropriate.
Neither is the original definition then. I'll change it to read:
body-part := MIME-part-headers [CRLF *OCTET]
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'm sorry, but any interpretation that says comments are not part of the
definition is simply wrong. Trying implementing RFC822 strictly from the BNF
and no comments and see what you get.
The original definition here was simply a comment hiding as prose in the BNF
anyway.
Nero Wolfe was once asked if there was any challenge he would not accept. He
said, "I would not undertake to put sense into a fool's brain." I suggest that
we not undertake this either.
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
basic type.
But they *are* fundamentally different, despite the fact that both are subsets
of what we call entities. We can either call this out syntactically or not. I
think given this discussion its best that we call it out as plainly as
possible!
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)
message.
True enough I guess, but since message/rfc822 can only appear as part of a body
part inside of some enclosing context, I don't see that it makes much
difference.
I actually like your original suggestion that we refer to
the encoding of the body rather than that of the body part or entity better, so
that's what I'll change it to.
Ned
P.S. I also found the use of the term "entity" to refer to registerable
things and to RFC822 syntax rules to be more than a little confusing.
I've therefore changed the specifications so these things are no longer
referred to as entities.