OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[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)


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
>>>
>>>
>>>  
>>>
>>
>>
>>
>>
>
>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]