OASIS Open Mailing List Archives  ·  All Lists  ·  emergency-cap  ·  2019-05

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]