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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-cap message

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

Subject: CAP SC agenda

Regarding agenda items for the CAP SC meeting today, here is the link to the previous CAP 1.2 errata redline.


The ASN.1 changes, if they were to stay in a single CAP 1.2 document are substantive and will break 1.1 implementations ( if there are any, have not heard of any so far).  Chet's previous advice was:

"... would qualify as "Substantive Changes" - defined in the TC Process as "a change to an OASIS Standard that would require a compliant application or implementation to be modified or rewritten in order to remain compliant" - then they cannot be handled through an Errata. "

Some background on the ASN.1 issue:

1. The XML signature element doesn't translate between XML and ASN.1 well and so there is a lack of support for signatures as defined in ASN.1.

2.  There was an error reported with the original 1.1 ASN.1 schema but I couldn't find the exact description on that in my notes this morning, will keep looking before the meeting.

3.  The ASN.1 encoding method previously chosen is a concern.  From a previous email "From my continued research on ASN.1 and Alessandro's recent replies, it appears as though there was no way to ensure forward/backward compatibility between 1.1 and 1.2.  There are methods in ASN.1 to do this, but the original method chosen was to align directly with the XML to allow for easier translation to/from ASN.1 and XML.  But any change to the XML schema, even if the XML world would consider it forward/backward compatible breaks ASN.1 compatibility.  So the initial choice that was made to use this type of ASN.1 encoding had its pros, but now we run into one of its cons."

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