Delay suggested

["Alessandro Triglia" <sandro@oss.com>]

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