[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] An alternative proposal has been uploaded
I have looked over the current revision of the document and see that the original reason I voted 'no' has not been addressed. That is the presence of the Reference to X.693 Amendment 1. There is no link to it and it is not available to the public in either paid or free form. Therefore, I continue to insist that this be removed as well as all references to 'EXTENDED-XER' which, like 'VXER', is subject to change. Regards, Ed Day ----- Original Message ----- From: "John Larmouth" <j.larmouth@salford.ac.uk> To: "Tyky Aichelen" <tyky@us.ibm.com> Cc: "xcbf" <xcbf@lists.oasis-open.org> Sent: Wednesday, May 21, 2003 9:55 AM Subject: Re: [xcbf] An alternative proposal has been uploadedTyky, I will be at the ITU-T buiding in Geneva 6pm Geneva time (which I *think* - hope - is the right time), and they have a high bandwidth Internet connection. So it is my intention to come in using Net2Phone, provided they do not have a fire-wall that stops me, but even Net2Phone is not totally free, so I may want to drop out and let others resolve the final decision. If I get blocked by a fire-wall, I will have to come in extremely briefly by ordinary phone, or do an MSN Messenger Chat with Bancroft or Paul Thorpe relaying between me and the telecon. (I hope that won't be necessary.) But as I said in my mail, I will go with any of the options if we can only get consensus, so you don't really need me. It people have specific questions or comments on my analysis (such as Ed's mailing that them to the list before Thursday evening UK time, just in case I cannot get through to the telecon. If you want to do a paragraph by paragraph pass over the document, then I strongly recommend using NetMeeting for that. This would cost us two weeks delay, but equally would give us two weeks for everyone to establish that they could use NetMeeting. Thanks. John L PS I did not see on your agenda discussion on the use of NetMeeting, which I requested. Tyky Aichelen wrote:Hi Team, Re the subject: I would like for us all to jointly reach the decision on this Friday telecon ( I had included it in the agenda), that way we all know how broadly is the OK. John: Count on you to call-in. Thanks for your hard work and all the analysis you sent in. Best regards, Tyky Aichelen John Larmouth <j.larmouth@salfo To: Ed Day<eday@obj-sys.com>rd.ac.uk> cc: xcbf<xcbf@lists.oasis-open.org>Subject: Re: [xcbf] Analternative proposal has been uploaded05/20/2003 12:44 PM Please respond to j.larmouth OK. That is a good reason for staying with BASE64. And Phil quietly flipped a bit when I proposed we dropped it, so I guess the "alternative proposal" is dead. Back to the first proposed revision. Is that broadly OK? John L Ed Day wrote:Is the reduction worth having? Here we have to examine where and when BASE64 is applied in the first proposal (which mirrors the lastproposal>from Phil, in this regard). It is applied ONLY to the octet stringsthat contain X.509 certificates and X.509 certificate revocation lists, and ONLY if the outer-level encoding is BASIC-XER, not if BER is used. So it will produce a 30% reduction in a couple of octet strings that will form a very small part of the total (verbose) XML document. The gains are actually miniscule.Based on my experience with security specs, I know of instances where certificate revocation lists can be *very* large. So I think a 30% reduction is a big deal. Regards, Ed ----- Original Message ----- From: "John Larmouth" <j.larmouth@salford.ac.uk> To: <j.larmouth@salford.ac.uk> Cc: <xcbf@lists.oasis-open.org> Sent: Tuesday, May 20, 2003 8:59 AM Subject: [xcbf] An alternative proposal has been uploadedYou will shortly get (or have already got) official notification from the OASIS Web software that I have uploaded another document. This is an alternative proposal, based on NOT using BASE64. I want to discuss here some points related to the use or non-use of BASE64, in order to allow an informed decision on which to progress toaCS ballot. (BOTH documents are complete specifications that I personally am happy with, and would vote YES on either. I do, however, as will becomeclearbelow, prefer this second proposal, as it is much simpler and easier to implement, loses virtually nothing, and does not require a revisionwhenEXTENDED-XER is approved.) It hung in the balance on our last telecon whether to use BASE64 ornot,with most people saying they did not really care, with the decision to use it swinging almost entirely on the remarks from Bancroft and myself that Phil, who left the meeting early, would be strongly pushing for BASE64. That may well still be true. But a technical assesmentfollows.First, let us dispose of the "BASE64 armoured" concept. You will see that I deleted that term from the text in both proposals. It is meaningless when applied to an octet string value. A hex encoding ofanoctet string value is just as much "armoured" as a base64 encoding.The**only** difference is that the number of characters needed by base64istypically reduced by 30% from the hex character count. I repeat, this is the ONLY difference for an octet string. The term "base64 armoured" CAN be legitimately applied to a character string. This is actually its main value in EXTENDED-XER. The point here is that the rules of XML FORBID some characters in anXMLdocument, EVEN IF THEY ARE EXPRESSED USING THE XML-DEFINED ESCAPE MECHANISMS. So if you want your character string (at the abstractlevel)to be able to carry all ISO 10646 | Unicode characters, you cannot doitusing either the UTF8 encoding of the character nor using the XML-defined escape sequences without violating XML rules. Applying BASE64 to the UTF8-encoding of the character string value and then UTF8-encoding the BASE64 characters allows that XML element to containarepresentation of ANY character string, without violating XML rules. This is truly "base64 armouring". Typically, the size of the encoding will be INCREASED by 30%. But to repeat myself, when applied to an OCTET STRING, base64 does nothing that hex does not do other than reducing the verbosiuty by 30%. Is the reduction worth having? Here we have to examine where and when BASE64 is applied in the first proposal (which mirrors the lastproposal>from Phil, in this regard). It is applied ONLY to the octet stringsthat contain X.509 certificates and X.509 certificate revocation lists, and ONLY if the outer-level encoding is BASIC-XER, not if BER is used. So it will produce a 30% reduction in a couple of octet strings that will form a very small part of the total (verbose) XML document. The gains are actually miniscule. (There is the small(?) point that XCBF and ANSI X9.84 - currently out for public comment - are aligned in this area. If BASE64 is NOT usedinXCBF, it would be good to get comment to have it removed in X9.84 as well, so that the two stay aligned.) Now, OK. But why not avoid problems with non-compatibility with X9.84 and stay with BASE64 for these two octet strings? What are the disadvantages? They certainly exist. We have tried to say that the use of BASE64 is "in anticipation" of the X.693 ammendment 1 that defines EXTENDED-XER. I think the text I have given you is about as good as can be got in this area (see thefootnotes1, 2, and 3 in the first proposed revision and the text in 7.4.2 - use the "View Print Layout" to see the footnotes). This "anticipation" is in itself a bit unsatisfactory, but the problems are more serious. I want to draw attention to footnote 3, and to expand on it. Here is a copy of that footnote: This is in anticipation of the acceptance of Amendment 1 to X.693,whichmakes provision for the use of BASE64 encodings. Formal use of this amendment will require the outer level encoding to be changed to EXTENDED-XER (see 7.4.3) and the addition of XER encoding instructions. This will also imply that a decoder will be required to accept the presence of XML DTDs, Processing Instructions, Comment, and accept and ignore attributes such as xsi:type and xsi:SchemaLocation. <<<<<<< This footnote raises ambiguity on what is a conforming implementationtothis actual spec: is a conforming implementation required to conformtoBASIC-XER until the Amendment is approved, and then to EXTENDED-XER? I think I have written the text in such a way that EXTENDED-XER is NEVER used unless or until we produce a new version of the spec referring to EXTENDED-XER rather than to BASIC-XER. Remember, the only reason for wanting to do that is this minimal use of BASE64 in the current spec, and alignment with X9.84 (which in my view has also probably got it wrong!) But X9.84 will not get finally approved until after the Amendment is in place, and the overheads of a full EXTENDED-XERencoding(see below) are likely to be more acceptable there than in an OASIS standard????? What are the overheads of saying that the outer-level is EXTENDED-XER and not BASIC-XER? The above copy of the footnote summarises it. Itisimportent here to realise that the primary raison d'etre for EXTENDED-XER was to provide support for the mapping from XSD, and the use of ASN.1 in conjunction with general XML/XSD tools. A BASIC-XER encoding (in the absence of EXTENDED-XER encoding instructions) *is* a valid EXTENDED-XER encoding, so for encoders there is no problem. The problem is for conforming decoders. They are REQUIRED to accept DTDsinthe XML document (for example that define character entities to reduce the verbosity of some XML documents), and they are REQUIRED to accept and ignore random xsi:type and xsi:SchemaLocation attributes, and they are REQUIRED to accept XML Proceeing Instructions and Comment wherever XML permits these to occur (more-or-less everywhere). All this adds to the implementation cost of an EXTENDED-XER decoder. Note that there is no option available in prospective ASN.1 standardisation to be able to include an encoding instruction to say "BASE64" **without** the requirement for a decoder to accept these additional options in the encoding. So the real issue is not so much which spec we decide to approve now, but rather where we intend to progress after that. We can: a) Use the alternative proposal (no use of BASE64), and be finished and simple, but not (currently) X9.84 compatible, and **very** marginally more verbose; or b) Use the first proposed revision and never move formally to EXTENDED-XER, accepting that we will be doing a "special" for our encodings, albeit a "special" that tool vendors that have imnplemented EXTENDED-XER can easily support, because all it means is anEXTENDED-XERencoder (to recognise the [XER:BASE64] syntax) and a decoder with lots of functionality that should never get used. (In this case, the first of my "proposed revision" documents could probably remove all textabout"anticipation" and EXTENDED-XER, and just openly admit it is a non-standard encoding that we are requiring). c) Use my first proposed revision, and then produce a new version that formally says that EXTENDED-XER is to be used. This is what thecurrenttext of the first proposed revision was targeting ("anticipating"), and we should not need to change that text for this option, but XCBF decoders would have a harder job in the long-term. The only disadvantage of a) is that it may not be X9.84 compatible, unless X9.84 is changed on public comment. Does that matter? Can X9.84 be changed to align with a)? There are NO technical disadvantages with a), as explained above. The only disadvantage of b) is a "special" encoding, but one that is probably fairly easy for tool vendors to support. This may or may not be X9.84 incompatible, depending on whether X9.84 is clarified to sayitreally means EXTENDED-XER, or whether it is clarified to say it is this "special" encoding with BASIC-XER. (Like the text I inherited, X9.84isutterly ambiguous in this regard at present.) The disadvantages with c) are: The potential confusion in the "anticipating" concept, and in a second OASIS spec that says EXTENDED-XER when the first said BASIC-XER; The extra complexity of requiring decoders to suppotr the full range of additional encodings (DTDs, comment, etc) of EXTENDED-XER in the long-term. I am sorry this has been such a long "essay". I believe what I have said is factually correct, but there are clearly subjective judgmentstobe applied. The bottom-line is that I will personally go for any of a) to c), we just need a decision. 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 You may leave a Technical Committee at any time by visitingp You may leave a Technical Committee at any time by visiting-- 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 You may leave a Technical Committee at any time by visitinghttp://www.oasis-open.org/apps/org/workgroup/xcbf/members/leave_workgroup.ph pYou may leave a Technical Committee at any time by visitinghttp://www.oasis-open.org/apps/org/workgroup/xcbf/members/leave_workgroup.ph p-- 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 You may leave a Technical Committee at any time by visitinghttp://www.oasis-open.org/apps/org/workgroup/xcbf/members/leave_workgroup.ph p You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/xcbf/members/leave_workgroup.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]