ImageVerifierCode 换一换
格式:PDF , 页数:40 ,大小:988.97KB ,
资源ID:804624      下载积分:10000 积分
快捷下载
登录下载
邮箱/手机:
温馨提示:
如需开发票,请勿充值!快捷下载时,用户名和密码都是您填写的邮箱或者手机号,方便查询和重复下载(系统自动生成)。
如填写123,账号就是123,密码也是123。
特别说明:
请自助下载,系统不会自动发送文件的哦; 如果您已付费,想二次下载,请登录后访问:我的下载记录
支付方式: 支付宝扫码支付 微信扫码支付   
注意:如需开发票,请勿充值!
验证码:   换一换

加入VIP,免费下载
 

温馨提示:由于个人手机设置不同,如果发现不能下载,请复制以下地址【http://www.mydoc123.com/d-804624.html】到电脑端继续下载(重复下载不扣费)。

已注册用户请登录:
账号:
密码:
验证码:   换一换
  忘记密码?
三方登录: 微信登录  

下载须知

1: 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。
2: 试题试卷类文档,如果标题没有明确说明有答案则都视为没有答案,请知晓。
3: 文件的所有权益归上传用户所有。
4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
5. 本站仅提供交流平台,并不能对任何下载内容负责。
6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

版权提示 | 免责声明

本文(ITU-T X 1303 BIS-2014 Common alerting protocol (CAP 1 2) (Study Group 17)《通用警报协议(CAP 1 2)(研究组17)》.pdf)为本站会员(boatfragile160)主动上传,麦多课文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。 若此文所含内容侵犯了您的版权或隐私,请立即通知麦多课文库(发送邮件至master@mydoc123.com或直接QQ联系客服),我们立即给予删除!

ITU-T X 1303 BIS-2014 Common alerting protocol (CAP 1 2) (Study Group 17)《通用警报协议(CAP 1 2)(研究组17)》.pdf

1、 I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n ITU-T X.1303 bis TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU (03/2014) SERIES X: DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY Secure applications and services Emergency communications Common alerting protocol (CAP 1

2、.2) Recommendation ITU-T X.1303 bis ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY PUBLIC DATA NETWORKS X.1X.199 OPEN SYSTEMS INTERCONNECTION X.200X.299 INTERWORKING BETWEEN NETWORKS X.300X.399 MESSAGE HANDLING SYSTEMS X.400X.499 DIRECTORY X.500X.599 OSI NETWOR

3、KING AND SYSTEM ASPECTS X.600X.699 OSI MANAGEMENT X.700X.799 SECURITY X.800X.849 OSI APPLICATIONS X.850X.899 OPEN DISTRIBUTED PROCESSING X.900X.999 INFORMATION AND NETWORK SECURITY General security aspects X.1000X.1029 Network security X.1030X.1049 Security management X.1050X.1069 Telebiometrics X.1

4、080X.1099 SECURE APPLICATIONS AND SERVICES Multicast security X.1100X.1109 Home network security X.1110X.1119 Mobile security X.1120X.1139 Web security X.1140X.1149 Security protocols X.1150X.1159 Peer-to-peer security X.1160X.1169 Networked ID security X.1170X.1179 IPTV security X.1180X.1199 CYBERS

5、PACE SECURITY Cybersecurity X.1200X.1229 Countering spam X.1230X.1249 Identity management X.1250X.1279 SECURE APPLICATIONS AND SERVICES Emergency communications X.1300X.1309 Ubiquitous sensor network security X.1310X.1339 CYBERSECURITY INFORMATION EXCHANGE Overview of cybersecurity X.1500X.1519 Vuln

6、erability/state exchange X.1520X.1539 Event/incident/heuristics exchange X.1540X.1549 Exchange of policies X.1550X.1559 Heuristics and information request X.1560X.1569 Identification and discovery X.1570X.1579 Assured exchange X.1580X.1589 CLOUD COMPUTING SECURITY Overview of cloud computing securit

7、y X.1600X.1601 Cloud computing security design X.1602X.1639 Cloud computing security best practices and guidelines X.1640X.1659 Cloud computing security implementation X.1660X.1679 Other cloud computing security X.1680X.1699 For further details, please refer to the list of ITU-T Recommendations. Rec

8、. ITU-T X.1303 bis (03/2014) i Recommendation ITU-T X.1303 bis Common alerting protocol (CAP 1.2) Summary The common alerting protocol (CAP) is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all kinds of networks. CAP allows a consistent warning messa

