The source and the sink are higher level entities with theirBut I am not offering alternatives. I am offering a single architecture. And you seem to be confusing applications with system and communication support for Unicode.
own higher level protocols.
Yes, and they would be examples of the first and second case I gave in my first mail on this thread.
The channel between source and sink, which
is the Unicode level and below, should be transparent to PUA characters, indeed to all characters apart from defined transformations. That surely is the point of the PUA. If the channel starts messing around with the characters sent through it, that is what is non-conformant.
Such applications would match the third case.
The fourth case can be used to build any of the others.
To cover your original cases, we need another layer. Look at it like this, in a monospace font:
--------- --------- | User | | User | --------- --------- | App | | App | --------- --------- | Unicode | | Unicode | ----------------------- | Communication channel | -----------------------
In this model, Unicode ... Unicode offers as defined a transparent channel for all characters including PUA (although normalisation etc is permitted), and if an implementation is not transparent it is non-conformant. The communicating applications built on top of Unicode are free to do what they want with PUA characters, including refusing to handle them at all; indeed they can refuse to handle any other character as there is no obligation to support any characters. But if they are to be useful applications for many users, they would be well advised to offer support for as many characters as possible.
-- Peter Kirk [EMAIL PROTECTED] (personal) [EMAIL PROTECTED] (work) http://www.qaya.org/
