1.0 Introduction 1.1 Purpose In order to meet the needs of the Australian Attorney General’s Department (AGD), this CAP v1.2 Australian Profile constrains the CAP v1.2 standard for receipt and translation with and among Australian CAP Users. The Common Alerting Protocol (CAP) provides an open, non-proprietary digital message format for all types of alerts and notifications. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as Web services, as well as existing formats while offering enhanced capabilities that include: Flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; Multilingual and multi-audience messaging; Enhanced message update and cancellation features; Template support for framing complete and effective warning messages; Compatible with digital encryption and signature capability; and, Facility for digital images and audio. (The previous paragraph with bullets was reused from IPAWS Profile Spec – may remove or elaborate if appropriate. Lines 23-33 of the IPAWS Spec are not included; they mention the use of “EDXL” terminology. Ok to not include?) The purpose of this document is to Facilitate the adoption of the international CAP standard within Australia; Provide the Australian Government Profile for the Common Alerting Protocol – Australia (CAP-AU); Provide guidance and reference material to assist Australian agencies and organisations to implement the CAP standard, and; Define the set of rules and managed lists of values that are recommended for CAP use within hazard alerting systems that are implemented in Australia. 1.2 Process This profile was developed in accordance with OASIS Technical Committee Process, for inclusion as an attachment within the Australian Government Standard for the CAP Australia Profile (CAP-AU-STD) that was developed in parallel by the Australian Commonwealth Attorney-General’s Department using the Australian Government National Standards Framework (NSF) process. (Suggested wording to replace the above sentence and para 2&3 in AU doc if appropriate: “This specification has been developed and refined by the CAP Stakeholder Group including a range of agency consultations”. (maybe add additional reference or info about stakeholder group and identify the agencies – are they CIOC and CJCIOC? IF we get decided on a maintenance path of those suggested by Jamie, that path should be included here as a separate paragraph.) 1.3 Terminology The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in [RFC2119]. The words warning, alert and notification are used interchangeably throughout this document. Layer – As used in this document, a Layer refers to message elements that are not required under the CAP v1.2 Standard or under the Australian Profile but that may involve a new rule, other managed lists and/or information specific to a subset of users in Australia’s’ hazard alerting community. A layer is typically supported with the use of one or more parameter elements within a CAP or CAP-AU file. Managed List - As used in this document refers to a collection of permitted values specific to a given element within a CAP-AU file (for example, the AUeventLIST). Profile – As used in this document, a Profile consists of an agreed-upon subset and interpretation of the OASIS CAP-v1.2 Specification to include a collection of rules, managed lists, and other references, which pertain to the CAP Specification. An XML Profile is applied to an existing XML Schema (in this case the OASIS Standard CAP v1.2 Schema) in order to constrain or enforce aspects of it to accomplish a specific purpose according to the definition and criteria set forth for an XML Profile. Any message that is in compliance with the Profile must validate against the original XML Schema as well as the resulting XML Schema of the Profile. A Profile is an accepted means to address needs specific to a country or system using the CAP Specification. (The above definition is used in the IPAWS Spec and the following wording is used in the AU document: The term “profile” is used in this document to refer to a collection of rules, managed lists, and other references, which pertain to the Reference Standard. A profile is accepted as necessary to address needs specific to a country or system using the Reference Standard, and to the full community of users identifying with the profile.) Rule Set – As used in this document refers to a collection of rules which are applied to the use of the CAP-v1.2 Specification, which impose usage requirements beyond those of the Reference Standard, but also remain in compliance with the Reference Standard. (Do you want to define an AU exchange partner? See IPAWS Profile Spec 1.3 line 82) 1.4 Normative References [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt [dateTime] N. Freed, XML Schema Part 2: Datatypes Second Edition, http://www.w3.org/TR/xmlschema-2/#dateTime , W3C REC-xmlschema-2, October 2004. [namespaces] T. Bray, Namespaces in XML, W3C REC-xml-names-19990114, January 1999. http://www.w3.org/TR/REC-xml-names/ [RFC2046] N. Freed, Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types, IETF RFC 2046, November 1996. http://www.ietf.org/rfc/rfc2046.txt [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, IETF RFC 2119, March 1997. http://www.ietf.org/rfc/rfc2119.txt [RFC3066] H. Alvestrand, Tags for the Identification of Languages, IETF RFC 3066, January 2001. http://www.ietf.org/rfc/rfc3066.txt [WGS 84] National Geospatial Intelligence Agency, Department of Defense World Geodetic System 1984, NGA Technical Report TR8350.2, January 2000. http://earth-info.nga.mil/GandG/tr8350_2.html [XML 1.0] T. Bray, Extensible Markup Language (XML) 1.0 (Third Edition), W3C REC-XML- 20040204, February 2004. http://www.w3.org/TR/REC-xml/ [XMLSIG] Eastlake, D., Reagle, J. and Solo, D. (editors), XML-Signature Syntax and Processing, W3C Recommendation, February 2002. http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ [XMLENC] Eastlake, D. and Reagle, J. (editors), XML Encryption Syntax and Processing, W3C Recommendation, December 2002. http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/ [National Standards Framework (NSF)] Australian Government Information Management Office, August 2009. http://www.finance.gov.au/publications/national-standards-framework/index.html [ISO 639.2] Codes for the Representation of Names of Languages, 18 October 2010. http://www.loc.gov/standards/iso639-2/php/English_list.php 1.5 Non-Normative References (There are no non-normative references in the AU Document. The IPAWS Spec references FEMA IPAWS Profile Reqts, EAS-CAP from Industry group and NOAA HazCollect OPEN doc. Is there any material that should be included here for the AU? If not, remove this section.) [Requirements - CAP Australian Profile] Buchanan, K., Trott, G. (editors), Discussion Paper Common Alerting Protocol - Australian Profile, Version 1.0, 30 September 2010. [CAP-AU-STD] Attorney-General’s Department, Australian Government Standard for the Common Alerting Protocol – Australia Profile, dd Mmm YYYY The implementation of the Common Alerting Protocol within Australia is defined within the Australian Government Standard for Common Alerting Protocol – Australia Profile (CAP-AU-STD), which is a three part document that provides background, guidance, rules, managed lists and reference information to enable CAP-AU to be implemented. The CAP-AU-STD includes the following Attachments: Attachment 1 to CAP-AU-STD (EDXL-CAP1.2-AU) – the OASIS Common Alerting Protocol v1.2 Australia Profile Version 1.0, which defines the rules and elements that will apply to CAP-AU Profile; and Attachment 2 to CAP-AU-STD (AUeventLIST) – the Australian Event Code List for CAP-AU, which defines a managed list of recognised events associated with hazard alerting in Australia. 1.6 Requirements (A statement about requirements can be made here if applicable, otherwise, remove. It is important to identify the requirements, and in the future we should have a requirements document for folks to follow. With the AU, their companion document started out as requirements and has evolved to what will become their AU Standard. So, I’m not sure what should be referenced here. It may be that this section should be removed and the Process section be elaborated to include more of the background. The requirements for the CAP-AU were gathered from numerous sources including emerging CAP Country Profiles, and existing CAP Users within Australian emergency management organisations. All requirements were collated into the Discussion Paper Common Alerting Protocol - Australian Profile, and reviewed by the Australian CAP Stakeholder Group during the period October 2010 - December 2010, resulting in an agreed list of CAP-AU requirements. The requirements were finalised as a result of the outcomes from the CAP event codes workshop conducted in February 2011, including establishment of the proposed list of Australian event codes. Subsequent refinement of requirements concluded that the CAP-AU message MUST result in a constrained XML message adhering to the requirements in Table 1. Table 1: CAP-AU Criteria and Miscellaneous Requirements Number Requirement 1. Unless otherwise stated within this “CAP-AU Requirements” table, all OASIS CAP elements SHALL be adhered to exactly as specified in the OASIS CAP Reference Standard. 2. The CAP-AU MUST not become a new or additional messaging “standard” (i.e. another Alerts and Warnings standard or another CAP “version”). It is simply a more constrained version of an existing messaging standard. 3. The CAP-AU message MUST comply with the CAP Reference Standard as follows:. always validate against the CAP Reference standard Schema. Definition and Development of the CAP-AU message may or may not result in a more restrictive Schema. adhere to CAP Reference Standard data dictionary restrictions. validate within the CAP Reference Standard namespace with no changes to root elements. use all required elements (i.e. no deletion of required elements are allowed). not change attributes for required fields. 4. A CAP-AU message MUST be capable of using an existing CAP Reference standard service (i.e. software designed to apply the standard) to receive and understand a CAP-AU message. Number Requirement 5. A CAP-AU message MUST NOT be Proprietary Format. 6. A CAP-AU message MAY further constrain the CAP standard. (may be thought of as a “constraint Schema” against the standard) 7. A CAP-AU message MAY add to required element definitions.(only to extend or interpret the definition) 8. A CAP-AU message MAY limit the size of required elements. 9. A CAP-AU message MAY exclude optional elements. 10. A CAP-AU MAY define elements in a specific, agreed-upon way – as defined and adjudicated for the Profile.