OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xcbf message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ASN-1 - XCBF Liaison?


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]