Re: [xcbf] Groups - XCBF XML Common Biometric Format CS April 3 2003.zipuploaded (fwd)

[John Larmouth <j.larmouth@salford.ac.uk>]

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


-- 
PLEASE NOTE - As an anti-SPAM measure, e-mails will shortly
not be accepted by my machine from an unknown sender unless
the subject contains the phrase "Hi John".

If you pass my e-mail address to others (which I am very happy
for you to do) please tell them to include this phrase in the
subject line of their first mailing to me.  Thanks.

    Prof John Larmouth
    Larmouth T&PDS Ltd
    (Training and Protocol Development Services Ltd)
    1 Blueberry Road
    Bowdon                               j.larmouth@salford.ac.uk
    Cheshire WA14 3LS                    (put "Hi John" in subject)
    England			
    Tel: +44 161 928 1605		Fax: +44 161 928 8069