OASIS Emergency Management TC

  • 1.  CAP 1.2 and related issues.

    Posted 02-16-2010 14:09
    Folks,

    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!!!!

    Respectfully,


    Gary Ham
    703-899-6241





  • 2.  Re: [emergency] CAP 1.2 and related issues.

    Posted 02-16-2010 15:18
    > 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?
    
    Gary I certainly agree with your comments about scope for 1.2, but I do not agree that Neil's proposal is equivalent to what is currently in the draft of 1.2.  Under Neil's proposal, a signature would look like this,
    
    


  • 3.  Re: [emergency] CAP 1.2 and related issues.

    Posted 02-16-2010 15:36
    Jake,
    
    He may have to adapt a bit, but the concept works.  And while the schemas do not match, an actual message created in the DM-OPEN proposal would validate in 1.2 as defined.  The key for Neil is to also assure that a message created in pure 1.2 could also be processed through DM-OPEN as previously expressed.  The point is, this capability is on DM-OPEN to achieve.  We believe that we can.  DM-OPEN implementation issues should not stop CAP 1.2 at this point.
    
    R/s
    
    Gary Ham
    
    On Feb 16, 2010, at 10:15 AM, Jacob Westfall wrote:
    
    >> 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?
    > 
    > Gary I certainly agree with your comments about scope for 1.2, but I do not agree that Neil's proposal is equivalent to what is currently in the draft of 1.2.  Under Neil's proposal, a signature would look like this,
    > 
    >