Yet another message on this subject. I know the temptation is strong to hit
the 'Delete' key, but please don't. I am trying to bring a new view on
the subject..
I have been reading your last message again and again. Maybe this phrase
is the key:
This is absolutely wrong. The previous definition tied body part to multipart
structures only. This is not acceptable.
Which means that you (and perhaps some others) wanted to use the term
'body part' in the context of messages whose body is not of the multipart
type. Is that right ?
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.
It can be done, of course, but I would have proceeded in the following manner:
1- invent a new term, say 'foobar', to replace 'body part';
2- replace 'body part', in the definition and wherever it appears in the
document, by 'foobar'. Doing so ensures that none of the things that were
correct (and there were many, since the document was the result of several
years of work by many talented people) gets broken. It also frees the
term 'body part', since it does not appear in the document anymore.
3- write a definition for 'body part', to let it be whatever you feel is
necessary. I guess it would sit after the one for 'Body', since it
would need to reference it. It would also need to reference 'entity',
since a 'body part' can be found either in a 'message' or in a 'foobar',
and step 2 would have made 'entity' the union of 'message' and 'foobar'.
4- then introduce 'body part' in the places of the document where you feel it
is needed.
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. The definition
of body part already says what it has to say (modulo the clarification about
content headers). And to me your step 4 amounts to removing all uses of the
term "foobar" and replacing it with body part.
It may be that this last step will lead to the removal of all instances
of 'foobar'.
That is exactly what it does.
My these is that it will not, because 'foobar' did play an
essential role at some places in the document.
Sure it did, but at the time at least some of the people doing the work did NOT
assume that foobar only referred to parts of multipart structures. I know for a
fact that I made no such assumption when I used the term "body part", and in
the many reviews I've done I've yet to encounter a case where anyone else did
either. How else do you explain the specific qualification of body part when
the term is used to refer specifically to one in a multipart structure.
Let me put this another way. I think this definition of body part was slipped
in without adequate review of the consequences. The specification was broken as
a result, and has now been fixed.
Possible justification for that these:
According to the new definition, an entity can only have ONE body part.
False. An entity is defined to be a message or a body part. A message can
contain mutiple body parts.
Since the new body part includes the 'Content-' headers that are part of
the header of the entity (well, that's not in the definition I have seen,
but you stated it), and since those headers cannot meaningfully be
repeated in the header of the entity, it follows that an entity can only have
a single body part.
No it doesn't. You are again assuming that all messages are body parts. They
aren't, nor are all body parts messages. Messages can be multipart structures,
which are NOT body parts, but which contain multiple body parts.
It can of course have several foobars, which means that
foobar will be difficult to eliminate while speaking about entities
whose body is of the 'multipart' variety...
This case is only theoretical. It doesn't come up in practice. 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.
Some difficulties:
- if one looks at the foobars inside a multipart body, one will see that
they look like free body parts. Are they body parts ? No, for the reason
explained above, and also because...
I don't know what a "free body part" is. However, they are most definitely
body parts.
- all the objects defined before the introduction of the new 'body part'
are 'physical': one can tell, in a 'top-level' message, at which character
each object starts and ends. 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.
So, I maintain that it was a mistake to try to fix a perceived problem
by redefining an existing object (body part).
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.
Ned