Re: [emergency-cap-profiles] Preliminary thoughts on a few of Jacob's latest comments

[Jacob Westfall <jake@jpw.biz>]

CC'ing this reply to the public comments list as well.

>> 3. A note should be added about potential <valueName> collisions
>> between those of this profile and what other system developers may
>> choose to use.
> 
> There's a potential for collisions, of course, and that's something we've talked about addressing
> in 2.0 by using UUIDs for valueNames.  In the meantime, what would such a note say, exactly?

An implementation notes section could be added.  In a section on valueNames, "The following valueNames (....) are reserved by the profile.  Implementers intending to use the IPAWS Profile should ensure that conflicting uses for these valueNames does not occur."

>> 4. Are multiple <eventCode>s with a <valueName> of SAME allowed
>> in an <info> block?
> 
> SAME only provides for one, and this particular value doesn't have any use other than for
> back-compatibility with SAME, so I can't think of any reason to have more than one.

The eventCode element is multi-instance so there is nothing in the current draft to prevent someone from using two SAME codes.  Due to the fact that some SAME codes speak to an event and others to actions, its a situation that could arise with an HMW and SPW both being valid.

>> 5. In order to support a number of different exchange partners using
>> the same message, a <parameter> should be added to allow an alert
>> issuer to indicate that a particular partner should ignore a message
>> that would normally be acted upon...
> 
> second- and third-order implications of a manual routing decision.  The message originator is
> really only authoritative on the subject of the alert content.  Alert routing should be done on 
> the basis of policy, not spur-of-the-moment choices.

The originator is going to have message distribution definitely in mind when creating a message.  If I use X,Y,Z for the U/S/C then such and such system will get triggered, etc...  Or if I check the EAS and HazCollect boxes in my alerting application, then these systems will get the message.  Of course the whole distribution dicussion leads to the DE and other things outside the IPAWS profile itself.  The idea of this parameter would be to add an exchange partner intent indicator to the CAP message to assist in policy decisions.  Its something to think about but not a necessary item.

>> 6. When alert information is delivered to the public through two
>> simultaneous methods using one medium, the message should be
>> synchronized....                                                          For EAS
>> broadcast content (sound/video) included in a message as a
>> <resource> there is no accompanying text content element.
> 
> This is possibly a bit out of scope for the profile, since it has to do with the rules for how CAP
> messages are to be transformed into SAME.  The ECIG has already specified how the CAP <description>
> and <instruction> elements should be transformed into audio and visual formats for EAS.

CMAS provides for rules to generate the text from included elements, like the ECIG did, or will use the CMAMtext as the intended text, bypassing these rules.  This new parameter would bring EAS inline with CMAS on this issue.

Some constructive criticsm regarding the ECIG rules.  I have yet to see a CAP message that follows these rules that is coherent to anyone else but EAS.  The rules are broken and usually result in gibberish.  The instruction ends up in the areaDesc, the event is a hanging sentence, and the ... just serve to further confuse the end-user.  If the ECIG could provide the sample messages that were used to create these rules, or provide some examples, I think it would really clear up the use and implementation of these rules.

Regardless this parameter would make everyone's life easier.  This parameter would have the exact text from the audio/video file and the rules could be a last resort.  Issuers don't need to try and sprinkle the text through the CAP elements according to the rules, nor do the EAS devices need to try and assemble it.

>> 9. The current requirement to include at least one <geocode> with a
>> SAME value should be changed to optional. The mandatory use of
>> geocodes should only be used to support legacy EAS equipment and
>> should not apply to more capable next-generation systems...
> 
> While I agree with the intent, the ECIG has already rejected the idea of requiring each and every
> endec do the geospatial math to derive the SAME-required conversion to FIPS codes.  Endecs are
> fairly simple-minded devices, and the manufacturers are quite cost-conscious.

From a standards point of view, the profile sends a very contradictory message.  In CAP it states that geocodes are all but deprecated and that geospatial is the preferred area representation.  But the Profile then makes a SAME geocode element required.  The geocode should be left optional but the Profile can define its form.  In practice many will use the geocode anyways, but SAME geocodes should not be required because then its no longer just "legacy support".

With regards to endec support.  Again there is no technological reason the endecs cannot do geospatial calculations.  I personally have written a real-time GPS nav system that ran on a $5 microcontroller doing more complicated calculations than just the required "point in polygon".  The code and computational resources necessary to do these calculations are much less than say, decoding an MP3 file included in the resource block, XML signature/encryption decoding of the CAP message, or performing text-to-speech translation of the message.

It would become an additional selling feature to support geospatial.  A manufacturer could offer a GPS option.  The GPS would provide a consistent date/time signal and perhaps offer an auto-config method for easy setup to prevent configuration errors, the GPS populates the geospatial location and SAME geocodes at the same time.  I'm sure the broadcasters would be interested in reducing alert message spillover and the viewer complaints that can result.

-- 
jake@jpw.biz
--