[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xcbf] An alternative proposal has been uploaded
Removal of the reference to the Ammendment to a footnote was agreed in
the telecon, and is no problem. That will be done in the next rev.
I think the footnote 2 should have been footnote 3. I had problems
referencing the same footnote from multiple places (sorry, we do not use
footnotes much in ASN.1, and as a (bad!) editor, I did not quite know
enough to manipulate them well). (I still don't know how to search for
them!
The next version should hopefully be OK.
I have been in Geneva on SG17 business for the last two days, and just
got back, but will try to get a new rev out in the next couple of days.
John L
Ed Day wrote:
>>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
>>
>>
>
>
>
> 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]