9、ge to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP also facilitates the detection of emerging patterns in local warnings of various kinds, such as an undetected hazard or hostile act might indicate.

10、CAP also provides a template for effective warning messages based on best practices identified in academic research and real-world experience. Recommendation ITU-T X.1303 bis also provides both an XML schema definition (XSD) specification and an equivalent ASN.1 specification (which permits a compac

11、t binary encoding) and allows the use of abstract syntax notation one (ASN.1) as well as XSD tools for the generation and processing of CAP messages. This Recommendation enables existing systems, such as ITU-T H.323 systems, to more readily encode, transport and decode CAP messages. History Edition

12、Recommendation Approval Study Group Unique ID* 1.0 ITU-T X.1303 bis 2014-03-01 17 11.1002/1000/12150 _ * To access the Recommendation, type the URL http:/handle.itu.int/ in the address field of your web browser, followed by the Recommendations unique ID. For example, http:/handle.itu.int/11.1002/100

13、0/11830-en. ii Rec. ITU-T X.1303 bis (03/2014) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs). The ITU Telecommunication Standardization Sector (ITU-T) is a perman

14、ent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establish

15、es the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of information technology which fall within ITU-Ts purview, the necessary standar

16、ds are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. Compliance with this Recommendation is voluntary. However, the Recomm

17、endation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some other obligatory language such as “must“ and the negative equivalents ar

18、e used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTSITU draws attention to the possibility that the practice or implementation of this Recommendation may involve the use of a claimed Inte

19、llectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process. As of the date of approval of this Recommendation, ITU had not recei

20、ved notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly urged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr

21、/. ITU 2014 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T X.1303 bis (03/2014) iii Table of Contents Page 1 Scope . 1 2 References . 1 3 Definitions 2 3.1 Terms defined elsewhere 2 4 Abbreviations

22、and acronyms 2 5 Conventions 3 6 Design principles and concepts 3 6.1 Design philosophy 3 6.2 Examples of requirements for design . 4 6.3 Examples of use scenarios 4 7 Alert message structure . 6 7.1 Document object model 6 7.2 Data dictionary . 7 7.3 Implementation considerations . 19 7.4 XML schem

23、a 20 8 Use of ASN.1 to specify and encode the CAP alert message . 22 8.1 General . 22 8.2 Formal mappings and specification 22 8.3 ASN.1 module 23 9 Conformance . 25 9.1 Conformance targets . 25 9.2 Conformance as a CAP version 1.2 message . 26 9.3 Conformance as a CAP version 1.2 message producer 2

24、6 9.4 Conformance as a CAP version 1.2 message consumer . 26 Appendix I CAP alert message examples . 27 I.1 Homeland security advisory system alert . 27 I.2 Severe thunderstorm warning . 27 I.3 Earthquake report (Update message) 28 I.4 AMBER alert (Multilingual message) 29 Bibliography. 30 iv Rec. I

25、TU-T X.1303 bis (03/2014) Introduction A brief introduction to the common alerting protocol (the current specification is identified as CAP 1.2) is provided below. Purpose The common alerting protocol (CAP) provides an open, non-proprietary digital message format for all types of alerts and notifica

26、tions. It does not address any particular application or telecommunications method. The CAP format is compatible with emerging techniques, such as web services and the ITU-T fast web services, as well as existing formats including the specific area message encoding (SAME) used for the United States

27、National Oceanic and Atmospheric Administration (NOAA) weather radio and the emergency alert system (EAS), while offering enhanced capabilities that include: flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; multilingual and multi

28、-audience messaging; phased and delayed effective times and expirations; enhanced message update and cancellation features; template support for framing complete and effective warning messages; compatible with digital signature capability; and, facility for digital images and audio. CAP provides red

29、uction of costs and operational complexity by eliminating the need for multiple custom software interfaces to the many warning sources and dissemination systems involved in all-hazard warning. The CAP message format can be converted to and from the “native“ formats of all kinds of sensor and alertin

30、g technologies, forming a basis for a technology-independent national and international “warning Internet.“ CAP history The National Science and Technology Council (NSTC) report on “Effective Disaster Warnings“ released in November 2000 recommended that “a standard method should be developed to coll

31、ect and relay instantaneously and automatically all types of hazard warnings and reports locally, regionally and nationally for input into a wide variety of dissemination systems.“ An international working group of more than 130 emergency managers and information technology and telecommunications ex

