Re: [xcbf] Delay suggested

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

Title:

Alessandro,

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.

Phil


Alessandro Triglia wrote:
> Phil,
>
> 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.
>
> Alessandro
>
>
>
> > -----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)
> >
> >
> > John,
> >
> > 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.
> >
> > Phil
> >
> >
> > John Larmouth wrote:
> >
> > > Phil,
> > >
> > > 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
> > >     OCTET STRING (CONTAINING ....  ENCODED BY .... )
> > > 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 
> > >     
> > tghe ENCODED 
> > > 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 
> > >     
> > strings, 
> > > open tupes, and character strings is a nice idea (both for 
> > >     
> > bandwidth 
> > > reduction and, in the case of character strings, to allow 
> > >     
> > characters 
> > > 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 
> > > through!)
> > >
> > > 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 
> > >     
> > position) 
> > > 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:
> > >
> > > > 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
> > > >
> > > >
> > > >
> > > >       
> > >     
> >