[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Comments received on ballot
Attached are the comments received on the ballot which just closed. These should be addressed, any corrections made to the document, and a new CS balloted and approved before we proceed. Or as an alternative, we could begin a new version two document and address these comments in that document. At any rate, I'll have no time to attend to these in the short run, but comments on these comments, how they should be resolved, when and how to move forward and in what time frame would be much appreciated. Phil
John Larmouth Comments There are a couple of editorial changes that need making, but these will be addressed as part of my response to the OSIS ballot. They are as follows: 1)The title of X.693 amendment 1 has changed, and needs correcting. 2)In a few places, the correct terms BASIC-XER and EXTENDED-XER need using instead of the old terms XER and VXER. 4)In order to align the ASN.1 with the main text, a two-line encoding control section needs to be added to the ASN.1. (It is possible that BASE64 was intended to be used for certificates and cris in SignedData, in which case a further line will be needed.) It is my understanding that it is not possible to change the document before submission for the main ballot, and these comments will therefore be made on the main ballot. If, however, it *is* still possible to make editorial changes to the document that is being approved for submission for OASIS ballot, then the above comments can be turned into specific change items. Phil Griffin Comments No ASN.1 encoding control statements are required to implement XCBF CS 1.0. These need only be added for the convenience of some ASN.1 tool vendors, but are not needed by the community using this specification at large. The certificates and CRLS components of type SignedData are represented as Base64 armored binary objects that happen to be encoded using the ASN.1 Distinguished Encoding Rules. The OCTET STRING type can be used to transfer these objects and to verify that the data is "ASN.1-valid" with respect to the XCBF ASN.1 Schema. This data, then represented as hexadecimal characters, can be subsequently transformed by a receiving application into Base64 characters. This process does not require any additions to the current XCBF ASN.1 schema. On encoding these binary objects, they can be encoded directly into the hexadecimal representation required by the OCTET STRING type specified in the XCBF ASN.1 Schema, then converted after schema validation into Base64 by the recipient. Alessandro Triglia Comments Comments on the XML Common Biometric Format Committee Specification, 25 March 2003 Line 28: The sentence "They conform to the canonical variant of the XML Encoding Rules (XER)" should become "They conform to the XML Encoding Rules (XER)". In addition, the document should specify exactly when CXER must be used and when BASIC-XER or EXTENDED-XER must be used. Line 73: The sentence "They conform to the canonical variant of the XML Encoding Rules (XER)" should become "They conform to the XML Encoding Rules (XER)". In addition, the document should specify exactly when CXER must be used and when BASIC-XER or EXTENDED-XER must be used. Lines 173-181 I propose deletion of this paragraph (although I proposed its insertion originally). It now looks confusing and not actually correct. Line 177: The phrase "basic XER (XER) or Variant XER (VXER)" should become "BASIC-XER or EXTENDED-XER". Line 180: The phrase "either XER or VXER" should become "either BASIC-XER or EXTENDED-XER" Line 1742: The title of X.693 Amd. 1 should be corrected. I am not sure about the year of publication. Line 1787: "x968-biometricTemplates" contains an invalid character in place of the first hyphen. Line 2230: An encoding control section should be added before the end of the ASN.1 module (module X9-84-CMS), as follows: --------------------------- ENCODING-CONTROL XER BASE64 certs, crls IN OriginatorInfo --------------------------- This would align the ASN.1 with the text (line 1541-2). Line 2230: It is unclear to me why the fields "certificates" and "crls" of "SignedData" aren't encoded in base-64 as well. If this was the intention, then the text should be corrected to mention this (somewhere around line 1043). Also, the encoding control section at the end of module X9-84-CMS should become: --------------------------- ENCODING-CONTROL XER BASE64 certs, crls IN OriginatorInfo BASE64 certificates, crls IN SignedData --------------------------- Lines 2753, 2754, 2796, 2798, 2800: Extra space characters in the encoding examples should be removed. Line 2803: <oid> 4 </oid> should become <id> 4 </id> Line 3007: <oid>4</oid> should become <id>4</id> Lines 1293, 1330, 1390, 1490, 1669, 3057: It is unclear why these lines contain a content type ID of 1.2.840.113549.1.7.1, while lines 1238-1244 seem to indicate that a content type ID of 1.2.840.113549.1.7.6 should be used. Line 2393: The OID values id-unknown-type and following should be included in the definition of the BiometricTypes information object set at line 2393. Paul Thorpe Comments I originally voted no with the following comment: The submission as an OASIS standard should be delayed until the the ISO ballot has started on the Amendment specifying the BASE64 encoding instruction which is referenced by the XCBF Committee Specification 1.0. I have changed my vote to Yes since I understand the OASIS ballot period will extend beyond the the May 10 expected start of the ISO ballot on the X.693 amendment which supports the BASE64 encoding instruction. This instruction needs to be added to the ASN.1 modules in the XCBF Committee Specification. Ed Day Comments Will not approve until VXER reference is removed or document is available.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]