Re: [xcbf] Vendor Specific Formats

[Ed Day <eday@obj-sys.com>]

If the goal is to get those in the BioAPI group to "buy-in" to this new
standard, then I think the goal should not only be 100% backward
compatibility, but ease-of-use as well.  My initial impression of the BioAPI
document was that it was an easy-to-follow document and I had a relatively
good understanding of the structure of the data.  When I then went to the
ASN.1 document, I had a hard time relating what was in the BioAPI C
structures to the ASN.1 specification.

So it would seem to me like the suggestion to use record types like the
following makes the most sense:

> > >      BioAPI-BIR-BIOMETRIC-DATA-FORMAT ::= SEQUENCE {
> > >         formatOwner     INTEGER (0..65535),
> > >         formatID        INTEGER (0..65535)

It should be possible to create almost a one-to-one mapping of fields in the
BioAPI structure to fields in an ASN.1 type.  This could be done at the
beginning of the specification with all of the more complex stuff concerning
information objects and the like pushed down to where it would of be out of
the way of the casual reader.

The other advantage is ease-of-use.  Using an ASN.1 compiler, one could
create the BIOAPI structure format directly from the ASN.1 source, making it
possible to read a header directly into a variable of the generated header
structure.  With a few more lines of code, one could then create the XML
document corresponding to the BIR.

This is just my initial impression from looking through the information that
is out there and I'm not sure what other factors are in play here.  Is there
other data in X9.84 format that has to be integrated into this mix or are we
basically starting from scratch?


----- Original Message -----
From: "Bancroft Scott" <baos@oss.com>
To: "Phil Griffin" <phil.griffin@asn-1.com>
Cc: "xcbf" <xcbf@lists.oasis-open.org>
Sent: Friday, May 10, 2002 1:41 PM
Subject: Re: [xcbf] Vendor Specific Formats


> On Fri, 10 May 2002, Phil Griffin wrote:
>
> > > Given that the BIR defines format identifier as
> > > an unsigned 16-bit integer value, it seems very likely that every
company
> > > that uses the BIR will have the OID associated with their company
identify
> > > a BIRint16 type.  Given this, I question how good the above change is.
I
> >
> > I don't follow this at all. If you believe that every
> > company is tied to a 16-bit integer value then the best
> > solution would seem to be one that makes our schema as
> > tight as possible and minimizes bits on the line changes
> > to the X9.84 ASN.1. This would simply be to change all of
> > the information object to refer to BIRint16.
>
> Everyone that uses the BioAPI is going to use a 16-bit integer value,
> for it is mandated by the BioAPI.  This being the case, it follows that
> the information objects of all such companies would identify BIRint16.
> Given this, I think it would make more sense to define a single
> information object that everyone can use to identify BIRint16.
>
> > > would much prefer see a more general solution.
> > >
> > > One solution that comes to mind is to introduce a new field of type
> > > BIRint16 within "Format".  It could be either:
> > >
> > >     Format ::= SEQUENCE {
> > >        formatOwner  BIOMETRIC.&name({Owner}),
> > >        formatId     INTEGER (0..65535) OPTIONAL,
> > >        formatType
> > >           BIOMETRIC.&Type({Owner}{@formatOwner})  OPTIONAL
> > >     }
> > >
> > > or:
> > >
> > >     Format ::= SEQUENCE {
> > >        formatOwner  BIOMETRIC.&name({Owner}),
> > >        ident CHOICE {
> > >            formatId     INTEGER (0..65535),
> > >            formatType
> > >               BIOMETRIC.&Type({Owner}{@formatOwner})  OPTIONAL
> > >        }
> > >     }
> > >
> > > The benefit with the above is that it provides a solution that is
> > > easy to comprehend, for it directly relates the BIR's formatId
> > > to that in the X9.84 biometric record.  The drawback is that it
> > > requires a change to the existing X9.84 Format type.
> >
> > The second solution is not too bad. But the required
> > change to the Format type is a show stopper for me,
> > particularly if there's a reasonable work around.
> >
> > > Another alternative would be to create a record similar to the 00 id
> > > record, perhaps with a relative OID value of 65535, where the
associated
> > > type is INTEGER (0..65535).  The benefit of this is that it does not
> > > require a change to the X9.84 Format type.  The drawback is that the
> > > relationship with the BIR's format identifier will not be as easily
> > > identifiable.
> >
> > Agree. I very much like identifying the company names
> > and the registry by use of individual OIDs.
> >
> > > Yet another alternative is similar to the last one mentioned above,
but
> > > instead of INTEGER (0..65535), we would have a SEQUENCE that contains
> > > the plain and simple type:
> > >
> > >      BioAPI-BIR-BIOMETRIC-DATA-FORMAT ::= SEQUENCE {
> > >         formatOwner     INTEGER (0..65535),
> > >         formatID        INTEGER (0..65535)
> > >      }
> >
> > This would be better than the proposal just above, as
> > it would allow an application to preserve all of the BIR
> > information needed to do a BIR->BiometricObject->BIR
> > transform.
> >
> > > Here the relative OID value of 65535 would identify the type as
> > > BioAPI-BIR-BIOMETRIC-DATA-FORMAT.  The benefit of this is that it
> > > immediately makes clear what the mapping from the BIR to the X9.84
record
> > > format is, it does not require a change to the existing X9.84 Format
> > > type, and it uses a single relative OID value to identify the INTEGER
> > > type, as opposed to the solution which you propose which would result
> > > in each BioAPI vendor using their OID to identify type INTEGER.
> > >
> > > Hmmm ..., it might actually be best to put
> > > BioAPI-BIR-BIOMETRIC-DATA-FORMAT directly into type Format as an
optional
> > > field.  This recognizes that the X9.84 record has more bredth, while
at
> > > the same time making it easier for implementors to map from the BIR to
> > > X9.84.
> >
> > I see this again as a show stopper because of the impact
> > to type Format. And all of these suggestions I think makes
> > application processing more complex.
>
> What about the suggestion to create a 65535 relative OID for the above
> BioAPI-BIR-BIOMETRIC-DATA-FORMAT?  I believe that that makes application
> processing more straightforward.
>
> > > > it indicates to me that replacing the BIR bit map
> > > > in the BioAPI with the X9.84 BiometricObject would improve
> > > > that standard and simplify applying security to biometric
> > > > objects. These issues need to be thoroughly addressed
> > > > somewhere in the XCBF documentation.
> > >
> > > I agree with all the above.  However, I am quite certain that the
BioAPI
> > > Consortium will not entertain the thought of replacing the BIR record
at
> > > this time.  Their focus now is on stability of the BioAPI 1.1
standard.
> > > The only chance I see for them adopting the X9.84 BiometricObject is
if we
> > > made this 100% backward compatible with implementations that are
underway.
> >
> > I think that we are very early in the game to call a
> > halt to change. The recent history of development of the
> > BioAPI format indicates that there has been no backwards
> > compatibility demonstrated to date. The tendency of bit map
> > specifications is to fail to weather change, which is why
> > ASN.1 solutions are generally favored by standards groups
> > such as X9. And as both X9.84 and BioAPI move forward in
> > the standardization process into a more international arena,
> > I'd tend to bet on change rather than none.
>
> I agree to all of the above.  I am not suggesting that we stick with the
> BIR forever.  I am suggesting that we find a backward-compatible way of
> introducing the X9.84 BiometricObject, for we are sure to meet stiff
> resistance if we introduce interoperability problems.  Yes, BioAPI 1.0
> and 1.1 are incompatible, but that does not mean that the industry will
> tolerate a series of new BioAPI versions, each with no compatibility
> with the previous version.
>
> BTW, your point about ASN.1 allowing new versions of application standads
> to be introduced with full backward-compatibility is a very good point.
> This alone is good enough reason to want to have the BioAPI directly
> support BiometricObject.  Does anyone have any ideas as to how it might
> be possible to do this while preserving backward-compatibility?
>
> Bancroft
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>