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

["Phillip H. Griffin" <phil.griffin@asn-1.com>]

John.

What you say below may well be true. But the agreement in
Baltimore was not the only occurrence. Another member of
the ASN.1 group offered to provide XER examples of XCBF
messages, and did not. Another member offered to do editing
of the CS, and did not.

All of these actions served to stall and delay progression of the
XCBF work.

Now, after your agreeing to approve the first CS, and agreeing to
enter a thirty day public review period, and agreeing to approve
a second CS with changes from the public review, and agreeing
to send this work to OASIS for consideration as an OASIS
standard, you suddenly find more reasons for delay. And you
lash out at the work as being defective and bust.

But in the Details of the latest ballot comments I see even more
new ASN.1 terminology is being proposed, being sprung on the
TC just now - words that are not in any of the ASN.1 standards
that we reference, but which you cite as reason for further delay.

You insinuate in your remarks that if the TC does not adopt these
secret phrases, our work will not be of low quality.

You criticize the simple, stable solution that was repeatedly
approved. And you offer a more complex solution in a state of
flux that itself is not approved as part of any standard.

It's difficult for me to accept from your actions that the best interests
of the TC are being served here. The appearance is that some other
agenda still has priority over XCBF.

Phil




John Larmouth wrote:

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