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] Delay suggested


I respectfully disagree.

Despite the tone and volume of the concerns expressed on this
thread, the minor issues that have been raised are just that, minor,
editorial in nature, easily addressed as we begin the next version.

The current CS is an important work that is useful far beyond this
TC. The XCBF CS is being referenced in one US national security
standard. And it is being used in other OASIS work as well.

Further delay will not substantially improve the XCBF CS as
evidenced by the strength of the ballot results to approve sending
the work forward, and the nature of the comments made during
that ballot.

However this turns out, I will do as the TC has balloted and send
the work forward as soon as I can meet all OASIS requirements.

I will then try to turn the TCs attention to the next version of the work.
Hopefully, all of your current concerns will be addressed in this effort.

But I look forward most to adding new material and to solving more
difficult problems in the months ahead. I hope that you will continue
to contribute to that effort.


Alessandro Triglia wrote:

In the presence of concerns expressed by members of the committee about
the quality of the current specification, I doubt it is a good idea to
submit this specification to OASIS for standardization.

The deadline of April 15 can be easily moved to May 15, if this helps
guaranteeing a minimum level of quality as is desirable from a standard.


-----Original Message-----
From: Phillip H. Griffin [mailto:phil.griffin@asn-1.com] 
Sent: Saturday, April 12, 2003 18:55
To: j.larmouth@salford.ac.uk
Cc: Bancroft Scott; xcbf@lists.oasis-open.org
Subject: Re: [xcbf] Groups - XCBF XML Common Biometric Format 
CS April 3 2003.zip uploaded (fwd)


The CS has been approved by the XCBF TC for submission to
OASIS for consideration as a standard. If I can get the 
paperwork done to meet all OASIS requirements, I will try to 
send in our submission before the deadline fo April 15.


John Larmouth wrote:


I think we may be having unnecessary disagrements due to
misunderstandings, which I would like to get resolved.

I have no problems with mixing CXER and BASIC-XER, provided 
the types
involved are either in an
or in an open type, and the spec clearly states (in the open type 
case), the encoding to be used (in the OCTET STRING case 
BY gives it).

But CXER is actually a subset of BASIC-XER (it is just one of the
BASIC-XER encodings with all encoder's options removed, so if the 
whole thing is encoded in CXER, the encoder is a conforming 
implementation of the spec.  *** That is an important point 
for you to 
note in terms of the number of implementations using the spec. ***

The problem actually comes back (surprise, surprise!) to the Base64
issue.  If we can eliminate that confusion, all is done.  
At the end 
of the day, Base64 (over Hex) reduces the bandwidth of the 
message by 
only a few percent in most cases.  BASE64 encoding of octet 
open tupes, and character strings is a nice idea (both for 
reduction and, in the case of character strings, to allow 
forbidden in XML - there the term "armoured" is appropriate), and 
indeed we *are* standardising it, ***but it would be silly 
for XCBF to 
be held up or founder just for that***.

As you have said before, there can always be a second version.
(Assuming we manage to get enough support to get the first version 

Phil, I want this to go forward.  But the actual "bits-on-the-line"
must be very clear, and cannot use Base64 (because of Ed's 
unless we delay.

I say again, if we can get a clear spec that uses (current) standard
ASN.1 encoding rules, you will get a whole-hearted YES 
without comment 
from me.

John L

Bancroft Scott wrote:


The crux of the problem that we are having lies around the 
fact that
is using Base64 as an encoding, but Base64 is not available in the 
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 
straight XER and/or CXER encoding.

In other words, I propose that we drop the use of (currently
in XER/CXER) Base64 in XCBF and instead stick to HEX encoding as 
by XER/CXER.  This would resolve the concerns that everyone, 
including Ed
Day, has voiced.




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