[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] Groups - XCBF XML Common Biometric Format CS April 3 2003.zipuploaded (fwd)
I really think we should try to avoid deadlines on this one. It is far more important to achieve a real consensus in the group (and a clear standard). If we push it forward prematurely, with different interpretations of the Standard, we will end up with serious interworking problems, and a very BAD standard. I am sure none of us want that. It is perhaps a flaw in the OASIS procedures that they require only certification of three implementations, but not that they have actually successfully interworked. But despite that, it behoves *us* to make sure that successful interworking is highly likely to occur, based ONLY on the text of the standard. But ..... .... why this imminent dead-line? I was not aware of this date. John L Phillip H. Griffin wrote: > John, > > The CS has been approved by the XCBF TC for submission to > OASIS for consideration as a standard. If I can get the paperwork > done to meet all OASIS requirements, I will try to send in our > submission before the deadline fo April 15. > > Phil > > > John Larmouth wrote: > >> Phil, >> >> I think we may be having unnecessary disagrements due to >> misunderstandings, which I would like to get resolved. >> >> I have no problems with mixing CXER and BASIC-XER, provided the types >> involved are either in an >> OCTET STRING (CONTAINING .... ENCODED BY .... ) >> or in an open type, and the spec clearly states (in the open type >> case), the encoding to be used (in the OCTET STRING case tghe ENCODED >> BY gives it). >> >> But CXER is actually a subset of BASIC-XER (it is just one of the >> BASIC-XER encodings with all encoder's options removed, so if the >> whole thing is encoded in CXER, the encoder is a conforming >> implementation of the spec. *** That is an important point for you to >> note in terms of the number of implementations using the spec. *** >> >> The problem actually comes back (surprise, surprise!) to the Base64 >> issue. If we can eliminate that confusion, all is done. At the end >> of the day, Base64 (over Hex) reduces the bandwidth of the message by >> only a few percent in most cases. BASE64 encoding of octet strings, >> open tupes, and character strings is a nice idea (both for bandwidth >> reduction and, in the case of character strings, to allow characters >> forbidden in XML - there the term "armoured" is appropriate), and >> indeed we *are* standardising it, ***but it would be silly for XCBF to >> be held up or founder just for that***. >> >> As you have said before, there can always be a second version. >> (Assuming we manage to get enough support to get the first version >> through!) >> >> Phil, I want this to go forward. But the actual "bits-on-the-line" >> must be very clear, and cannot use Base64 (because of Ed's position) >> unless we delay. >> >> I say again, if we can get a clear spec that uses (current) standard >> ASN.1 encoding rules, you will get a whole-hearted YES without comment >> from me. >> >> John L >> >> Bancroft Scott wrote: >> >>> Phil, >>> >>> The crux of the problem that we are having lies around the fact that >>> XCBF >>> is using Base64 as an encoding, but Base64 is not available in the >>> current >>> version of X.693. Given this, plus the fact that that only the >>> EnvelopedData and SignedData types carry certificates and CRLs, and that >>> even in these cases, the certificates and CRLs components are optional >>> (and in practice never used), it would solve all our problems if XCBF >>> used >>> straight XER and/or CXER encoding. >>> >>> In other words, I propose that we drop the use of (currently >>> non-standard >>> in XER/CXER) Base64 in XCBF and instead stick to HEX encoding as >>> required >>> by XER/CXER. This would resolve the concerns that everyone, >>> including Ed >>> Day, has voiced. >>> >>> Bancroft >>> >>> >>> >> >> > > > > -- PLEASE NOTE - As an anti-SPAM measure, e-mails will shortly not be accepted by my machine from an unknown sender unless the subject contains the phrase "Hi John". If you pass my e-mail address to others (which I am very happy for you to do) please tell them to include this phrase in the subject line of their first mailing to me. Thanks. Prof John Larmouth Larmouth T&PDS Ltd (Training and Protocol Development Services Ltd) 1 Blueberry Road Bowdon j.larmouth@salford.ac.uk Cheshire WA14 3LS (put "Hi John" in subject) England Tel: +44 161 928 1605 Fax: +44 161 928 8069
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]