2. From the previous lengthy dicussions about "prefix" area, there were
some strong reasons that "prefix" and "postfix" areas should be
dropped.
They *were* dropped. Or am I misinterpreting your use of the terms?
Quoting from RFC-XXXX, it stated: "In general, these 'prefix' and
'postfix' areas of multipart messages should be regarded as comments, and
implementations are free to discard them. However, it is recommended that
composing agents use the prefix area to include a short textual message..."
I would like to see a stronger statement that implementations *should*
discard the "prefix" and "postfix" areas. Don't recommend the use of them.
I am afraid that if a sending UA puts an important (judgment call) message
in the prefix area, but the receiving UA discards it. In my opinion, these
2 UA's are *not* interoperable.
I had actually written a version of the RFC that included the
Content-Label proposal, but then I got rid of it when I realized that
one could easily use the established Message-ID field for this purpose.
Is there any advantage to defining a Content-label rather than using
Message-ID in the encapsulated parts?
Content-Label is set by the *sending* UA (e.g. the sender assigns a label
"Phone_Message" to an audio typed body part) and it is more user-friendlier
than Message-ID when used in a reply message. This field exists in each
body part, but it is optional. Message-ID is different from Content-Label
that Message-ID refers to the whole message and Content-Label refers to a
specific body part in a message.
-Vincent