Erwann ABALEA wrote:
2011/7/29 Howard Chuhyc@symas.com:
Then you should just be using PrintableString. You're required to use the least-inclusive string type, after all.
Howard, you're very good. But you too can make mistakes :)
- PrintableString is inadequate (because of the underscore character).
Ah, right.
If everything is internally converted to UTF8 and t61.c seems to provide a lossless T.61 to UTF8 conversion, why isn't it used?
Because it's incomplete. It only handles the original 333 character repertoire of T.61, it doesn't handle shift-in/shift-out to other character sets. I believe in the last version of T.61 there was support for Japanese (JIS), Chinese, and Greek. So quite a lot more logic and tables needs to be added, and it looks like a lot of work for something nobody should actually be using.
If the support for JIS, Chinese, and Greek characters were to be included in the 1993 edition, and this edition has never been published, couldn't it be possible to ignore them? X.680 (1997 edition) also references the 1988 edition of T.61, and if no newer edition is present, then it still must be used, right?
Actually Japanese and Chinese are already specified in the 1988 edition. Greek is mentioned there but is lacking a specification of which escape code to use. Probably it's defined elsewhere, like a later version of ISO 2022 or somesuch.
Is an incomplete (but documented) support for T61String really worse than no support for it at all? Even if literature tells that no perfect support can exist?
In the security arena, yes. E.g. if we accept a T61String that uses escape codes, we will not normalize it correctly to UTF-8. From there we would be giving "definitive" yes/no results to matches, based on invalid comparisons.