Re: [emergency-comment] CAP IPAWS Profile Comments

[Rex Brooks <rexb@starbourne.com>]

Hi David,

We address all comments, and our resolutions can be found in the 
IssuesLists, where we record them as we go through the process. Those 
we decide to incorporate are included in the revised specification 
document. You can find the resolutions in the IssuesList. The last 
IssuesList is located at (and can be downloaded from) the Documents 
page of the EM CAP Profiles SC in the Resources folder:
http://www.oasis-open.org/apps/org/workgroup/emergency-cap-profiles/download.php/33000/CAPv1.1-IPAWS-Profile-v1.0-PR01-IssuesList_v2.4.xls

You can see what the resolutions were for issues you submitted. As I 
recall several were decided as out of scope for this particular work, 
but should be addressed in CAP v1.2 for which we are in the midst of 
the Public Review.

I should say, just for the record, that v1.2 is intended to be a 
relatively quick fix for a very few specific issues and we are poised 
to take up the task of gathering formal requirements for CAP 2.0 as 
soon as CAP v1.2 work is concluded.

I'm sure you are aware of the difference between between a minor 
revision within a numerical series, e.g. 1.x and a major revision 
that starts a new numerical series, e.g. 2.0.

So we have to weigh whether or not an issue falls within one or the 
other category, and the longer we spend on 1.2, which is also likely 
to vex this profile as well; the longer it will take for us to tackle 
2.0.

I haven't gone over your comments completely, but I can see where at 
least one is a typo, which shows me that I will need to go over this 
thoroughly when I have some time, and mark which ones are 
correctable. This will have to happen after I compile the redline 
version which marks the deltas between the first Public Review and 
the next one.

At this point in our process specifications need to be frozen until a 
decision is taken, and any changes that the TC approves will made at 
that time. However, for now, this work has moved out of the SC 
process and is now a TC matter. You may already have known this, but 
I wanted to be clear about it anyway.

It is always a temptation for an editor to take care of "little" 
fixes, but I can attest that that can get us in difficulties. So all 
I can promise is that I will mark the ones that won't need discussion 
so that I can do those quickly at the time needed for a possible 
"approved as corrected" motion. If the TC declines to approve this 
draft, it will go back to the SC, most likely.

For now, I'm really working hard to catch up on a number of works in 
progress, following a recent presentation as well as this work, and 
the new work we have started.

Cheers,
Rex


At 2:55 PM -0400 6/23/09, Miller Jr, David C wrote:
>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
>
>
>Attachment converted: Macintosh HD:smime 1086.p7s (    /    ) (0178805E)


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670