[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] Comments received on ballot
John, Your personal attacks are inappropriate for this list and not constructive in helping the TC find a best way forward. Phil . John Larmouth wrote: > Phil, > > I cannot support this view, Any ballot based on it, I will have to > vote NO on. Do you really want to go down this confrontational route? > I guess you do. > > John L > > PS I never saw you as a Bush supporter for the Iraq invasion, but you > are very much taking the same attitude - I have the power, and I am > going ahead, no matter what the cost. Yuck. As I have said before, > there are far better ways than conflict to resolve disputes. > > > Phillip H. Griffin wrote: > >> >> >> Ed Day wrote: >> >>> Hi 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? >>> >>> >> Your voting NO is not being a stick in the mud. It is a thoughtful >> contribution to the XCBF work. In my opinion, all comments >> and votes help us to shape the work. >> >> This would have been harder for me to say until I saw the new >> substantial changes being suggested, both in the document text >> and to the schema. >> >> We were lead to believe back in December in Baltimore that we >> should put "VXER" into the XCBF document. Now, three months >> later, and after twice approving the XCBF document as a CS, we >> are suddenly informed that this term has been deprecated and that >> we must adopt new terminology that has not been balloted and >> approved. >> >> We could chase our tails forever with such changes. But doing so >> would further delay progress of our work and eliminate one of the >> primary benefits of developing new standards in OASIS - that we >> enjoy in OASIS an efficient, streamlined standards process. >> >>> I 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. >>> >>> >> To delay our work any longer while we wait for the ISO/IEC >> and ITU-T organizations to enter their convoluted and lengthy >> ballot process over notation that is not even needed would >> be a setback for XCBF. >> >> Phil >> >>> 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 ballot >>> >>> >>> >>> >>>> John, >>>> >>>> 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 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. >>>>>> >>>>> >>>>> 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]