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: Dave's Comments on Cap 1.2


Dave et al-

I hesitantly agree to Dave’s point below regarding encryption;  My only experience with validating to schemas is either by writing the code to do it myself or using XMLspy; Both of which seem to work for the 1.2 schema.  I am wary of using the <any> tag, but without something more concrete I can’t really object.  For everyone’s consumption I’ll post the schema and a sample file to test with.

 

Don McGarry

The MITRE Corp.

Office: 315-838-2669

Cell: 315-383-1197

dmcgarry@mitre.org

 

 

All

The Emergency Management Technical Committee needs to address the impacts for embedded <any> xml tags within the CAP v1.2 Committee Specification.  I understand the desire for maximum flexibility for architects and system designers; however, these have significant impact on the architecture for infrastructure for the EDXL family of standards.

Issue:  The internal encrypting of the entire content of a CAP message would require a significant key management infrastructure.  This is doable but creates a very brittle and non-interoperable architecture.  From the EDXL-DE perspective, content objects are examined and key information is extracted for population of distribution header tags.  Since CAP alerting systems by their very nature are designed to create a federated system of systems, the encrypting strategy should be external to the CAP message or if CAP messages are embedded as an EDXL-DE content object which has always been the case since CAP1.0 was established as an OASIS standard.  Recommend removing the schema tag which provides this capability for internal encrypting of CAP 1.2 alert message from the CAP v1.2 Committee Specification.

Note:  From an Infrastructure perspective the <any> element tag for internal signing of CAP 1.2 messages will weaken the federated system of systems architecture since many xml validating methods become less accurate if they encounter this tag when validating any xml schema. This is the initial step for message typing. From an EDXL-DE family of standards perspective, message typing is critical to accurate policy enforcement during distribution.  This could require infrastructure to include in-line tools like CAM validation of content object type which could slow the transmitting of critical alert messages.

David E. Ellis

Chair, EM Infrastructure sub-committee

 



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