This seems to imply that if a password is entered in a script like Armenian or Ethiopic then the characters will be replaced all by a single character 0×3F, making the protection feature useless. This is unacceptable

The conversion from input password to single byte string is ambiguous. Certainly the input password could contain characters from more than one script, say some Korean, some Chinese. Do we process via multiple DBCS code pages Or just one and then replace the unmapped characters with 0×3F If only one DBCS code page is used, how is that determined in this case

Canada requests that a statement be inserted within this text area which would explicitly clarify the restriction especially with the use of passwords.

pg. 1916 Part 4, Section 03.02.29

TE

Proposed Disposition of DIS 29500 Comment CA-0038 (Modified: 2008-01-04) Agreed; as detailed in CA-0037, we will replace the existing mechanism with a new version which does not inherit its limitations and deficiencies. Within the deprecated legacy mechanism, we agree that this comment correctly points out a limitation which should be noted (the mapping to a single code page results in characters being effectively lost by being converted to 0×3F). We also agree that the deprecated algorithm should still be completely defined to ensure that legacy files with this hash value are handled appropriately by all implementations of the specification; accordingly, the following changes will be made: The specification will be updated (see below) to explicitly note the effects of the legacy hashing algorithm when dealing with input strings which use characters from multiple scripts. Closely related to this, to resolve GB-0473, the legacy hashing algorithm will be updated to store the character set to which the string is converted, in order to improve its portability and improve interoperability with other document interchange standards. Part 4, §3.2.29, page 1,916, attribute revisionsPassword, between paragraphs 1 and 2: Attributes Description revisionsPasswor d (Revisions Password) Specifies the hash of the password required for unlocking revisions in this workbook. The hash is generated from an 8-bit wide character. 16-bit Unicode characters must be converted down to 8 bits before the hash is computed, using the following logic: [Note: This legacy conversion attempts to fit UTF-16 encoded characters into a single-byte character set. As such, if the input string uses characters from multiple character sets, many characters will be unmapped in the destination character set and take on the default value, 0×3F. For this reason, it is recommended that applications choose a character set which maps the maximum number of characters from the input string. end note]