CAP IPAWS Profile Comments

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

Title: CAP IPAWS Profile Comments

I have reviewed the latest CAP IPAWS profile document, and the comments are listed below. Many of these comments came from the first review, as I did not see them explicitly addressed in the revisions. If there are any questions on these comments please contact me at 301-639-5717.

Section 1.1: I have a general concern with defining separate profiles for every type of CAP consumer. This leads to some serious complications and inefficiencies when implementing an IPAWS solution, namely:

* The message traffic will be larger, because the CAP message itself needs to accommodate the different types of consumers OR there must be more messages sent for each alert to address the specific consumer needs;

* The producer of the alerts will have to be aware of the consumer, which is against the typical publisher/subscriber pattern. You can make a much more efficient solution that can tolerate more changes to the consumers when knowledge of said consumers is not built into the composition of the message.

An IPAWS message distributor should not have to understand and tailor messages to the potential subscribers that might receive it. The interpretation of the message itself should be done at the subscriber level (even if through an "interpreter" or "adapter"), since the distributor might not be aware of all the downstream subscribers that might be processing the message. I become concerned if we start developing various cases such as "an IPAWS Profile for CAP for CMAS consumers" and an "IPAWS Profile for CAP for XYZ consumers" and so on. We want one message, with one interpretation, for IPAWS. Otherwise, a nationwide system that is supporting literally hundreds of legacy systems will not work.

Section 1.1: The CAP is not a protocol - it is more of a message format standard. One of the things that we need to do in order to support an IPAWS implementation is to define the protocol – what messages would be exchanged by a client that wishes to add an alert, as well as appropriate responses? What messages would be exchanged by a client wishing to query these messages? What about a reconstitution protocol, that would allow a client to “catch up” with the current alerts after recovery from a failure? How would a subscriber (receiver) of alert messages define a subscription which would allow the IPAWS provider (publisher) to know what kinds of messages should be published to given subscribers?

Section 1.3: Profile - misplaced period after the "the" in the first sentence.

Section 2, Table 1: The following fields are not included in the table and need to be addressed:

* Message ID – we feel that the message identification needs to be standardized so that messages are universally unique and have some sort of semantic scheme.

* Restriction – there is no guidance on how this field is used – it is especially important if we plan to support IPAWS messages targeted for certain audiences, and we want that to be consistently interpreted and applied.

* If all messages are supposed to be “public” (I have concerns about that later on), should “private” be a banned field? Same with “Restriction”?

* Incidents – it is not clear from even the CAP specification how instance identifiers are associated with a CAP message or segment. If this field is not allowed, state so. If allowed, we need to be specific on how it is to be used to promote consistency.

* senderName/headline – each of these fields should be required, as these are the kinds of fields one would want displayed on situational awareness displays about the alert

Section 2, Table 1 (Status): How would the public and/or other systems integrated with IPAWS know the difference between a “real” alert message and a test message? You can use fields like “Status” as a means of defining a subscription for a given alert subscriber – why try and “hide” that very useful and pertinent information?

Section 2, Table 1 (Code): Fields like “code” need to be specified so that there is no interpretation problem. Including a string does not enforce the necessary conformity you need in a nationwide system that needs to interpret these fields in the same manner. Should it only contain "IPAWSv1.0"? What if it contained "IPAWSv1.05"? What if we are on IPAWSv1.1 (which we are now) and the message had IPAWSv1.0? Does the client reject messages that have the wrong IPAWS profile version? This kind of information should probably go in a "version" field.

Section 2, Table 1 (info): I think the constraint of making every CAP message available to the public is a real problem – it limits your ability to define CAP messages for users like FEMA to dispatch resources or handle responses to situations. Every CAP message is not necessarily going to the public – it may be going agency to agency.

Section 2, Table 1 (eventCode): How will the receiving system know if the code has been approved by the FCC? Is that a validation constraint passed on to the recipients of the message?

Section 2, Table 1 (effective, onset): Since requirements for the IPAWS system have not yet been defined, we cannot say for sure if there will be requirements to disseminate alerts that do not take place until future time, which means alert initiators (like state emergency managers) might want to send a CAP message to an IPAWS service with a future time stamp. If we want solutions to store the message and not disseminate until the effective/onset time, then we need the ability (outside of free-form fields like <description>) to specify future timestamps and have them be respected.

Section 2, Table 1 (expires): Are we sure that the expiration time of every event will be known? I can imagine large classes of emergency alerts that will not have an expiration at the time they are generated and disseminated. Recommend that this be optional, and if not provided, the alert does not expire (which is the way it is in the specification).

Section 2, Table 1 (resourceDesc): The field name is in bold, so I assume it is required. "resourceDesc" should only be required if there is a resource that goes along with it. In other words, specifying a resource is optional. If you do have a resource, resourceDesc is required.

Section 2, Table 1 (mimeType): Why invent new MIME types that are not supported by standard players? The majority of the MIME types can be viewed or played by many COTS products, and it is more work for a client (consumer) to translate some logical name into what it really is, and then pass it on to a player for playback. I don't see value in adding this field for this profile - let them use the standard.

Section 2, Table 2: I am uncomfortable having the producer, especially in an environment with multiple consumers, having to understand exactly who will be receiving these messages, and making these consumer-specific parameter assignments. It will result in more messages sent, and sets a bad precedent, especially if those values conflict with one another for different consumers.

Section 3.1: We’re missing a fourth and probably most important party in an IPAWS solution – the IPAWS Message Distributor. The way IPAWS will work is that an IPAWS Message Producer will send a message to an IPAWS Message Distributor, and the IPAWS Message Distributor will publish the message to the IPAWS Message Consumers, hopefully through some subscription mechanism.

General: Clean up all the typos, spacing and grammar errors. Fix the page numbering as well - last page reads 16 of 22.

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