32、perts convened in 2001 and adopted the specific recommendations of the NSTC report as a point of departure for the design of a common alerting protocol (CAP). Their draft went through several revisions and was tested in demonstrations and field trials in Virginia (supported by the ComCARE Alliance)

33、and in California (in cooperation with the California Office of Emergency Services) during 2002 and 2003. In 2002, the CAP initiative was endorsed by the national non-profit Partnership for Public Warning, which sponsored its contribution in 2003 to the OASIS standards process. In 2004, CAP version

34、1.0 was adopted as an OASIS standard. In 2005, changes based on user feedback were incorporated into CAP and version 1.1 was released. As part of the International Telecommunication Union (ITU-T) adoption of CAP, a CAP 1.1 Errata was released in 2007 to support ASN.1 encoding. Version 1.2 is a minor

35、 release to resolve issues identified by the EM-TC CAP Call for Comments initiated in April 2008 and also incorporates feedback from CAP profile development efforts. NOTE There are incompatible changes in the XML schema between CAP 1.1 and 1.2. Consequently, the ASN.1 module for CAP 1.2 as described

36、 in clause 8.3 is not compatible with that of CAP 1.1 Recommendation ITU-T X.1303 (2007). Rec. ITU-T X.1303 bis (03/2014) v Structure of the CAP alert message Each CAP alert message consists of an segment, which may contain one or more segments, each of which may include one or more and/or segments.

37、 Under most circumstances, CAP messages with a value of “Alert“ should include at least one element. (See the document object model diagram in clause 7.1, below). The segment provides basic information about the current message: its purpose, its source and its status, as well as a unique identifier

38、for the current message and links to any other, related messages. An segment may be used alone for message acknowledgements, cancellations or other system functions, but most segments will include at least one segment. The segment describes an anticipated or actual event in terms of its urgency (tim

39、e available to prepare), severity (intensity of impact) and certainty (confidence in the observation or prediction), as well as providing both categorical and textual descriptions of the subject event. It may also provide instructions for appropriate response by message recipients and various other

40、details (hazard duration, technical parameters, contact information, links to additional information sources, etc.). Multiple segments may be used to describe differing parameters (e.g., for different probability or intensity “bands“) or to provide the information in multiple languages. The segment

41、provides an optional reference to additional information related to the segment within which it appears in the form of a digital asset such as an image or audio file. The segment describes a geographic area to which the segment in which it appears applies. Textual and coded descriptions (such as pos

42、tal codes) are supported, but the preferred representations use geospatial shapes (polygons and circles) and an altitude or altitude range, expressed in standard latitude / longitude / altitude terms in accordance with a specified geospatial datum. Applications of the CAP alert message The primary u

43、se of the CAP alert message is to provide a single input to activate all kinds of alerting and public warning systems. This reduces the workload associated with using multiple warning systems while enhancing technical reliability and target-audience effectiveness. It also helps ensure consistency in

44、 the information transmitted over multiple delivery systems, another key to warning effectiveness. A secondary application of the CAP alert message is to normalize warnings from various sources so they can be aggregated and compared in tabular or graphic form as an aid to situational awareness and p

45、attern detection. Although primarily designed as an interoperability standard for use among warning systems and other emergency information systems, the CAP alert message can be delivered directly to alert recipients over various networks, including data broadcasts. Location-aware receiving devices

46、could use the information in a CAP alert message to determine, based on their current location, whether that particular message was relevant to their users. The CAP alert message can also be used by sensor systems as a format for reporting significant events to collection and analysis systems and ce

47、nters. Rec. ITU-T X.1303 bis (03/2014) 1 Recommendation ITU-T X.1303 bis Common alerting protocol (CAP 1.2) 1 Scope This Recommendation defines the common alerting protocol (CAP) version 1.2 which is a simple but general format for exchanging all-hazard emergency alerts and public warnings over all

48、kinds of networks. CAP allows a consistent warning message to be disseminated simultaneously over many different warning systems, thus increasing warning effectiveness while simplifying the warning task. CAP facilitates the detection of emerging patterns in local warnings of various kinds, such as t

49、hose that might indicate an undetected hazard or hostile act. CAP provides a template for effective warning messages based on best practices identified in academic research and real-world experience. CAP provides an open, non-proprietary digital message format for various types of alerts and notifications. CAP provides the following capabilities: flexible geographic targeting using latitude/longitude shapes and other geospatial representations in three dimensions; multilingual

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1