[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: NetMeeting
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]