Let's be clear, however, that conveying the UTF-8 string as a security
category allows the result to be compatible regardless of whether UTF-8 is
used. There is already a perfectly good extension mechanism included in the
X.411 label. Can somebody spell out for me the reason for NOT using it to
address the UTF-8 requirement? The way I see it, the current solution is
creating a problem that does not need to be created.
Chris
______________________
Paul Hoffman / IMC wrote:
At 11:09 AM 3/26/98 -0500, Bonatti, Chris wrote:
I think that expanded character sets are generally useful, but you need to
recognize that you're not necessarily working from a blank slate. The label
in the previous ESS draft was aligned with the X.411 security label. This
label structure has gained a fair amount of acceptance, and is used in a
number of areas including X.500, and non-OSI systems. I was pleased to see
it appear in ESS. Changing the privacy-mark field makes the ESS label
incompatible with the existing X.411 security label structure. Using an
alternate encoding or character set for the existing field is certain to
impact existing implementations that provide and consume security labels.
If the MUA creating the privacy mark wants to be compliant with X.411, it
can: it chooses the pString value in ESSPrivacyMark. If it wants to have
their mark use characters outside the PrintableString charset (for
instance, if the mark needs to include a non-ASCII text character or if the
sender wants to include an Internet mail address in the privacy mark), it
uses the utf8String value. The current label is *not* incompatible with
X.411; one of the two choices is. It is quite easy to create
X.411-compatible privacy labels if what you want to say in the label
doesn't need any characters outside the PrintableString charset.
--Paul Hoffman, Director
--Internet Mail Consortium