[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] An alternative proposal has been uploaded
Hi Ed,
Thanks for speaking up.
To all: Please do like Ed did and send me your remaining unresolved issue
(i.e. why you vote 'no') if any. I form a list and we go through each of
them this Friday in the telecon.
Thanks.
Tyky
"Ed Day"
<eday@obj-sys.com To: "xcbf" <xcbf@lists.oasis-open.org>
> cc:
Subject: Re: [xcbf] An alternative proposal has been uploaded
05/21/2003 02:00
PM
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]