OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xcbf] Comments received on ballot


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

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.


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


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.


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

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

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


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

Line 177:

The phrase  "basic XER (XER) or Variant XER (VXER)"  should become

Line 180:

The phrase  "either XER or VXER"  should become  "either BASIC-XER or

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:


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:


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

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]