[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] An alternative proposal has been uploaded
If we are trading NO votes, you can have one from me.
I don't mind WHAT technical solution we end up with, but I *do* want
clear text, not just a judeged footnote or whatever.
If that means a further 30 days, so-be-it. Hopefully this Standard will
have a life of a lot more than 30 days, and I have no wish to be
associasted with rubbish text for which there is no excuse.
John L
Phillip H. Griffin wrote:
> Ed,
>
> I haven't had time to look at the revision document.
> But I too will vote 'no' if this issue is not addressed.
>
> Again, it was agreed on this list that the only revision
> necessary to move the document forward was a single
> trivial change - addressing Ed's comment by adding a
> footnote on the coming amendment.
>
> Anything more than this will likely require an additional
> 30-day public review and comment period, followed by
> edits, another ballot to send the resulting document to
> OASIS, and so on.
>
> Phil
>
>
> Ed Day wrote:
>
>>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 uploaded
>>
>>
>>
>>
>>>Tyky,
>>>
>>>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] An
>>>>
>>>>
>>alternative proposal has been uploaded
>>
>>
>>>> 05/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 last
>>>>>>
>>>>>>
>>proposal
>>
>>
>>>>>>from Phil, in this regard). It is applied ONLY to the octet strings
>>>>>
>>>>>
>>>>>
>>>>>>that 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 uploaded
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>You 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 to
>>>>>>
>>>>>>
>>a
>>
>>
>>>>>>CS ballot.
>>>>>>
>>>>>>(BOTH documents are complete specifications that I personally am happy
>>>>>>with, and would vote YES on either. I do, however, as will become
>>>>>>
>>>>>>
>>clear
>>
>>
>>>>>>below, prefer this second proposal, as it is much simpler and easier to
>>>>>>implement, loses virtually nothing, and does not require a revision
>>>>>>
>>>>>>
>>when
>>
>>
>>>>>>EXTENDED-XER is approved.)
>>>>>>
>>>>>>It hung in the balance on our last telecon whether to use BASE64 or
>>>>>>
>>>>>>
>>not,
>>
>>
>>>>>>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 assesment
>>>>>>
>>>>>>
>>follows.
>>
>>
>>>>>>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 of
>>>>>>
>>>>>>
>>an
>>
>>
>>>>>>octet string value is just as much "armoured" as a base64 encoding.
>>>>>>
>>>>>>
>>The
>>
>>
>>>>>>**only** difference is that the number of characters needed by base64
>>>>>>
>>>>>>
>>is
>>
>>
>>>>>>typically 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 an
>>>>>>
>>>>>>
>>XML
>>
>>
>>>>>>document, EVEN IF THEY ARE EXPRESSED USING THE XML-DEFINED ESCAPE
>>>>>>MECHANISMS. So if you want your character string (at the abstract
>>>>>>
>>>>>>
>>level)
>>
>>
>>>>>>to be able to carry all ISO 10646 | Unicode characters, you cannot do
>>>>>>
>>>>>>
>>it
>>
>>
>>>>>>using 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 contain
>>>>>>
>>>>>>
>>a
>>
>>
>>>>>>representation 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 last
>>>>>>
>>>>>>
>>proposal
>>
>>
>>>>>>from Phil, in this regard). It is applied ONLY to the octet strings
>>>>>
>>>>>
>>>>>
>>>>>>that 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 used
>>>>>>
>>>>>>
>>in
>>
>>
>>>>>>XCBF, 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 the
>>>>>>
>>>>>>
>>footnotes
>>
>>
>>>>>>1, 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,
>>>>>>
>>>>>>
>>which
>>
>>
>>>>>>makes 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 implementation
>>>>>>
>>>>>>
>>to
>>
>>
>>>>>>this actual spec: is a conforming implementation required to conform
>>>>>>
>>>>>>
>>to
>>
>>
>>>>>>BASIC-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-XER
>>>>>>
>>>>>>
>>encoding
>>
>>
>>>>>>(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. It
>>>>>>
>>>>>>
>>is
>>
>>
>>>>>>importent 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 DTDs
>>>>>>
>>>>>>
>>in
>>
>>
>>>>>>the 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 an
>>>>>>
>>>>>>
>>EXTENDED-XER
>>
>>
>>>>>>encoder (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 text
>>>>>>
>>>>>>
>>about
>>
>>
>>>>>>"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 the
>>>>>>
>>>>>>
>>current
>>
>>
>>>>>>text 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 say
>>>>>>
>>>>>>
>>it
>>
>>
>>>>>>really means EXTENDED-XER, or whether it is clarified to say it is this
>>>>>>"special" encoding with BASIC-XER. (Like the text I inherited, X9.84
>>>>>>
>>>>>>
>>is
>>
>>
>>>>>>utterly 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 judgments
>>>>>>
>>>>>>
>>to
>>
>>
>>>>>>be 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 visiting
>>>>>>
>>>>>>
>>>>>
>>>>>
>>http://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.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 visiting
>>>>
>>>>
>>>>
>>http://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.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 visiting
>>>
>>>
>>http://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
>>
>>
>>
>>
>
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]