Why do you say "ridiculous"?

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

Title: Message

Phil,

 

Your views about the precision required in a standard are quite interesting. 

 

What do my past comments have to do with the present content of the document?

 

Please stop using the OASIS XCBF mailing list as a theater for public attacks against members of the TC that you chair.

 

Alessando

 

 

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

Alessandro Triglia wrote:

-----Original Message-----
From: Bancroft Scott [mailto:baos@oss.com] 
Sent: Saturday, April 12, 2003 17:57
To: xcbf@lists.oasis-open.org
Subject: Re: [xcbf] Groups - XCBF XML Common Biometric Format 
CS April 3 2003.zip uploaded (fwd)


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, 
    

Also notice that the text mentions BASE-64 only in relation to
EnvelopedData (OriginatorInfo) and NOT in relation to SignedData,
although both EnvelopedData and SignedData may carry certificates.

Therefore the use of BASE-64, as specified by the current normative
text, only applies to the certificates included in EnvelopedData and not
to those included in SignedData, which are probably more common.  The
latter are encoded in hex.
  

You're really straining at a gnat Alessandro.

In both places in the CS, in SignedData and EnvelopedData,
the exact same certificate and crl ASN.1 types are used. The
Base64 processing requirement applies to the type, not the
location.

The detailed description appears only in one place, not both.
You first suggested that an editorial change be made to reuse
the EnvelopedData description. And I added clairifying text
to the SignedData clauses. But then you voted against amending
the CS.

Now you complain that the edit has not been made? Ridiculous.

Phil

Alessandro



  

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