ietf-smime
[Top] [All Lists]

Re: Checking abilities of ASN.1 compilers

1998-03-09 09:54:13
From: Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org>
So now people have asked instead for:

ESSPrivacyMark ::= CHOICE {
    pString      PrintableString (SIZE (1..ub-privacy-mark-length)),
    utf8String   [0] IMPLICIT UTF8String
 }

without the UNIVERSAL 12 defintion. Before I do this, however, I want to
check: whose compilers will choke on this? I would imagine that some would,
because the thing after the IMPLICIT is undefined. If no one's compiler
chokes on this, I'd say we can go with it, but if some people's compilers
die, then we're gonna have to get creative.

On a related issue: why do people who support the second format want "[0]"?
This is unneeded since there's no chance the item will get confused with
the PrintableString.


The "[0] IMPLICIT" is the whole key to interoperability, because with
either "UTF8String" or "[0] EXPLICIT UTF8String" (the latter being silly,
as you note), the [UNIVERSAL 12] tag goes on the wire.  With the suggested
syntax, only the [CONTEXT 0] tag is sent, which is legal in all compilers.

I believe the suggestion was made for the syntax to be:

       utf8String  [0] IMPLICIT OCTET STRING  -- must contain a UTF8 string

If it is ever determined that 1997 compilers are widespread enough to
update the spec, then the definition could be changed to:

       utf8String  [0] IMPLICIT UTF8String

without any change to the bits on the wire.

(Someone has already noted that the first version is not an example of
the dreaded "octet string hole", because there is no explicit OCTET
STRING being used to encapsulate another data type.)

<Prev in Thread] Current Thread [Next in Thread>