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

[Rex Brooks <rexb@starbourne.com>]

Hi again Jacob,

I've gotten to Issue 33 (relates to 32 but I just pulled parameter 
into its own table without any other changes yet) and located this 
email, but i am not clear what language to use. Could you boil this 
down to just what should be used for the "reserved" parameter 
valueNames? It would also be helpful if this came with a suggestion 
of where to put it in the Table 2 >parameter> details that I've 
created.

Currently it is just a copy and paste from before into its own table 
with each of the numbered items in its own row.

Cheers,
Rex

At 10:43 AM -0400 5/1/09, Jacob Westfall wrote:
>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
>--
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


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