I was running my ASN compiler last night, and I also discovered that we have
put UTF8String into ContentHints, so whatever solution/resolution we come to
should modify that structure as well.
jim
-----Original Message-----
From: dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil
[mailto:dpkemp(_at_)missi(_dot_)ncsc(_dot_)mil]
Sent: Monday, March 09, 1998 8:51 AM
To: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Checking abilities of ASN.1 compilers
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.)