[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)
http://www.oasis-open.org/committees/process.php#approval_standard John Larmouth wrote: > What is this April 15 deadline? > > 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 >>>> >>>> >>>> >>> >>> >> >> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]