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

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

Phil,

I would simply repeat my first paragraph below:  Whatever is possible 
formally, I do believe it would be best to resolve this issue and make 
sure we really have total consensus on what is to be submitted.  This 
need not take an inordinate amount of time. If it does, then clearly we 
do NOT have consensus!

I would suggest targetting May 15th rather than April 15th should give 
enough time to get everyone in agreement.

John L


Phillip H. Griffin wrote:
> John,
> 
> We voted to submit a document that only one member did
> not agree on. Ed voted no only because the VXER reference
> you and your colleagues insisted on was not removed.
> 
> 1. There was consensus agreement that the document was
>    of OASIS Committee Specification quality.
> 
> 2. There was a thirty day public review of the work that
>     resulted in minor changes.
> 
> 3. These changes were agreed by the TC and the current
>     XCBF CS was approved by the TC.
> .
> 4. The current CS document was approved by the TC for
>    submission to OASIS for consideration as a standard.
> 
>    You voted affirmative on this ballot.
> 
> 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
>>>>>>
>>>>>>
>>>>>>  
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 


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