Subject: Re: ASN-1 - XCBF Liaison?
Phil, Three comments: First, I have total sympathy with providing the material to everyone on the XCBF list, as OASIS is already accepted as a class A liaison to both SC6 and to SG17, and the ammendment is clearly very relevant to the XCBF work. (I have not checked, but if Jooran - SC6 Secretariat - did what she said she would do, Karl has for some time been on the distribution list for all SC6 mailings to National Bodies, and receives all outputs from our official meetings. He should be in possession of all the London ASN.1 outputs, but may not have realised who to send them to in OASIS.) Second, I would be a bit unhappy about posting to the XCBF list itself, as the archives are publicly accessible. However, if you can give me a full list of all members of that list, I can post to them all individually, with the usual ISO and ITU-T "this is private material for use in developing the standard" notice on it. **** If any of them are not prepared to accept that privacy statement, then I guess they should e-mail me (privately or to this list, as they wish) saying "please do not include me in the distribution". **** Third, we are now very near the next ASN.1 meeting in Somerset (starting Tuesday after Easter), and I believe it would be sensible if I did NOT send people the London output (which has changed a lot in technical detailed details, and could be confusing), but instead mailed the output from the Somerset meeting. (Apart from editorial matters, this Somerset output will be the text going for ISO FPDAM ballot, and apart from mending actual errors detected during the FPDAM ballot, it will be the text to be approved by ITU-T and offered for ISO FDAM ballot. In other words, give or take mending errors, it will be the final text of the amendment.) I will mail both the Ammendment for EXTENDED-XER and the new standard for the mapping from XSD. I will not include the (immature) documents related to time types, nor the OID work, unless someone specifically asks for it. I await comments from yourself or from others on this list, but otherwise I will expect to get from you a list of members (or a URL where I can find their e-mail addresses), and will e-mail the Somerset outputs to all of them. I hope this will be a satisfactory resolution. (I guess we should have set something like this up sooner. The real problem is probably that the concept of the Class A liaison and the administrative things that would stem from that have probably not been fully understood on either side, and not fully followed-through. Both you and I assumed that getting the Class A liaison approved was all that neeeded to be done.) John L Phillip H. Griffin wrote: > John, > > I do not have a clue what you mean when you use the term > "EXTENDED-XER". I can find no mention of this term in > any of the ASN.1 standards that XCBF and X9.84 reference. > > You and your colleagues are apparently busy changing the ASN.1 > standards. But even though there are four XCBF TC members > doing this work, none of you has bothered to tell the rest of the > TC what these changes are and how they might affect XCBF. > > I believe that it was this failure of the ASN.1 insiders to disclose, > this appearance of secrecy or back room dealings, that may have > lead to Ed's no vote. I don't know. > > But I do know that the ASN.1 Standards editor agreed to Ed's > request at the XCBF face to face meeting in Baltimore to disclose > the VXER notation, and then did not. > > Maybe I erred as TC chair and should have insisted on a more > formal arrangement with your ASN.1 group. But I'd like now to > correct this situation. > > Would you or one of the others working on the ASN.1 standards > agree to be the XCBF TC liaison to your group? > > This would require that you stop keeping important information to > yourselves and start making reports, perhaps just a few notes to > the XCBF list, when you make changes to the ASN.1 standards > that impact the XCBF work. > > This would help the XCBF TC immensely and eliminate the recent > surprise terminology and notation that keep coming up in your negative > ballot comments. > > Phil > > > John Larmouth wrote: > >> Are you saying that X9.84 is referencing EXTENDED-XER? >> >> John L >> >> >> Phillip H. Griffin wrote: >> >>> This is not what we agreed in the CS. >>> >>> And this would not be compatible with X9.84. >>> >>> Phil >>> >>> >>> Bancroft Scott wrote: >>> >>>> Phil, >>>> >>>> The crux of the problem that we are having lies around the fact that >>>> XCBF >>>> is using Base64 as an encoding, but Base64 is not available in the >>>> current >>>> version of X.693. Given this, plus the fact that that only the >>>> EnvelopedData and SignedData types carry certificates and CRLs, and >>>> that >>>> even in these cases, the certificates and CRLs components are optional >>>> (and in practice never used), it would solve all our problems if >>>> XCBF used >>>> straight XER and/or CXER encoding. >>>> >>>> In other words, I propose that we drop the use of (currently >>>> non-standard >>>> in XER/CXER) Base64 in XCBF and instead stick to HEX encoding as >>>> required >>>> by XER/CXER. This would resolve the concerns that everyone, >>>> including Ed >>>> Day, has voiced. >>>> >>>> Bancroft >>>> >>>> >>>> >>>> >>> >>> >>> >>> >> >> > > > > -- 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 firstname.lastname@example.org Cheshire WA14 3LS (put "Hi John" in subject) England Tel: +44 161 928 1605 Fax: +44 161 928 8069