OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (EMERGENCY-31) Clarify and standardize ways to cancel a CAP alert


    [ https://issues.oasis-open.org/browse/EMERGENCY-31?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=53382#comment-53382 ] 

Norm Paulsen commented on EMERGENCY-31:
---------------------------------------

"Update" and "Cancel" have both been used since the beginning to end an alert message from playing. Cancel can do it at the <alert> block level whereas Update does it at the <info> block level with the <expires> element. But because <expires> is optional, some recipients look to Cancel only, thinking this is the "de facto" standard practice.

So to answer your question, if the recipient just plays the message they are told to play with elements like expires, urgency, severity and certainty (and others if need be) as the ones to use for answering the "when to play?" and "how long to play?" questions, then your question becomes moot.

Its called a CAP Message in CAP for a reason, not CAP ALert. CAP Alert Message is ok too, because Alert is then used as an adjective to describe what type of message we have. In this way CAP can be agnostic to the many ways people define what an Alert is. CAP is just a message to whatever that is. You define Alert above as a living thing that gets updated over time, but the media/recipient often don't think of it that way.Some think each message is a new Alert.

So if you want a message to "play" when you  end an aler as you and I see them, you can do so in CAP. If you want no message to play when the alert is over you can do that too. 



> Clarify and standardize ways to cancel a CAP alert
> --------------------------------------------------
>
>                 Key: EMERGENCY-31
>                 URL: https://issues.oasis-open.org/browse/EMERGENCY-31
>             Project: OASIS Emergency Management TC
>          Issue Type: Bug
>          Components: CAP 
>            Reporter: Steve Hakusa
>
> From https://www.oasis-open.org/apps/org/workgroup/emergency-cap/download.php/54116/Sep15-2014-meeting-notes.doc and also discussed in https://issues.oasis-open.org/browse/EMERGENCY-4
> 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.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]