On Mon, 2 Mar 1998, Russ Housley wrote:
I agree with Bancroft Scott that ESSPrivacyMark should be re-defined
+as follows:
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE
+(1..ub-privacy-mark-length)),
utf8String [0] IMPLICIT UTF8String (SIZE
+(1..ub-privacy-mark-length))
}
Note Bancroft's point as follows:
Another
benefit is that if someone is using a tool that does not support
UTF8String they can simply change it to "[0] OCTET STRING" and get
+the
same encoding.
I do not agree. I think we should use the UNIVERSAL tag. This will
align us with the correct implementation of UTF8 in the future,
+rather
than creating an octet hole to carry a UTF8.
An "octet hole" is use of an OCTET STRING type to carry data of some
other type, so [0] IMPLICIT UTF8String is not an octet hole for the
type of the value is clearly specified as UTF8String. The suggestion
below to define the utf8String component with an IMPLICIT tag is a
good idea, for it does not put an octet hole in the standard, while at
the same time gives implementors the freedom to use octet holes if
that is how they would like to support UTF8String.
At most there should be a comment:
-- UTF8String ::= [UNIVERSAL 12] IMPLICIT OCTET STRING
Doing so does not break the 1988 and 1997 standards which both forbid
the use of UNIVERSAL tags in type definitions in ASN.1 modules, it
makes it clear how this type is formally defined for those people who
don't know that the tag is UNIVERSAL 12, and it is convenient for
anyone whose tool does not support UTF8String to simply remove the
"--" if doing so helps their tool to properly handle UTF8String.
Christian
---
Christian Rinderknecht Alcatel Alsthom Corporate Research Center
Object Architectures Unit Tel : +33 (0) 1 69 63 17 60
Route de Nozay Fax : +33 (0) 1 69 63 17 69
91460 Marcoussis, France
mailto:Christian(_dot_)Rinderknecht(_at_)aar(_dot_)alcatel-alsthom(_dot_)fr