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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

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

Subject: CAP 1.2 and related issues.


After reading all of the e-mails related to this issue, I am actually sorry that the committee vote failed, and that I bear some of the responsibility for that failure.  CAP 1.2 is supposed to be (and is as drafted) a minor change from CAP 1.1.  Given the chance to vote (I was not on the voting list due to missed meeting for medical reasons) I will vote for it exactly as written.

So, why the apparent change of heart?  For one thing, the changes needed for DM-OPEN have NOTHING TO DO with CAP in general, and everything to do with signature requirements related related to the implementation of IPAWS.  So, if a change really is made, it probably belongs in the more specific IPAWS Profile than it does in the CAP 1.2 spec.  Secondly, if you take a look at the change proposed by Neil Bourgeois that he wants to make in the schema used by DM-OPEN, that change actually would result in messages that validate to the currently proposed CAP 1.2 specification!!!!!!  So why change it?

The result of his change is that messages signed for use by IPAWS would use the IPAWS managed signature world in the format he has defined.  But that world fits within the <any> space of the CAP 1.2 Spec just fine.  So long has DM-OPEN is fitted to maintain the values of the <any>  that do not fit in the arena of IPAWS managed signatures when those messages are passed through, there will be no problem.  But there will be no IPAWS or DM-OPEN management of those values.  To DM-OPEN, they would be treated as irrelevant overhead to be maintained, but not processed in any way.

The net effect is that the schema used by DM-OPEN to generate it WSDL and Clients would look like Neil's  proposal (and like a profile of CAP 1.2) but it would, because of the optionality of the extra tags within the area that CAP 1.2 allows <any>, also take any other valid CAP 1.2 Message.  I really wish I had seen this fact before.  For that I apologize to all of you. 

As for the rest of the arguments about validity, non-repudiation, "the right way to do signatures", etc., etc. They are well beyond the scope of CAP 1.2.  We agreed on that before we started the CAP 1.2 process.

Let re-vote on this and get it done!!!!


Gary Ham

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