[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: ASN-1 - XCBF Liaison?
John Larmouth wrote: > 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. John, you and I worked hard on this together. But as you have pointed out before, we have yet to realize the fruits of our efforts. > > (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.) I just looked on the main page of the OASIS web site. After all of this time and repeated mention by me, they still do not have these liaisons listed on the page. Not interested? I doubt it. More likely just swamped for time and over whelmed by the growth of the organization. I fear that you are right and that there is no distribution established. > > 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. John, I did not mean that the actual materials needed to be posted. I understand the copyright issues and the need to protect those rights. And even more important, I understand that you'd NEVER want someone to read working drafts and believe that they were fixed in stone. That would be misleading and a disaster. What I had hoped for was a paragraph or two after each meeting. Maybe a paraphrasing of the minutes would help. Perhaps a spot of notation as example when relevant. > > > **** 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. Rather than the actual copyrighted output, how about a brief summary instead. If you are willing to serve as liaison, Bancroft is the chair of the Liaison SC and I am a member. We should be able to quickly get you approved if Monica agrees, and I'm pretty sure she would. That would help move us forward smoothly. > > (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. Please consider summaries instead. It will keep us informed and eliminate the standards bodies having coniptions or them having to do anything about copyrights or distribution. Anyone who wants more than that should attend the ASN.1 meetings. Phil > > (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 >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]