[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] NetMeeting
I nominate Paul Thorpe! I am sure he will be very happy to have people
contact him for help and/or a trial session.
John L
Tyky Aichelen wrote:
>
>
>
> John,
> I personally don't think a paragraph by paragraph pass over the document is
> necessary, but if anyone feels strongly about it, please speak up and I
> would be willing to do it.
> Just a pass over the specific paragraphs and the specific approaches that
> we still don't have the consensus, so we can reach the final decision quick
> and move on without delay.
> I add now Netmeeting as topic in the agenda as you requested (Sorry, I just
> forgot it!). Yes, we can explore the use of Netmeeting from now on in
> addition to the telecon for greater productivity. We need to enlist a
> NetMeeting expert to help set everyone up. Any volunteer?
>
> Best regards,
> Tyky Aichelen
>
>
>
>
> John Larmouth
> <j.larmouth@salfo To: Tyky Aichelen/San Jose/IBM@IBMUS
> rd.ac.uk> cc: xcbf <xcbf@lists.oasis-open.org>
> Subject: Re: [xcbf] An alternative proposal has been uploaded
> 05/21/2003 06:55
> AM
> Please respond to
> j.larmouth
>
>
>
>
>
>
> 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.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
>>
>>
>>
>>
>>You may leave a Technical Committee at any time by visiting
>>
>
> http://www.oasis-open.org/apps/org/workgroup/xcbf/members/leave_workgroup.php
>
>
>>
>>
>>
>>
>>
>>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
>
>
>
>
>
>
>
> 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]