Subject: Objections to IPKI3CMP charset handling

From: [email-masked]
Date: Fri, 21 Nov 1997 11:35:51 +0100

Hello,
I see that the IPKI3CMP draft uses the following construct to send
around text intended for human consumption:

  PKIFreeText ::= CHOICE { 
      iA5String  [0] IA5String, 
      bMPString  [1] BMPString
  } -- note that the text included here would ideally be in the 
    -- preferred language of the recipient

BMPString is the UCS-2 encoding (16 bits per character) of the
16-bit subset of the ISO 10646 character set.

This decision has some problems:

1) It is not compatible with current thinking on charset policy, as
   specified in draft-alvestrand-charset-policy-02.txt, currently
   in Last Call for BCP.

2) The BMPString encoding of 10646 is a particularly bad choice,
   since ISO has stated intent of adding characters to 10646 outside
   the BMP range, which cannot be represented there.
   (BMPString is not the same thing as UTF-16, another ISO proposal)

3) The use of CHOICE for this important construct makes "shorthand
   implementation" handling only one branch of the CHOICE all too likely.

An alternative that I think would be better for all concerned would be
to redefine this construct like this:

   PKIString ::= OCTET STRING -- UTF-8 encoded text

(As far as I know, ASN.1 does not have an UNIVERSAL type for UTF-8;
use of UniversalString would require inserting the appropriate escape
sequence at the beginning of the string, not very attractive)

This can even be made backwards-compatible with the previous version
for all cases that conform to ASCII by a simple added tag:

    PKIString ::= [0] OCTET STRING

since all ASCII strings are, by design, valid UTF-8 strings.

The IETF charset policy also strongly recommends adding language
information where possible; I note that the document already has a
note about this, but no support for it.

I would suggest adding the following to the PKIHeader:

   languages [9] SEQUENCE OF IA5String -- RFC 1766 language tags

and a Note at the end of section 3.1.1:

  The language field may be used to indicate the languages used in
  occurences of PKIString within this message. Its first element
  indicates the desired language for replies.

The reason for having > 1 fields is so that you don't have to lie when
you send a message with "header.freeText" in Norwegian and
"PKIStatusInfo.statusString" in English; the reason for overloading the meaning
of the first component element is so that the normal case (I'm sending
text in Norwegian and want replies back in Norwegian) is as simple as possible.

There's a note in the charset policy document about default language;
you may want to think about whether you want to reference that, too.

NOTE: I regard the charset issue as a show-stopper that SHOULD be
fixed before progressing the document; the language tagging function
is more of a feature that I'd very much approve of.

I hope this problem can be solved promptly, and apologize for not
catching this at an earlier stage in your deliberations.

Regards,

                    Harald T. Alvestrand