in other words, you have to specify the underlying model first,
and then how octets and character sets figure into that. To make this
concrete,
let me state MY model (i am unsure of what the old mail model was) for text
interchange was. The (simple) model is that the text i supply is drawn
left to right across the display with NL (0xA) causing the start of a new
line.
While I have much better model than yours and is still simple, I don't
think here is the proper place to discuss on it.
On some devices, X <backspace> Y would appear as Y, on others as X and Y
superimposed. printing characters from ASCII are assumed to be displayed
correctly; all others were pure luck.
As a general guideline for character sets, I'd like to display characters
even if I am unlucky.
(and not characters). 10646 defines what a text element is: essentially,
a (base) character followed by an infinite sequence of combining marks.
Though it has nothing to do with MIME, it is a good example of how absurd
10646 is.
The above model has a fatal defect in interactive environment. You can't
determine where symbols are separeted unless you read the next non-combining
mark. Thus, you can't display a symbol unless you look ahead an extra
character.
But, in interactive environment, the extra character is often unavailable.
The character might be delayed in network or the character is not yet typed.
It should be noted for Henry Spencer that the above BUG was also pointed
out repeatedly by many people during the development phase of DIS 10646-1.2.
Masataka Ohta