It does not help your case to insult me. I read your original message quite
carefully. I read all such messages quite carefully.
Was it looking insulting ? Sorry about that. English is the fourth language
I learned in my life, and I am sure that if I had been allowed to write this
paragraph in french, I would have been able to express all the nuances of
thought that were needed. Since you were not the editor of the document at
the time I was actively participating, and since I had been silent for a long
time, I just wanted to make clear that I had not just discovered the document
one hour before whining on it. And I did not call you or anyone else names,
like I have seen on this (and some other) list, unless I really don't realize
the meaning of the (foreign to me) language I must use here.
The definition of 'body part' was introduced to have a term to designate
one part of a multipart body without confusion.
Disagree. A body part doesn't have to be part of a multipart. It can be either
a part of a multpart or it can be the content headers as well as the actual
contents of a message that contains a single part.
I was stating the original intent (was introduced) of the definition. Since
I wrote it, I don't see how you can disagree with my original intent... You
may of course state that the term has been redefined. Do I understand
correctly that, according the the new definition, a 'body part' can now
be SOME OF the headers of a message, plus its body ? That's not what is
actually written:
The term "body part", in this document, refers to either a
single part message or one of the parts in the body of a
multipart entity.
Unless I am erring completely, 'single part message' means the totality
of a message, full header and body, the only restriction being that the
type of the body must be one of the discrete type or 'message', but that
it cannot be 'multipart'.
No it can't! Once again you haven't read what the definition says! Read it
again! A single part message is not the same as a message in general!
The only qualifier I see is 'single part'. On the other hand, any part
of a multipart body (a body part) can itself have a body of type multipart.
Since there is no qualification attached to 'one of the parts',
the 'new' definition of body part now lumps together:
- messages (full header and body) whose body is not multipart, and
- parts of a multipart (header and body) whose body is or is not multipart.
That's exactly the problem. The "rules" for parts of a multipart also have
to apply to messages that only contain a single part. Under the old definition
they did not. For the third time, this is not acceptable.
And once again, what do the parts of a multipart body (that can themselves
have a body of type multipart, see below), and single part messages have in
common to justify the introduction of a term to designate both ???
The use of a media type of multipart in a body part within
another multipart entity is explicitly allowed.
Keith Moore writes:
KM>Like it or not, the term 'body part' is now widely used for both
KM>entire messages and components of a multipart (i.e. anything that can
KM>have a content-type header). So messages are a subset of body parts.
++++++++++++++++++++++++++++++++++++++
And you told me:
So what? You are generalizing about messages, whereas the definition clearly
talks about a very specific subcase of the more general case.
Is it not the same generalization ?
I've reconsidered twice now, and I still disagree with you on almost all of
this. I will clarify the definition to make it clear that only the content and
content headers are being referred to in the case of a single part message.
That's as far as I'm going to go.
Maybe there were places where the text could have been made better than it
was. I still believe that something as radical as a change of definition is
no the right way to go. My feeling is that you will have to fix lots of things
that were written in concordance with the original definitions, just to bring
back the document to the same level of consistency it had when it was
published as RFC1521.
/AF