Re: ASN-1 - XCBF Liaison?

[John Larmouth <j.larmouth@salford.ac.uk>]

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                               j.larmouth@salford.ac.uk
    Cheshire WA14 3LS                    (put "Hi John" in subject)
    England			
    Tel: +44 161 928 1605		Fax: +44 161 928 8069