Re: [xcbf] Comments received on ballot

[John Larmouth <j.larmouth@salford.ac.uk>]

I would be opposed to producing a spec that is not aligned with an 
emerging Recommendation | International Standard unless there is a good 
reason to do otherwise.

John L


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
lr
> 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?
> 
> 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.
> 
> 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