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.
Frankly, I don't think anyone ever did this. I know I didn't. I thought I did,
but the fact remains that a huge inconsistency (you attempts to diminish it
notwithstanding, its still a huge problem) crept in that careful reading would
have caught. Ergo, there weren't enough careful readers.
People often read what they want to read rather than what's there. That's
what I did. I didn't notice the fact that the definition of body part was
inconsistent and incorrect. I read it and thought it covered all the cases,
when in fact it did not.
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.
This position makes no sense, since the definition can easily be shown, by
citing example after example after example from RFC1521, to be completely
inconsistent.
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.
I am NOT kidding. And once again I take serious offense at your tone. In point
of fact I reviewed EVERY SINGLE OCCURENCE of the word "body" throughout this
document. In each case I looked at what was being said and made sure the
correct terms were being used. I did this as a natural consequence of the
change in the definition. It would have been irresponsible to do anything else.
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.
I completely disagree. I find it much your confusing your way, and I am not
going to change the current prose in the fashion you suggest.
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...
It is not a unique occurence -- there are at least two more similar phrases.
And even if it was unique, so what? The fact of the matter is that we rarely
need to refer to the specific case of a body part within a multipart.
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 ?).
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.
So what?
- 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.
Actually it doesn't match at all. The new prose is a much better fit, but there
are still differences.
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.
I completely disagree. It is a sign of increased precision.
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.
I still disagree with all of this. The term body part describes something
consisting of a set of content headers and the associated body, regardless of
where it appears. I think that this is the only definition that makes any
sense at all.
In conclusion, I actually had some doubts going into this discussiom, but I
don't any more. The present definition will remain as-is. If you don't like
this you may of course bring it up with the IESG, but it is going to take
either a much more convincing argument or a specific IESG mandate at point
point for me to change anything.
Ned