emergency-cap — archive
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]
FW: CAP Cancel question
Thanks, Gang. I wasn't sure if Cancel had formally been re-defined or clarified in any formal documentation. I'm currently trying to determine whether or not NWS needs to change the way we use Cancel. Currently, we heavily use Cancel when all or portions of the alert have been canceled or have expired. That is, we don't strictly use it to revoke an alert sent in error. There might also be unintended consequences on downstream systems such as IPAWS/WEA if we change the way we use Cancel.
Mike
On Wed, May 8, 2019 at 2:57 PM rexbroo < [email protected]
> wrote:
From the Issues List
https://issues.oasis-open.org/browse/EMERGENCY-31
There are multiple different ways to Cancel a CAP
message, each with subtle meanings.
msgType Cancel is more akin to Revoke. Consider
renaming, and adding a requirement that Cancel messages do not
have an info block.
msgType Cancel could apply to the event instead
and may be part of the new event information construct for CAP
Current practice in widespread use is to use an
info block with a Cancel to explain the reasons for the
cancellation. Clarify whether Cancel is appropriate for this
case, or should msgType Alert be used. Clarify how to specify
expires times in these cases.
Clarify how to use Cancel with responseType
AllClear, noting Cancel practices had evolved out of the lack of
All Clear in prior CAP versions .
From the Issues List:
https://issues.oasis-open.org/browse/EMERGENCY-100 :
Proposal:
msgType
cap.
alert.
msgType.
code
The code denoting the nature of the alert
message (REQUIRED)
Code Values:
"Alert" - Initial information requiring attention by
targeted recipients
"Update" - Updates and supercedes the earlier message(s)
identified in <references>
"Cancel" - Cancels (repudiates) the false alarm in the
earlier message(s) identified in <references>
"Ack" - Acknowledges receipt and acceptance of the
message(s) identified in <references>
"Error" - Indicates rejection of the message(s) identified
in <references>; explanation SHOULD appear in
<note>
From the latest version
of Practices Committee Note that I have:
3.4
Alert cancels
Historically,
there
has been some confusion as to what cancel means, and in
practice it has been
used for different purposes. U pdate and cancel have both been used since the beginning
to end an alert
message from playing. C ancel
can
do it at the alert block level whereas update does it at the
info block level
with the expires and/or responseType elements. But because these
elements are
optional, some recipients look to cancel
only, thinking this is the "de facto" standard practice.
TBD examples for both practices.
That's all I have on this.
Rex
On 5/8/2019 11:01 AM,
[email protected] wrote:
Please see question from Mike Gerber
regarding the earlier discussion on the use of Cancel . I
recall this discussion but do not recall the resolution. I
also do not see it in the Elements guidance. Elysa
From: Mike Gerber - NOAA Federal
<[email protected]>
Sent: Wednesday, May 8, 2019 10:28 AM
To: Elysa Jones <[email protected]> ; Botterell
Art <[email protected]>
Subject: CAP Cancel question
Elysa/Art,
At one
time, OASIS discussed clarifying the use of CAP msgType
"Cancel". What this ever codified/placed into policy
anywhere?
Thanks.
--
Mike
Gerber
National Weather Service
Office of Dissemination
--
Rex Brooks Starbourne Communications Design
Email: [email protected]
GeoAddress: 1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
Virus-free. www.avast.com
--
Mike Gerber National Weather Service Office of Dissemination
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
— [Date Index]
| [Thread Index]
| [Month Index]
| [List Home]