[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]