http://www.oasis-open.org/committees/process.php#approval_standard
John Larmouth wrote:
> What is this April 15 deadline?
>
> John L
>
>
> Phillip H. Griffin wrote:
>
>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>>
>
>
