Yes and no. Yes, this is the usage we're getting at, but no, it isn't a
question of "wanting to use". It absolutely has to be this way. The MIME
specification ties all sorts of characteristics to body parts. These have to
apply to single part messages. If they don't the MIME specification fails to
specify most MIME usage. It really is just this simple.
And also:
Isn't it obvious that this is a HUGE problem, and the definition absolutely
MUST change to correct it?
At the highest level, what I understand is that there was a 'huge problem'
in MIME for 4-5 years, because the term 'body part' could not be used
to speak about what's in a message that is not a 'multipart'. Actually,
during the five first years of MIME development, the object that has been
put forward was 'body'. And yes, with MIME, a message can contain either
one body, or several bodies, of different types if one wants it. All of
RFC1521 consistently speaks about 'bodies', data in a body, etc. A few
examples:
R> 2. A Content-Type header field, generalized from RFC 1049 [RFC-1049],
R> which can be used to specify the type and subtype of data in the
R> body of a message and to fully specify the native representation
R> (encoding) of such data.
R> (4) Two additional header fields that can be used to
R> further describe the data in a body, the Content-ID and
R> Content-Description header fields.
R> The purpose of the Content-Type field is to describe the data
R> contained in the body fully enough that the receiving user agent can
R> pick an appropriate agent or mechanism to present the data to the
R> user, or otherwise deal with the data in an appropriate manner.
R> Transfer-Encoding" header field. The Content-Transfer-Encoding field
R> is used to indicate the type of transformation that has been used in
R> order to represent the body in an acceptable manner for transport.
R> A Content-Type of "video" indicates that the body contains a time-
R> varying-picture image, possibly with color and coordinated sound.
--- The same wording is used for each type...
So MIME was designed consistently to say things about bodies. Why bodies ?
Because bodies is what interest users. Header are a nuisance that is needed
to qualify a body, to permit it's proper interpretation by software, but
still is a nuisance for the user. Take the example of a computer file
storage. What is interesting is the files. We all know that there is a
directory structure to keep track of the files, to associate some attributes
to them, etc, but what everybody is interested in, speaking of, etc, are
'files'. And so in MIME the interesting object is a 'body', which contains
actual user data. And for years, MIME has consistently put 'bodies' forward,
and 'body' could actually be used the way you now want to use 'body part'.
the resulting
specification contained many inconsistencies, loopholes, and ambguities and I
cannot see how you could possibly have reconciled yourself to them all.
Warning: the following paragraph includes a disagreement statement.
I don't know how you handle such things, but I would certainly find my
keyboard very hot if I would type such a judgement about a document that
has been under close scrutinity by a large number of people for several
years. I tend to think that many of those people did actually read the
document as such a work must be read, that is by reading the definitions,
understanding them, and then reading the rest of the text with those
definitions in mind. You are in fact accusing all the people who took part
in the discussions of being unable either to practice proper document
reading as described above, or to see a HUGE problem for years. I take the
position that if no revolution has taken place yet in the group, it's
because when read correctly, RFC1521 (and its predecessor RFC1341 - which
is identical in this respect) is consistent as stated above.
Now to more specific discussion points:
There's only one little problem with this: I've already done it! And the result
of this procedure is the present document in its present form.
You must be kidding.... Just thinking 'If I do that job, it will certainly
give that result' is not the same as actually doing it.
You are confusing type and encoding here. They are quite different. It
makes sense to talk about the type of the body (data), since its an inherent
characteristic of the data itself. It also makes sense to talk about the type
of a body part, which refers to the content type labelling.
I don't mind if in a conversation, one speaks about the type of a
body part, knowing that it is by extension.
Encodings are quite different, however, since they are associated with the
representation of the body rather than the body itself. As such, talking about
the encoding of the body or data confuses matters, since it is not an inherent
quality the body or data possesses. It does make sense, however to talk about
the encoding of a body part, since a body part includes the content labelling
where the encoding is specified.
On the contrary, I do believe that the confusion is on your side. It is said
in the documents, sometimes with much emphasis, that transfer encodings
always apply to bodies, and that headers are never transfer encoded. So
speaking about the encoding of a body part (which by any definition includes
headers and body) actually confuses matters, while speaking about the encoding
of the body or data faithfully describes what is actually done and thus is
a good way to avoid that confusion.
When we want
talk about body parts that are specifically within a multipart structure we
make the distinction right there in the prose. For example:
Note that the MIME-Version header field is required at the top level of a
message. It is not required for each body part of a multipart entity. It is
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
required for the embedded headers of a body of type "message" if and only if
the embedded message is itself claimed to be MIME-conformant.
This is a unique occurence in RFC 1521, and it is just a case of added
emphasis like the one where one says separately for messages and body
parts to what body Content-transfer-encoding does apply. It does not
make a trend...
And I believe that I have proved that an extremely major error existed in the
earlier definition that has now been corrected. And you have yet to convince me
that there are any problems with the current definitions or approach.
Well, it seems that you now have a version that is already quite different
from what I have been able to look at, but nevertheless:
The purpose of the kind of documents we are producing is not to follow
informal conversation practice, but to defines things in the most rigorous
way possible (I know you know this - it is just an introductory sentence,
right ?).
In the case of MIME, we are defining a complex, recursive data structure to
be interpreted by programs. If you look at RFC1521 (which is not perfect and
surely needed some clarification, etc), you will see that:
- the definition are all one simple sentence (sometimes clarification is
added in a second sentence, but that second sentence is not part of the
definition). None of them contents any word like 'but', 'except', 'only',
'if', etc.
- from the definitions and the rest of the document, it is possible to
construct a recursive parser (and yes I know that it would have to be
modified to account for error recovery, etc).
- the bnf matches the prose.
If the next version contains definitions that are longer, and/or contain
some words of the 'but' 'except' etc. variety, it will be IMNSHO a sign
of decreased quality. The fact that it better matches informal conversation
usage not withstanding.
One thing I will also be interested to see is the BNF it will contain. In
RFC1521, the contruct 'body-part' only appears in the context of multipart
bodies. To stay in sync with the new usage, the same contruct will now have
to appear at other places too. And in this respect:
Not so for the new body part: being the union
of a body and some headers that can be in the middle of some others, it is
rather a 'logical' object. This logical object appears in a 'pure'
form when it sits in a foobar, but not necessarily when it sits in a
message.
I don't see this as a difficulty. In the final analsysis all of these are
"logical entities". That doesn't mean they don't have properties and
characteristics and requirements that we have to talk about.
Don't play with the words: we all know that all those things are finally
magnetic domains on sheets of ferro-magnetic material, charges in small
capacitors or electrical levels on some wire, and that of course all the
structure we are putting on this is logical. Let's then try another word:
the new body part is a 'disjointed' object, whose pieces can be separated
by other stuff. I fail to see (but maybe I will be happily surprised) how
this can be represented by BNF that is not much more complicated.
IN CONCLUSION, MIME have been for year allowing one to say that a message
can contain one or several BODIES. The term 'body part' has been invented
to deal with the technicalities of multipart items, to be a good foundation
for BNF productions and software parsers. It may be that some people thought
that a 'body part' was what is actually a body, and started thinking and
saying that a message can contain one or more BODY PARTS. Coping with this
informal conversation practice by changing the definition does induce the
need to make numerous adjustments to the document(s), in a way that makes
it more complicated and more 'special cased' that it already was, which
IMO will lead to less chances to get correct implementations.
P.S.
I also
try very hard not to let the tone of the comment bother me, since a fair number
of them come in saying stuff like, "If you don't fix this for me I won't ever
use MIME again."
I hope my messages are not felt to be in that style. I have never made that
threat. Of course I am thinking of a few others I don't speak about, but
that's another story 8-).
/AF