🚀 go-pugleaf

In article <1gnemoEINN3qo@uni-erlangen.de>, unrza3@cd4680fs.rrze.uni-erlangen.de (Markus Kuhn) writes:
> ...
> in the above pipeline. I heard roumors, that the Plan 9 UTF version will
> be added as UTF-2 to an ISO 10646 annex, can anyone confirm this? Perhaps

	firstly, 10646 is cast in concrete right now. there will
be no changes for at least a year or two or three.

	secondly, the UTF encoding is now formally called UTF-1.

	thirdly, the Plan 9 encoding is the same as the FSS-UTF
encoding being considered for adoption by X/Open as the
recommended encoding for 10646 text streams. (i believe it
has been approved by the technical committee and is wending
its way through some process inside X/Open.)

	fourthly, if as we expect X/Open adopts FSS-UTF, it will
be proposed as an addition to 10646 as an alternate UTF encoding
(presumably called UTF-2 -- we have heard of no other encodings).
This could be done relatively quickly and expeditiously if ISO
so desired; otherwise, it will wait until the next time someone tweaks
10646.

> we really should wait as suggested by Randall Atkinson for the final
> version of ISO 10646 before starting to include anything new (e.g.
> a 16-bit encoding) in MIME.

	this won't help. the character assignments are known; translation
tools exist (i have nearly got permission for public release of the
Plan 9 translation stuff); and the ISO-blessed encoding (UTF-1) is known.

> Of course. But USENET users will have difficulties in understanding this,
> as there isn't currently anything like a presentation layer (as defined in the
> OSI reference model) that performs the conversion between the local
> representation (e.g. I prefer Latin 1 files) and the encoding used on
> the network (e.g. any 8-bit encoding on news and 7-bit encoding on
> email). ...

	maybe some usenet users will have difficulties. i suspect most
won't. but in any case, they oughtn't have to know! mail has
always struct me as one of the easiest programs to control in this way
as typically all mail leaves and enters a system through a couple
of programs. and conceptually, those programs could easily and
transparently handle conversion to and from a transport format/encoding.

	right now, we have the transport model/encoding and conversion
stuff; all we lack are the conventions to get 8-bits thru cleanly
and to do the translations.

			andrew