Discussion document on XCBF spec

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

I have uploaded a copy of the XCBF spec with comments and 
recommendations embedded in it - but no new text yet.  I want reactions 
to the comments first.

I understand that you should be getting notification of that upload 
automatically, but it has not come back to *me* yet.

I was very tempted to have it reviewed by using a "VOTE", as there has 
been a recent OASIS "VOTE" that was simply a means of saying you would 
or would not attend the OASIS reception at XML Europe 2003!  (I voted YES!)

It is clear that this voting mechanism is good for much more than just 
real voting!  The ability for people to say "Yes, I agree with that, and 
here are my comments", rather than trees of e-mails, is clearly useful.

But unfortunately I do not have "Ballot Manager" privileges, and could 
not set up a ballot, so please comment on my comments (once you are 
notified of the upload) in the old-fashionned way - with an e-mail 
message.  (Once we have a new Chairman, I guess she/he will get the 
Ballot Manager privileges, and that problem will be solved.)

Basically, I can see am easy way forward to the production of clear text 
that will be independent of the Amendment (basically including, as 
agreed earlier, text in anticipation of the amendemnt), but there is one 
issue outstanding:

Are we happy to say that the entire outer-level encoding is canonical 
(CXER), or do we want to allow non-canoncial (BASIC-XER) outer-level 
encodings, with only the content of the BiometricObjects (and 
CertificateSet and CertificateRevocationLists) being encoded canonically?

The latter is hard (impossible?) to do when Open Types, rather than 
OCTET STRING (CONTAINING .... ENCODED BY ....) are being used .for 
BiomtericObjects.  (I think this was probably for historical reasons - 
OCTET STRING CONTAINING is a fairly recent (but fully approved and 
standardised) addition to ASN.1.)

My recommendation in comments in the document is that we use CXER for 
everything, apart from the use of DER in some OCTET STRINGs,  with those 
octet strings being encoded (as an encoder's option) as either HEX or 
BASE64.

(There is no formal mechanism - even with Amendment 1 in place - to 
formally forbid a HEX encoding.  You can allow a BASE64 encoding as an 
encoder's option, but you cannot express formally that you require 
(only) that to be used instead of HEX.  Maybe that is a lack of 
functionality in the Encoding Control Instructions, but experience with 
X.692 shows that a comprehensive functionality to totally define 
encodings can get very complicated, and we tried to avoid that with XER. 
  So there is no mechanism in the Annex to forbid HEX - only to allow 
BASE64.)

John L

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