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

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

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