[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)
OK. The 15th of ANY month. Why do we need to rush it? Why not get agreement and go for 15th May? John L Phillip H. Griffin wrote: > 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 >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >>> >> >> > > > > -- 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]