The idea of using sequential body parts so you can have
different languages seems rather clumsy and high overhead.
I do appreciate the problem with mixed languages in
one piece of text. That there must be *some* way of
marking that a change in language has occured. Either
it would be some sort of special sequence of characters
to mark the transition (and there isn't a standard way
of doing this as yet) or an out of band marker. A body
part boundry is one such out of band marker.
The problem I have with using body part boundries for this
sort of marker is that.. hmm .. it's the wrong level of
abstraction. If you take a body part to be an "attachment"
in the classic sense of "business letters", then using body parts
to mark language transitions is "wrong".
It kinda depends on how you see (or intend to use) mixing of
languages within a piece of text. I frequently exchange e-mail
in which I am speaking mostly in english but occasionally use
words and names from any european language used in the last 1000
years, as well as occasional transcriptions using the phonetic
alphabet. In this case you'd cause me to put in a complete
body part boundry just for the one name, then another to get
back to the english text. And then there's no gaurantee that
a receiving UA will present this correctly ...
Unfortunately the only solution I can offer is that we create
a lower level method of making an out-of-band signal of
a shift in languages. Two possibilities come to mind, one
fairly rational and the other off the wall. The first
is to use tokens in the pseud-SGML (richtext) to mark
language changes. A piece of mixed-language text would
certainly fall under the label of "rich text", it certainly
is no longer plain-jane text ;-).
The second idea is "sub-body-parts". And, no, I don't want to
suggest adoption of this for the first release of MIME. At
any rate this may be able to capture a few of the ideas and
facilities floating about. What is meant by "sub-body-parts"
is a mechanism to have a multipart body part. This would capture
the "parallel" and (especially) "alternative" versions
of the existing "multipart", as well as this problem of
mixing languages in text.
I see a few ways of implementing this idea:
-- Have a body part of Content-Type: multipart/references. In
the body part you would have some way of referring to other
body parts and organizing them in some way. I lack the imagination
at the moment to come up with more specifics than this.
-- As Louis suggested, put the feature into richtext to suck
in other body parts.
-- Have a body part of Content-Type: multipart/concatenated.
The body parts up to the ending boundry for that bodypart
should be displayed "concatenated" on the display. (Whatever
that would mean...)
Is the intention currently that `multipart' only be used in
a message header? If so this would have to be relaxed
to allow it to appear anywhere.