[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] Comments received on ballot
Your voting NO is not being a stick in the mud. It is a thoughtfulHi all, Sorry to be a stick in the mud on this, but I do think it is important that potential implementors have full access to all referenced material in a standard. The fact that this new VXER standard has apparently changed under our feet (in the forms of new names, etc.) underscores the problem. Who is to say it won't change again before it is finalized?
To delay our work any longer while we wait for the ISO/IECI agree with Phil that the use of this standard is not really necessary here. The inclusion of a simple comment in the schema identifying the fields to be encoded in base64 should be sufficient for developers. As Phil correctly points out, most automated tools have configuration facilities to allow this sort of thing to be done without formal declarations.
Ed Day ----- Original Message ----- From: "Phillip H. Griffin" <phil.griffin@asn-1.com> To: "[OASIS XCBF]" <xcbf@lists.oasis-open.org> Sent: Wednesday, April 02, 2003 6:34 AM Subject: Re: [xcbf] Comments received on ballotJohn, Thank you for your comments. You overlook three key points in my ballot remarks. There are existing implementations of XCBF without this new encoding control notation. Such notation is not part of any public standard (hence Ed's comment). Removal of the VXER reference and a minor clarification of the Base64 processing could eliminate months of further delay needed to allow the ISO/IEC and ITU-T processes to begin - not end, which could require even more time. The corrections needed in the current CS, as pointed out in Alessandro's ballot remarks, would also be delayed. Starting a second version presents another way forward, and perhaps new opportunities. This need not be limited to only corrections. I would expect a second version would deal with new material as well. In any event, perfecting the current CS to make it as clean as possible has a lot of appeal. But doing this would not include adding any new "VXER" material that is still very much subject to change. We don't benefit by introducing additional flux. My preference is to eliminate the VXER reference. Phil John Larmouth wrote:To resolve Ed Day's comment, the ASN.1 ammendment 1 needs to be publicly available. That will occur in late September (of this year). Correcting the other comments can be done very quickly, but would be best done shortly after 10 May when ISO balloting starts, as the technical contents of the ammendment will then be stable. So if you want EVERYBODY on board, a time-scale of late September for final progression to an OASIS standard looks good. If you are prepared to go ahead without Ed, then progression in late May would be fine. I do not think it is sensible to have a version 1 then a version 2 within 6 months, with no changes other than the editorial problems identified. I have added comments to your remarks below on my comments. My last remark is probably the most important. Why are you not prepared to do this right? It is no big hassle. John L PS Alternatively, you abandon BASE64 and use only BASIC-XER and CXER, but I don't think you want to do that, and I do not recommend that. Phillip H. Griffin wrote: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 willthereforebe 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.If you do not include them, then the ASN.1 module is inconsistent with the English text and examples. That would be plain daft.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.Rubbish. The spec in the ASN.1 is for an encoding that does not allow BASE664. This is totally different from what is said in the body. It is nothing to do with tools - it is to do with a consistent spec.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.The issue is not what manipulations can be done, the issue is what is a conforming transfer between two different systems. It uses BASE64 or it does not. However, I do not understand your resistance to producing a fully consistent spec that is totally aligned with the final ASN.1 Standard. We are talking about a maximum of ten lines of editorial change in a formal part of the document.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]