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

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

Phil,

Whatever is possible formally, I do believe it would be best to resolve 
this issue and to submit a document that we all agree on.

John L

PS I was not aware of the agreement in Baltimore, or our failure to meet 
it.  (My fault - I probably failed to read the minutes carefully 
enough.)  If I had known we were not doing something that was agreed, I 
would have tried to help.

I would simply say that everyone in ASN.1 work has been up to their ears 
for the last twelve months trying to get the EXTENDED-XER ammendment and 
the XSD mapping standard out of the door, and the Editor has had an 
additional load with truly editorial and formatting issues that have 
been raised by ITU-T on the basic 2002 version (long since approved, but 
still only "pre-published").  This may not be an *excuse*, but it is the 
*reason* for any lack of attention to XCBF, none of us are in any way in 
opposition to it or attempting to delay it - quite the contrary.  I am 
sorry if we have not given it enough attention over the last six months 
or so.


Phillip H. Griffin wrote:
> John,
> 
> Ed voted no because in the Baltimore XCBF face to face
> meeting last December, the ASN.1 Standards editor agreed
> to provide the TC with an example of the notation needed to
> automate use of Base64 in the XCBF CS. He did not.
> 
> But that CS ballot passed and the document under ballot became
> the current XCBF CS that was approved in that ballot to be
> submitted to OASIS for consideration as an OASIS standard.
> 
> There were ballot comments requiring minor changes to the
> CS that I attempted to resolve. We just balloted to accept
> those proposed changes and that ballot failed.
>  
> That's where we are. The CS document that Ed voted against
> but which you voted to approve and send to OASIS for
> consideration as a standard is our current CS.
> 
> Phil
> 
> 
> 
> 
> John Larmouth wrote:
> 
>> Phil,
>>
>> I am not sure how you justify your first statement.
>>
>> There was certainly initial agreement to use Base64, on the grounds 
>> that it was being added in EXTENDED-XER. I agree with that.
>>
>> But Ed opposed that decision because EXTENDED-XER was not yet publicly 
>> available.  I have no problems with Ed's position.  But it means that 
>> that solution is not agreed.
>>
>> A subsequent proposed solution was a kind of fudging of the issue with 
>> a hex encoding of a Base64 encoding of the value, which I don't think 
>> was ever agreed.  Certainly if that fudge had been clear to me (and 
>> here we come to problems with lack of clarity in the document in this 
>> area, and perhaps lack of discussion of this technical issue) I would 
>> not have supported that proposal.  It is technically a nonsense, I 
>> believe, introducing overheads with no gain.
>>
>> Another solution was to delay progression in OASIS until Base64 became 
>> available in late summer, or to proceed once the ISO FCD ballot was 
>> started.  That also was not agreed.
>>
>> The third proposed solution was not to use Base64 at all.  That is my 
>> own preferred position, given Ed's opposition to using a standard that 
>> is not yet finalised.  But you seem not to accept that either.
>>
>> So ...
>>
>> ... whatever, I believe that your statement that "This is not what we 
>> agreed in the CS" is wrong.  In *this* area, I think there has been NO 
>> agreement (yet) in the CS - ***that is the problem***.
>>
>> It would be horrible to lose the ship for what is a ha'pth of tar.  Is 
>> the Base64 stuff THAT important?
>>
>> *** But if you want to continue to press for it, we must reach a 
>> consensus on its use and how to proceed. ****
>>
>> This is the only problem with what is otherwise an excellent Standard, 
>> it should not founder just for this.
>>
>> John L
>>
>>
>> Phillip H. Griffin wrote:
>>
>>> This is not what we agreed in the CS.
>>>
>>> And this would not be compatible with X9.84.
>>>
>>> Phil
>>>
>>>
>>> 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