Re: [xcbf] Groups - XCBF XML Common Biometric Format CS April 3 2003.zipuploaded (fwd)

[John Larmouth <j.larmouth@salford.ac.uk>]

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