[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] Delay suggested
Phil, In the presence of concerns expressed by members of the committee about the quality of the current specification, I doubt it is a good idea to submit this specification to OASIS for standardization. The deadline of April 15 can be easily moved to May 15, if this helps guaranteeing a minimum level of quality as is desirable from a standard. Alessandro-----Original Message----- From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com] Sent: Saturday, April 12, 2003 18:55 To: j.larmouth@salford.ac.uk Cc: Bancroft Scott; xcbf@lists.oasis-open.org Subject: Re: [xcbf] Groups - XCBF XML Common Biometric Format CS April 3 2003.zip uploaded (fwd) 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, providedthe typesinvolved 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 casetghe ENCODEDBY 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 pointfor you tonote 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 endof the day, Base64 (over Hex) reduces the bandwidth of themessage byonly a few percent in most cases. BASE64 encoding of octetstrings,open tupes, and character strings is a nice idea (both forbandwidthreduction and, in the case of character strings, to allowcharactersforbidden in XML - there the term "armoured" is appropriate), and indeed we *are* standardising it, ***but it would be sillyfor XCBF tobe 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'sposition)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 YESwithout commentfrom me. John L Bancroft Scott wrote:Phil, The crux of the problem that we are having lies around thefact thatXCBF 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 andCRLs, and thateven in these cases, the certificates and CRLs componentsare optional(and in practice never used), it would solve all ourproblems if XCBFused 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]