Re: [xcbf] Comments received on ballot

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

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