- From: Keld J|rn Simonsen <keld@dkuug.dk>
- Date: Sun, 08 Aug 1993 23:08:24 +0200
- To: John C Klensin <KLENSIN@INFOODS.MIT.EDU>, luc@opus.spc.nl
- Cc: mohta@NECOM830.CC.TITECH.AC.JP, harald.t.alvestrand@delab.sintef.no, ietf-charsets@INNOSOFT.COM, luc@spc.nl
John C Klensin writes: > In this context, and for MIME, the labels that would have been > associated with 10646 DIS-1 or -- if one believes in Han unification -- > UNICODE or IS 10646 BMP pose no particular problems (although the more > paranoid among us might insist on a date as part of the label): These > provide Standard character code tables, whose content and required > graphics are known at time of publication and revised very infrequently > and usually compatibly. We already have an extensive list of character set names registered with IANA, and their mapping to 10646 and other character sets in many cases is documented in RFC 1345. > But "unrestricted 2022" or "IS 10646 including planes and groups not yet > defined" are much harder to label in a useful way since it is difficult, > if not impossible, to write a piece of code that can guarantee sensible > representations for all of the characters in all files with that > particular label. In particular, if such a program is written today, it > is unlikely that it will behave optimally (or even reasonably) with a > character set registered with ECMA next week or with 10646.x > standardized in 1995. Yep, that is a problem. We should design something that is extensible, or "forwards compatible" (cf backwards compatible..) Keld --Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)
Received on Sunday, 8 August 1993 14:47:26 UTC