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