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: Google Australia 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 cap-v1.2-au-profile-v1.0-csprd01  document. 

 

The Reviewers details are:

 

Reviewer’s Name:  Matt Dawes (Public Policy & Government Affairs) - +61 2 9374 4108 / mattdawes@google.com

 

Reviewer‘s Organisation:  Google Australia Pty Ltd

 

 

1) It would be helpful to provide more guidance on the use of the <incidents> field. Is there

a standard format for specifying incidents, or is it free text? Who defines incident strings

and how are they shared among different agencies?

 

Initial consideration from CAP-AU Project Manager: Australian Users would benefit from receiving best practice advice from OASIS regarding this issue.

 

 

 

2) Question: You have an <alert> with multiple <info> fields, and each <info> references a

different <area>. You need to send an update that cancels the <alert> for one <area>

and continues the alert for the other <area>s. What is the recommendation to send this

update? It seems that it must be two separate <alert>s, one having <msgType> cancel

and one with <msgType> update.

 

Initial consideration from CAP-AU Project Manager: Australian Users would benefit from receiving best practice advice from OASIS regarding this issue.

 

 

 

3) For the <area> element, does <circle> and <polygon> take precedence over

<geocode>? In other words, if both a <circle> and a <geocode> are provided, the

boundaries implied by the <geocode> will be different than the circle. We assume the

intent is to alert people in the area of the <circle>?

 

Initial consideration from CAP-AU Project Manager: Australian Users would benefit from receiving best practice advice from OASIS regarding this issue.

 

 

 

4) Can both <polygon> and <circle> be provided in the same <area>? If so, are

they complementary, or does one take precedence over the other?

 

Initial consideration from CAP-AU Project Manager: Australian Users would benefit from receiving best practice advice from OASIS regarding this issue.

 

 

 

5) It would be beneficial if the profile or associated usage guide provided a suggested way

to specify the event area, and not just the alertable area. An example is bushfires; the

CAP <area> specifies the alertable area, the area in which people should be warned

about a fire. There is no good construct in CAP to specify the actual area where the fire

is burning.

 

Initial consideration from CAP-AU Project Manager:  Australian CAP Stakeholders did discuss the value of developing a comprehensive rules guide during a CAP workshop held in February 2011; however, consensus at the time was that this type of guide was an implementation issue and that the time it would take to obtain agreement to the content would significantly exceed the schedule that was available to the CAP project.  Therefore, it was agreed that development of a Best Practice Guide would be excluded from the scope of work for the CAP Project due to the risks it imposed.

 

OASIS, Canada and the World Meteorological Organization (WMO) have indicated at an international CAP Workshop in April 2011 that they wish to develop a Best Practice Guide to assist nations interpret how to apply the CAP rules effectively. 

 

The CAP Custodian will be responsible for monitoring development of Rules and Best Practice documents produced by international CAP Users and will report developments to the CAP Stakeholders group during the annual work plan activities.

 

 

 

6) It would be beneficial if the profile or associated usage guide provided a way to handle

the end time of an event, in addition to the <expires> time of an alert. We see frequently

with alerts from the National Weather Service in the US, that the expires time denotes

the “time before which an update to the alert is expected” and not the “time which the

alertable event is expected to end”. While the former is useful for routing and displaying

messages, the latter is more useful for notifying the public.

 

Initial consideration from CAP-AU Project Manager: Australian Users would benefit from receiving best practice advice from OASIS regarding this issue.

 

 

 

7) Editorial comments on CAP profile:

a) Page 24, In Profile Specification Normative for ‘Effective’, ‘Note 2’, there is a typo “<msgTyp>” should be <msgType>

b) In Profile Specification Non-Normative for ‘Expires’, ‘Example A’, the time in the text

explanation (0700 UTC) does not match the timestamp in the example below (+09:30).

 

Initial consideration from CAP-AU Project Manager: Agree that these edits should be corrected in the next revision of the document.

 

 

Greg Trott

CAP-AU Project Manager

Australian Government Attorney-General's Department

Tel: +61 - 2 - 6141 3904 

Email: Gregory.Trott@ag.gov.au

 

 

 



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]