John,
The CS has been approved by the XCBF TC for submission to
OASIS for consideration as a standard. If I can get the paperwork
done to meet all OASIS requirements, I will try to send in our
submission before the deadline fo April 15.
Phil
John Larmouth wrote:
> Phil,
>
> I think we may be having unnecessary disagrements due to
> misunderstandings, which I would like to get resolved.
>
> I have no problems with mixing CXER and BASIC-XER, provided the types
> involved are either in an
> OCTET STRING (CONTAINING .... ENCODED BY .... )
> or in an open type, and the spec clearly states (in the open type
> case), the encoding to be used (in the OCTET STRING case tghe ENCODED
> BY gives it).
>
> But CXER is actually a subset of BASIC-XER (it is just one of the
> BASIC-XER encodings with all encoder's options removed, so if the
> whole thing is encoded in CXER, the encoder is a conforming
> implementation of the spec. *** That is an important point for you to
> note in terms of the number of implementations using the spec. ***
>
> The problem actually comes back (surprise, surprise!) to the Base64
> issue. If we can eliminate that confusion, all is done. At the end
> of the day, Base64 (over Hex) reduces the bandwidth of the message by
> only a few percent in most cases. BASE64 encoding of octet strings,
> open tupes, and character strings is a nice idea (both for bandwidth
> reduction and, in the case of character strings, to allow characters
> forbidden in XML - there the term "armoured" is appropriate), and
> indeed we *are* standardising it, ***but it would be silly for XCBF to
> be held up or founder just for that***.
>
> As you have said before, there can always be a second version.
> (Assuming we manage to get enough support to get the first version
> through!)
>
> Phil, I want this to go forward. But the actual "bits-on-the-line"
> must be very clear, and cannot use Base64 (because of Ed's position)
> unless we delay.
>
> I say again, if we can get a clear spec that uses (current) standard
> ASN.1 encoding rules, you will get a whole-hearted YES without comment
> from me.
>
> John L
>
> 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
>>
>>
>>
>
>
