[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] Comments received on ballot
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.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
--
Prof John Larmouth
Larmouth T&PDS Ltd
(Training and Protocol Development Services)
1 Blueberry Road
Bowdon j.larmouth@salford.ac.uk
Cheshire WA14 3LS Tel: +44 161 928 1605
England Fax: +44 161 928 8069
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]