From: Peter Kirk (peterkirk@qaya.org)
Date: Thu Nov 13 2003 - 13:10:22 EST
On 13/11/2003 09:39, jon@hackcraft.net wrote:
>The source and the sink are higher level entities with their
>
>
>>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.
>
>
>
>
>
But 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.
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 peter@qaya.org (personal) peterkirk@qaya.org (work) http://www.qaya.org/
This archive was generated by hypermail 2.1.5 : Thu Nov 13 2003 - 14:10:53 EST