Re: invalid syntax when teletexstring

[Erwann ABALEA <eabalea@gmail.com>]

2011/7/29 Howard Chu <hyc@symas.com>:
> Erwann ABALEA wrote:
[...]
>> I'm reading now libldap/t61.c. I just read the IETF draft, and the
>> numerous tables... What a mess. X.680 has a reference to T.61
>> recommendation, which was deleted some years ago, and I'm not clever
>> enough to make Google find a copy of the standard. It can't be bought
>> anymore from ITU, but it's still referenced by later standards. Nice.
>
> The 1988 edition is still downloadable.
> http://www.itu.int/rec/T-REC-T.61-198811-S/en

One click further... Sorry, I read "Superseded" for the 1988 edition,
and "Withdrawn" for the 1993 one, and didn't realize I could click on
the 1988 link to download this edition.

> It also references T.51:
> http://www.itu.int/rec/T-REC-T.51/en
>
> Unfortunately the 1993 edition of T.61 is gone.

Even more, it is displayed as "Never published."

>> Meanwhile, I still haven't found the Czech CSCA certificate, but I
>> know what to do with the remaining 1% uncertainty. The CN field is
>> encoded as T61String, to hold the "CSCA_CZ" value. That fits well
>> within the 7bits limit.
>
> 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 :)
1. PrintableString is inadequate (because of the underscore character).
2. It's not *my* certificate, it's the Czech Republic certificate used
to issue passports that will be verified by every other country. I
don't work for them, I'm french :) (OK, I don't know where you live
either)
3. And the "you're required to use the least-inclusive string type"
statement is wrong, there's no such requirement, nowhere, everybody's
free to use UTF8String even when PrintableString could be used (it's
even RECOMMENDED to do so). The good option would have been to use
UTF8String, for sure. But they already produced passports, and
changing the root certificate of this importance is not an easy task.

Instead, RFC4518 states that non-Unicode strings are to be translated
to Unicode, even TeletexString. The reader is warned that it is NOT
RECOMMENDED to use such encoding, and that no standard conversion
rules between them exists, but this conversion is *not* optional.

>> 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?

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?

-- 
Erwann.