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)


There is absolutely no other agenda.

But producing standards that are not consistent is not a good idea. I 
suspect that some of us (me included) did not take time to fully 
understand the OASIS progression processes, and tended to assume that 
problems could be sorted out at later stages.

But I am sure that NONE of us involved in ASN.1 are in any way at all 
trying to delay your standard.  We just want to ensure that there is no 
ambiguity (which will result in interworking problems) on the actual 
encoding to be used.

And as I have said before, most of this relates to the desire to use 
BASE64 in advance of its approval and specification in publicly 
available text.  In retrospect, that was probably a mistake.

But I do not think it is helpful to go over old history.  The issue now 
is how best to move forward.

John L


Phillip H. Griffin wrote:
> 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
>>>>>>
>>>>>>
>>>>>>  
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
> 
> 
> 
> 


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





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