idnits 2.17.1 draft-barnes-atoca-cap-mime-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 7, 2011) is 4582 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'CAP' ** Obsolete normative reference: RFC 3023 (Obsoleted by RFC 7303) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft BBN Technologies 4 Intended status: Standards Track B. Rosen 5 Expires: April 9, 2012 Neustar 6 H. Tschofenig 7 Nokia Siemens Networks 8 October 7, 2011 10 Media Type Registration for Common Alerting Protocol 11 draft-barnes-atoca-cap-mime-01 13 Abstract 15 This document registers the media type "application/cap+xml" for 16 Common Alerting Protocol (CAP) format . 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 9, 2012. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 60 2.1. Registration of the 61 'application/common-alerting-protocol+xml' media type . . . 4 62 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 63 4. Normative References . . . . . . . . . . . . . . . . . . . . . 6 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 The Common Alerting Protocol (CAP) [CAP] is an XML document format 69 for exchanging emergency alerts and public warnings. This document 70 registers a media type for CAP documents. The full specification for 71 CAP can be found at the following URL: 73 76 The following is an example of a CAP message for a severe 77 thunderstorm warning: 79 81 82 KSTO1055887203 83 KSTO@NWS.NOAA.GOV 84 2003-06-17T14:57:00-07:00 85 Actual 86 Alert 87 Public 88 89 Met 90 SEVERE THUNDERSTORM 91 Severe 92 Likely 93 NATIONAL WEATHER SERVICE SACRAMENTO 94 SEVERE THUNDERSTORM WARNING 95 AT 254 PM PDT... 96 NATIONAL WEATHER SERVICE 97 DOPPLER RADAR INDICATED A SEVERE 98 THUNDERSTORM OVER SOUTH CENTRAL ALPINE COUNTY... 99 OR ABOUT 18 MILES SOUTHEAST OF 100 KIRKWOOD... MOVING SOUTHWEST AT 5 MPH. HAIL... 101 INTENSE RAIN AND STRONG DAMAGING WINDS 102 ARE LIKELY WITH THIS STORM 103 TAKE COVER IN A SUBSTANTIAL SHELTER 104 UNTIL THE STORM PASSES 105 BARUFFALDI/JUSKIE 106 107 EXTREME NORTH CENTRAL TUOLUMNE COUNTY 108 IN CALIFORNIA, EXTREME NORTHEASTERN 109 CALAVERAS COUNTY IN CALIFORNIA, SOUTHWESTERN 110 ALPINE COUNTY IN CALIFORNIA 111 38.47,-120.14 38.34,-119.95 38.52,-119.74 112 38.62,-119.89 38.47,-120.14 113 114 115 117 2. IANA Considerations 119 2.1. Registration of the 'application/common-alerting-protocol+xml' 120 media type 122 To: ietf-types@iana.org 124 Subject: Registration of media type application/cap+xml 126 Type name: application 128 Subtype name: cap+xml 130 Required parameters: (none) 132 Optional parameters: charset; Indicates the character encoding of 133 the enclosed XML. Default is UTF-8 [RFC3629]. 135 Encoding considerations: Uses XML, which can employ 8-bit 136 characters, depending on the character encoding used. See RFC 137 3023 [RFC3023], Section 3.2. 139 Security considerations: Transmission of CAP payloads does not 140 introduce new security risks 142 Interoperability considerations: CAP is widely used for emergency 143 management. 145 Published specification: RFC XXXX [Replace by the RFC number of 146 this specification]. 148 Applications which use this media type: Applications that convey 149 alerts and early warnings according to the CAP standard. 151 Additional information: 153 Magic number: (none) 155 File extension: .cap 157 Macintosh file type code: 'TEXT' 159 Person & email address to contact for further information: Hannes 160 Tschofenig, hannes.tschofenig@nsn.com 162 Intended usage: Limited use 164 Restrictions on usage: (none) 166 Author: The CAP format was originally standardized by OASIS [CAP]. 167 This document was developed by the IETF ATOCA working group. 169 Change controller: The IESG 171 Other information: This media type is a specialization of 172 application/xml [RFC3023], and many of the considerations 173 described there also apply to application/cap+xml. 175 3. Security Considerations 177 The introduction of the CAP MIME type does not present any new risks 178 in itself. CAP messages are used to encode emergency alerts, which 179 means that false CAP messages can have significant negative effects, 180 such as the unnecessary evacuation of an area. Systems that process 181 CAP messages will need to have mechanisms for integrity protection 182 and origin authentication, in order to ensure either that end alert 183 recipients do not receive false alerts or that they can distinguish 184 valid alerts from false alerts. 186 4. Normative References 188 [CAP] Botterell, A. and E. Jones, "Common Alerting Protocol 189 v1.1", October 2005. 191 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 192 Requirement Levels", BCP 14, RFC 2119, March 1997. 194 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 195 Types", RFC 3023, January 2001. 197 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 198 10646", STD 63, RFC 3629, November 2003. 200 Authors' Addresses 202 Richard Barnes 203 BBN Technologies 204 1300 N 17th St 205 Arlington, VA 22209 206 US 208 Email: rbarnes@bbn.com 209 Brian Rosen 210 Neustar 211 470 Conrad Dr. 212 Mars, PA 16046 213 US 215 Email: br@brianrosen.net 217 Hannes Tschofenig 218 Nokia Siemens Networks 219 Linnoitustie 6 220 Espoo 02600 221 Finland 223 Phone: +358 (50) 4871445 224 Email: Hannes.Tschofenig@gmx.net