Comments on the CAP 1.2 Draft Specification

["Miller Jr, David C" <david.c.miller.jr@lmco.com>]

Title: Comments on the CAP 1.2 Draft Specification

If there are any questions with regards to these comments, please contact David Miller at 301-639-5717 or Brian Cooper at 301-640-4336.

General Overall Comments:

Footers: Footers appear to be overlapping older copies of itself – please fix.

Language support: UTF-8 only supports languages with 8-bit character sets. So, how can CAP messages support other languages?

Specific Comments:  
Section 1.1, Page 6: CAP as a protocol should define “roles” of interested parties that may use the message (or its derivatives), the sequence of messages exchanged between these roles in an operational context, and error handling (such as for duplicate messages).    
Section 1.3, Page 7: <area> should be required for all alerts, which is not implied by the 1^st sentence in section 1.3      
Section 1.3.4, Page 7: Instead of <circle> and <polygon being the “preferred” representation, they should be the required representation. This is necessary to support display, distribution, and accurate representation of alerts, which rarely (if ever) fall into nice geopolitical boundaries.   
Section 2.3.4, Page 11: CAP message does not have “targeting” per se (2^nd paragraph).CAP messages define the area in which the alert occurs, but that says nothing at all as to where the alert should be directed. The difference between the affected area (which CAP addresses) and the area of interest (where you might target an alert message) is not at all addressed by CAP.  
Section 3.2.1, Page 13: Identifier - There ought to be some kind of format or standard mentioned here so that uniqueness can be guaranteed. This is especially important for specific usage profiles where uniqueness is paramount to correct function.
Section 3.2.1, Page 13: Sender - The method of uniqueness ought to be specified here to facilitate automated processing.  Is this an email address?       
Section 3.2.1, Page 13: Sent - Reference the standard xs:dateTime type. Why would we define a new date/time representation standard when W3C has a perfectly good and internationally accepted standard?       
Section 3.2.1, Page 15: Addresses - The format of these addresses should be identified here so that support for routing can be automated.       
Section 3.2.1, Page 16: Incidents - There is no place in the CAP message for an “incident ID” or “incident name”, so how do we relate the “incidents” here to an existing message that may have already been sent?     
Section 3.2.2, Page 16: Info, bullet 2 - <area> should be required, per above comment on section 1.3.4, page 7.    
Section 3.2.2, Page 20: Effective, Onset - Reference the standard xs:dateTime type. Why would we define a new date/time representation standard when W3C has a perfectly good and internationally accepted standard?   
Section 3.2.2, Page 21: Expires - Reference the standard xs:dateTime type. Why would we define a new date/time representation standard when W3C has a perfectly good and internationally accepted standard?    
Section 3.2.2, Page 21: senderName - This should match the same format as “sender” in the alert block. 
Section 3.2.2, Page 21: Headline - Should be required. This is the kind of field that would be displayed on many systems as the tagline for the alert. 
Section 3.2.2, Page 21: Description - Should be required. A proper understanding of an alert requires the description.   
Section 3.2.3, Page 23: mimeType - Should be required if drefUri is supplied.  
Section 3.2.3, Page 23: Size - Should be an actual size if derefUri is supplied (to cross-check integrity)     
Section 3.2.3, Page 24: derefUri – Why the restriction for #4? DerefUri is the safest and most secure method of transmission, because then you can sign the message (protecting the resource contents from tampering). The digest provides yet another safety measure.
Section 3.2.3, Page 24: Digest - Should be required if derefUri is present. Also, should not be restricted to SHA-1, since that can be broken. Recommend a “digestAlgorithm” field so that the associated algorithm for computing the digest can be provided.  
Section 3.2.4, Page 24: Area - We recommend that <circle> or <polygon> (one of these two) be required, to support the fact that alerts do not fall on nice geopolitical boundaries, and to support automated rendering of the alert area.      
Section 3.2.4, Page 25: Polygon - The coordinates should be ordered (i.e. points should be listed in order of adjacency from first to last).   
Section 3.2.4, Page 26: Geocode - Recommend this field be deprecated in favor of <polygon> and <circle>.       
Section 3.3.2, Page 27: Do not define the form of date/time here – reference the standard xs:dateTime type already defined by W3C. Why should we define some specialized form of xs:dateTime?  
Section 3.3.4.1, Page 28: “Other XML signature mechanisms MUST NOT be used in CAP Alert Messages.” - Disagree. CAP messages will most likely be used in SOAP messages, which have their own signature header blocks, which will protect the contents of the message. That is the correct usage of signature in these cases and should not be restricted by the standard. 
Section 3.3.4.1, Page 28: 2^nd paragraph - Disagree on the grounds of security. If you are unable to validate the signature, then the alert may itself be invalid or worse yet tampered with. This approach violates most security rules. Suggest that the message be ignored if the message is not authenticated.   
Section 3.5, Page 32: Why are we supporting a non-XML standard for this message? It is important to understand that these messages will require data security, and XML provides this. Other representations will be less secure and less supported (XML support is much greater than ASN.1). 
Section 4, Page 37: This section seems to focus on XML and not ASN.1, which is more justification to the argument that XML is the right way to go.  
Section 4.3, Page 37:  “a standard protocol (for example, EDXL-DE)” - Replace “protocol” with “message envelope”. EDXL-DE is not a protocol.   
Appendix A, Page 39: No ASN.1 examples      

David C. Miller, Jr.
Lockheed Martin Information Systems & Global Services - Civil

321 Ballenger Center Drive
Frederick, MD 21703-4565
Cell: 301-639-5717
Home Office: 301-560-7198
Frederick Office: 301-698-3387
Greenbelt Office: 301-623-4363
Email: david.c.miller.jr@lmco.com

smime.p7s