Comments received on ballot

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

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

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.