OASIS Emergency Management TC

  • 1.  RE: [emergency] SBE Viewpoint

    Posted 02-15-2010 23:20
    Ron,
     
    Strongly agree. 
     
    I also was pointing to the ebXML CPA as an example of mechanisms that link between the exchange message envelope and the ability to determine what the relationship is between the bits and bytes and the real world.
     
    BTW - I've just recalled another nifty feature of CPA - the CPA ID - which can be private.  So even if I managed somehow to get hold of someones digital certificate for signing messages - I may not know what the CPA ID is that defines the relationship between X and Y - because as partner W with Y - I have never seen the CPA ID they are using.  And the CPA ID can be specific to message exchanges - so I may have different values depending on the types of messages in an exchange.
     
    Conversely - where is proves problematic to have digital certificates - they are not the easiest thing to say shoehorn into a device - whereas a CPA ID code can be used in a configuration to authenticate the relationship and exchange.
     
    To the general discussion though - seems to me - need is to add supporting documents and profiles of use to the base schema in the CAP spec's - rather than retooling the schema persay.
     
    These profiles are things you can vote on separately - and implementers will want to use then to supplement the schema.
     
    Mentioning which - as Chair of CAM TC - I need to mention that CAM templates provide a great way to specify profiles of use - that overlay on top of a generic schema - and provide the actual "rules of engagement" and content for specific application use.

    Thanks, DW
     
     



  • 2.  Re: [emergency] SBE Viewpoint

    Posted 02-16-2010 00:15
    David,
    
    No offense, please.
    
    I know you mean well and that there are solid reasons why this 
    information is valuable, but we really must focus on CAP v1.2. This 
    discussion is more relevant to the upcoming CAP 2.0 work and EDXL-DE 2.0 
    work. However, we are not there yet. We have to get the current 
    situation resolved before we can change focus because the time will have 
    arrived when we can actually move on and dig into all this very 
    interesting stuff.
    
    For now we have to avoid issue creep.
    
    Cheers,
    Rex
    
    David RR Webber (XML) wrote:
    > Ron,
    > Strongly agree.
    > I also was pointing to the ebXML CPA as an example of mechanisms that 
    > link between the exchange message envelope and the ability to 
    > determine what the relationship is between the bits and bytes and the 
    > real world.
    > BTW - I've just recalled another nifty feature of CPA - the CPA ID - 
    > which can be private. So even if I managed somehow to get hold of 
    > someones digital certificate for signing messages - I may not know 
    > what the CPA ID is that defines the relationship between X and Y - 
    > because as partner W with Y - I have never seen the CPA ID they are 
    > using. And the CPA ID can be specific to message exchanges - so I may 
    > have different values depending on the types of messages in an exchange.
    > Conversely - where is proves problematic to have digital certificates 
    > - they are not the easiest thing to say shoehorn into a device - 
    > whereas a CPA ID code can be used in a configuration to authenticate 
    > the relationship and exchange.
    > To the general discussion though - seems to me - need is to add 
    > supporting documents and profiles of use to the base schema in the CAP 
    > spec's - rather than retooling the schema persay.
    > These profiles are things you can vote on separately - and 
    > implementers will want to use then to supplement the schema.
    > Mentioning which - as Chair of CAM TC - I need to mention that CAM 
    > templates provide a great way to specify profiles of use - that 
    > overlay on top of a generic schema - and provide the actual "rules of 
    > engagement" and content for specific application use.
    >
    > Thanks, DW
    >
    >