[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] An alternative proposal has been uploaded
> I would ask Ed to reconsider. All mention of it is in informative
> tutorial material, not in normative text.
I have reconsidered, and, based on the phone conference arguments, would
like to get this finalized. If the X.693 Amendment 1 could be removed from
the references and put in a footnote as an anticipated future standard, that
should do it. I am also trying to track down the footnote referenced in the
following paragraph:
If the outer level encoding is BASIC-XER (or EXTENDED-XER - see footnote 2)
the binary value of the octet strings ...
Where can I find that?
Regards,
Ed
----- Original Message -----
From: "John Larmouth" <j.larmouth@salford.ac.uk>
To: "Ed Day" <eday@obj-sys.com>
Cc: "xcbf" <xcbf@lists.oasis-open.org>
Sent: Friday, May 23, 2003 3:51 AM
Subject: Re: [xcbf] An alternative proposal has been uploaded
> The version wihtout BASE64 does not have any mention of the amendment or
> of EXTENDED-XER!
>
> The version **with** BASE64 does have it, but with footnote 1, which I
> thought would be acceptable. Its onlly other use of EXTENDED is in the
> body of the text in parens with a reference to footnote 2 which is
> intended to warn implementors that it might change later, and in the
> various footnotes saying that this is in anticipation of this
> standardisation.
>
> The normative text does not rely on it at all for any part of the
> specification. It is purely for information. I thought that was what
> we had agreed - an explanation that use of BASE64 was "in anticipation"
> of the expected standardisation.
>
> I would ask Ed to reconsider. All mention of it is in informative
> tutorial material, not in normative text.
>
> However, it would be possible to delete the reference to the amendment
> and all the footnotes (and the comments -- BASE64 --.
>
> That would be deleting most of the stuff that was deleted in the
> non-BASE64 version, except the normative para ahout BASE64 use and
> definition in 7.4.
>
> I think that if we go this route, we decide to stay with a "special" on
> BASIC-XER indefinitely. That is one of the options I gave in my
> analyis/discussion, but not one I have produced text for yet.
>
> John L
>
> 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.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
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]