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


John,

Look at the ASN.1 and notice the type BiometricObjects.
This is not "everything", but merely one part of  the schema,
which spans three ASN.1 modules.

We are requiring CXER for encodings of values of type
BiometricObjects when they must be cryptographically
enhanced.

The message components that use Base64 need never be
encoded using CXER, and they themselves contain signed
objects, and thus need never be cryptographically enhanced.

Only the sets of biometric objects MUST be CXER encoded,
and nothing else.

I like to use the term "armor" to try to distinguish this data
encoding process from ASN.1 encoding. And since the
purpose of Base64 is to make binary data "mail safe", the
result of  this process is often referred to as armoring the
binary data.

Phil


John Larmouth wrote:

> Phil,
>
> If everything is intended to be CXER, then a clear statement to that 
> effect suffices - I am absolutely *not* wanting that to be said in any 
> formal way.  But I still think there is confusion with examples that 
> are not in CXER, and the use of terms like "BASE64 armoured" also adds 
> confusion.
>
> But your first sentence in the mail below confuses me in terms of your 
> intent, and adds confusion to the spec itself.  What do you mean by 
> "We're using Base64 in a simple specification"?  What simple 
> specification?  Base64 is at the heart of this problem.  It WILL be 
> available in EXTENDED-XER which will be fully approved in late summer 
> by ITU-T, fingers crossed, but Ed was unwilling on the first vote to 
> reference the amendment for that until it was published, and this 
> started the problem.  Please, however, note there is no canonical 
> version of EXTENDED-XER, nor is one planned, so you can only use 
> BASE64 AND canonical encodings by mixed use of EXTENDED-XER and CXER, 
> something I do not really recommend if it can be avoided.
>
> But .....
>
> .... provided the next ballot document contains a clear and 
> unambiguous statement that the encoding of all parts of the ASN.1 is 
> CXER (assuming that is what is intended), then you will get my 
> whole-hearted YES vote without comments - I can live with any other 
> bits which might cause confusion.
>
> John L
>
>
> Phillip H. Griffin wrote:
>
>> John,
>>
>> We're using Base64 in a simple specification.
>>
>> We are requiring CXER for encodings of values of type
>> BiometricObjects when they must be cryptographically
>> enhanced.
>>
>> We are not using formal notations to specify when CXER
>> is required, because the specification requirements for all
>> CXER use is so simple.
>>
>> Phil
>>
>>
>>
>>
>> John Larmouth wrote:
>>
>>> Phil,
>>>
>>> I do NOT want this to be confrontational.
>>>
>>> Can we please have reasoned discussions on what will be a good 
>>> Standard?
>>>
>>> The issues seem to revolve around BASE64, with perhaps a sub-issue 
>>> of which parts use BASIC-XER and which use CXER, and the nature of 
>>> examples.
>>>
>>> We need a consistent document.  But that can only be achieved once 
>>> we all agree on what is to be expressed.
>>>
>>> Are we abanonding BASE64 or not?  Are we doing a contorted spec with 
>>> CONTAINED BY, or a simple spec?  Are we clearly using the formal 
>>> notations to specify which bits are CXER and which are BASIC-XER 
>>> (assuming that thre *are* any BASIC-XER - as opposed to CXER - 
>>> components).  And are the examples an tutorial text in-line with the 
>>> normnative text?
>>>
>>> These are the main issues to be resolved - not by ballot, but by 
>>> discussion.
>>>
>>> I am sure this is all solvable, but I would really prefer a solution 
>>> by *discussion* within the TC to acheive a consensus,  with futher 
>>> ballots only occuring after there is such a consensus.
>>>
>>> Repeasted balllots that fail are certainly allowed by the 
>>> procedures, but are not productive, and bring discredit on the work.
>>>
>>> John L
>>>
>>>
>>> Phillip H. Griffin wrote:
>>>
>>>> You may be correct! I'll check with Jamie on his interpretation of
>>>> the OASIS rules.
>>>>
>>>> Phil
>>>>
>>>>
>>>> Alessandro Triglia wrote:
>>>>
>>>>>  
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: phil.griffin@asn-1.com [mailto:phil.griffin@asn-1.com] 
>>>>>> Sent: Thursday, April 10, 2003 08:49
>>>>>> To: xcbf@lists.oasis-open.org
>>>>>> Subject: [xcbf] Groups - XCBF XML Common Biometric Format CS 
>>>>>> April 3 2003.zip uploaded
>>>>>>
>>>>>>
>>>>>> The document XCBF XML Common Biometric Format CS April 3 2003.zip 
>>>>>> has been submitted by Phil Griffin (phil.griffin@asn-1.com) to 
>>>>>> the XML Common Biometric Format TC document repository.
>>>>>>
>>>>>> Document Description:
>>>>>> XCBF Committee Specification 1.0 approved March 25, 2003 after 
>>>>>> agreed changes incorporated to address a thrity day public review 
>>>>>> period, plus minor changes resulting  from comments made in that 
>>>>>> ballot that were accepted by the XCBF TC in the ballot closing 
>>>>>> April 10, 2003.
>>>>>>   
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I understand that the present document has NOT been approved as a new
>>>>> Committee Specification, because the number of YES votes has been 
>>>>> less
>>>>> than 2/3 of the total membership of the TC.   Can you please clarify?
>>>>>
>>>>> Alessandro
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>>> Download Document:  
>>>>>> http://www.oasis-open.org/apps/org/workgroup/xcbf/download.php
>>>>>> /1501/XCBF%20XML%20Common%20Biometric%20Format%20CS%20April%20
>>>>>> 3%202003.zip
>>>>>>
>>>>>> View Document Details: 
>>>>>> http://www.oasis-open.org/apps/org/workgroup/xcbf/document.php
>>>>>>   
>>>>>
>>>>>
>>>>>
>>>>> ?document_id=1501
>>>>>
>>>>>
>>>>> PLEASE NOTE:  If the above links do not work for you, your email
>>>>> application may be breaking the link into two pieces.  You may be 
>>>>> able
>>>>> to copy and paste the entire link address into the address field 
>>>>> of your
>>>>> web browser.
>>>>>
>>>>> -OASIS Open Administration
>>>>>
>>>>>
>>>>>  
>>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>




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