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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-comment message

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


Subject: Feedback for public review of cap-v1.2-au-profile-v1.0-csprd01 [SEC=UNCLASSIFIED]


UNCLASSIFIED

OASIS,

 

The feedback below is submitted on behalf of an Australian reviewer as the issues raised could potentially impact the content of the OASIS document.  The Reviewers details are:

 

Reviewer’s Name:   Luke Corbett (Director) - +61 488 887 473 / luke@ripeintel.info  

Reviewer‘s Organisation:   RIPE Intelligence Pty Ltd (www.ripeintel.info)

 

1) The current OASIS CAP and CAP-AU standards focus on the <info> component with <area> being secondary or slave, which enables issuers the ability to apply one message to multiple areas (which is not in itself a bad thing).  A more suitable approach would be to declare the area and then subsequently declare what messages [hazards] apply to that location.  This approach makes it a lot easier for the public to consume the warning.

Understandably, this approach requires more than just an adaptation of the CAP and is no doubt out of scope.

 

Initial consideration from CAP-AU Project Manager:  This approach would fundamentally change the OASIS CAP approach, which is a body of work that is outside the scope of the Australian CAP Project. This comment is forwarded to OASIS for future consideration during the development of OASIS CAP version 2.0.  Additional explanatory information is available upon request, from the RIPE document that this comment was extracted from.

 

 

2) <incidents> - This tag allows issuers to manage multiple messages sent for a single incident. This supports the top down approach to messaging (agency to public) however does not enable easy consumption at the consumer end (public).  A more appropriate use of this tag would enable the consolidation of warnings by location as opposed to incident.

 

Initial consideration from CAP-AU Project Manager:  This issue is forwarded to OASIS for consideration and advice regarding best practice approach. 

 

 

3) <msgType> - Does not explicitly allow for a warning to be lifted or declared safe. Many Australian agencies just remove warnings leaving the public wondering if something has gone wrong with the system/data feed. It is important that any solution enables agencies to issue a safe/all clear/completed message at the conclusion of a warning.

 

Initial consideration from CAP-AU Project Manager:  Use of CAP values “cancel” or “update” may be an appropriate procedural solution for Australian CAP users.  This issue is forwarded to OASIS for consideration and advice regarding best practice approach. 

 

 

 

 

Greg Trott

CAP-AU Project Manager

Australian Government Attorney-General's Department

 

 



If you have received this transmission in error please
notify us immediately by return e-mail and delete all
copies. If this e-mail or any attachments have been sent
to you in error, that error does not constitute waiver
of any confidentiality, privilege or copyright in respect
of information in the e-mail or attachments.




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