One document matched: draft-rosen-atoca-server-discovery-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC5031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
<!ENTITY RFC5222 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml">
<!ENTITY I-D.rosen-sipping-cap PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosen-sipping-cap.xml'>
<!ENTITY I-D.forte-ecrit-lost-extensions PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.forte-ecrit-lost-extensions.xml'>
<!ENTITY I-D.ietf-ecrit-phonebcp PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml'>
]>
<rfc category="std" docName="draft-rosen-atoca-server-discovery-00.txt" ipr="trust200902">
<front>
<title abbrev="Alert Server Discovery" >LoST-based Discovery of Servers Distributing Alerts</title>
<author initials="B." surname="Rosen" fullname="Brian Rosen">
<organization>NeuStar, Inc. </organization>
<address>
<postal>
<street>470 Conrad Dr</street>
<city>Mars</city>
<region> PA </region>
<code>16046 </code>
<country>US </country>
</postal>
<phone> </phone>
<email>br@brianrosen.net
</email>
</address>
</author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization abbrev="Columbia U.">Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<date year="2010"/>
<area>RAI</area>
<workgroup>ATOCA</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Early Warning URN</keyword>
<keyword>Server Discovery</keyword>
<keyword>LoST</keyword>
<abstract>
<t>The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency
alerts and public warnings. Different organizations issue alerts for specific geographic
regions. The Location-to-Service Translation (LoST) protocol provides a way to discover
servers that distribute these alerts for a geographical region. This document defines the
Service Uniform Resource Names (URN)s for warnings in the same way as they have been defined
with RFC 5031 for citizen-to-authority emergency services. Additionally, this document
suggests to use LoST for the discovery of servers distributing alerts. </t>
</abstract>
</front>
<middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="introduction" title="Introduction">
<t>The Common Alerting Protocol (CAP) is an XML document format for exchanging emergency
alerts and public warnings. Different organizations issue alerts for specific geographical
regions. The Location-to-Service Translation (LoST) protocol provides a way to discover
servers that distribute these alerts for a geographical region. This document defines the
Service Uniform Resource Names (URN)s for warnings in the same way as they have been defined
with RFC 5031 for citizen-to-authority emergency services. Additionally, this document
suggests to use LoST for the discovery of servers distributing alerts. </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="terminology" title="Terminology">
<t>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
RFC 2119 <xref target="RFC2119"/>.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Protocol Semantics">
<t>This document makes use of LoST, RFC 5222 <xref target="RFC5222"/>. However, instead of
performing a translation from location information and a Service URN to a PSAP URI (plus
supplementary information), as used with <xref target="I-D.ietf-ecrit-phonebcp"/> for the
citizen-to-authority emergency services use case, the LoST client asks the LoST server for a
URI to receive further information on how to obtain warning alerts. In a response the URIs
in the <uri> element MUST be from the following format: sip, xmpp or http. The
SIP URI MUST subsequently be used with <xref target="I-D.rosen-sipping-cap"/>. An XMPP URI
MUST be used as described in <xref target="XEP-0127"/>. An HTTP URI MUST be used with GeoRSS
([Reference to be added.]). </t>
<t>In a LoST response the optional <serviceNumber> element is not used by this
specification. In mapping citizen-to-authority services, receiving multiple mappings is an
exception. However, since many organizations may provide warnings for the same area, this is
likely to be more common for alerts. As such, the extensions defined in <xref
target="I-D.forte-ecrit-lost-extensions"/> (e.g., the ability to limit the number of
returned mappings) are useful in this context. </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="example" title="Examples">
<t><xref target="example1"/> shows a regular LoST query including geodetic location
information with the Service URN pointing to 'urn:service:warning'. The semantic of the
query is: "I am at location (point,"37.775 -122.422"). Please give me a URI where I can
obtain information for warnings under the category 'urn:service:warning'. <figure
anchor="example1" title="A <findService> geodetic query">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findService
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
serviceBoundary="value"
recursive="true">
<location id="6020688f1ce1896d" profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>37.775 -122.422</p2:pos>
</p2:Point>
</location>
<service>urn:service:warning</service>
</findService>
]]></artwork>
</figure>
</t>
<t>In response to the query in <xref target="example1"/> the LoST server returns a regular
LoST response, as shown in <xref target="example2"/>. The returned mapping information
indicates that the URIs (sip:alerts@example.com and xmpp:alerts@example.com) can be
contacted to subscribe to warning events. The service boundary indicates that subsequent
requests to the same service will lead to the same response for the geodetic region
indicated by the polygon in the <serviceBoundary> element. <figure
anchor="example2" title="A <findServiceResponse> geodetic answer">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml">
<mapping
expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z"
source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66">
<displayName xml:lang="en">
Austrian Early Warning Center
</displayName>
<service>urn:service:warning</service>
<serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:alerts@example.com</uri>
<uri>xmpp:alerts@example.com</uri>
</mapping>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="6020688f1ce1896d"/>
</findServiceResponse>
]]></artwork>
</figure>
</t>
<t><xref target="example3"/> shows a <ListServicesByLocation> query asking for
the services that are available at a given location; in this example at a point (-34.407
150.883). <figure anchor="example3"
title="Example of <ListServicesByLocation> query">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocation
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"
recursive="true">
<location id="3e19dfb3b9828c3" profile="geodetic-2d">
<p2:Point srsName="urn:ogc:def:crs:EPSG::4326">
<p2:pos>-34.407 150.883</p2:pos>
</p2:Point>
</location>
<service>urn:service:warning</service>
</listServicesByLocation>
]]></artwork>
</figure>
</t>
<t>
<xref target="example4"/> lists a possible response to the
<ListServicesByLocation> query with 6 subservices being offered for the
indicated geographical region. <figure anchor="example4"
title="Example of <listServicesByLocationResponse>">
<artwork>
<![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<listServicesByLocationResponse
xmlns="urn:ietf:params:xml:ns:lost1">
<serviceList>
urn:service:warning.geo
urn:service:warning.met
urn:service:warning.safety
urn:service:warning.security
urn:service:warning.rescue
urn:service:warning.fire
</serviceList>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
<locationUsed id="3e19dfb3b9828c3"/>
</listServicesByLocationResponse>
]]></artwork>
</figure>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="sec-cons" title="Security Considerations">
<t>The security considerations of RFC 5031 <xref target="RFC5031"/>, RFC 5222 <xref
target="RFC5222"/> and <xref target="I-D.rosen-sipping-cap"/> are relevant to this
document. This document does not introduce new security vulnerabilities. </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="IANA Considerations">
<section title="Sub-Services for the 'warning' Service">
<t> This section defines the service registration within the IANA registry defined in
Section 4.1 of <xref target="RFC5031"/>, using the top-level service label 'warning'. </t>
<t>The 'warning' service type describes services providing public safety alerts, i.e.,
alerts that can warn members of the public about dangers to life, health and property.
Additional sub-services can be added after expert review and must be of general public
interest and have a similar emergency nature. The expert is designated by the ECRIT
working group, its successor, or, in their absence, the IESG. The expert review should
only approve early warning based emergency services that are offered widely and in
different countries, with approximately the same caller expectation in terms of services
rendered. The 'warning' service is not meant to be used by non-emergency services related
information. </t>
<t>The warning classification (including description) in the list below is taken from the
CAP specification <xref target="cap"/>:</t>
<t>
<list style="hanging">
<t hangText="'urn:service:warning':"> The generic 'warning' service denotes a generic
early warning message of any type encompassing all of the services listed
below.<vspace blankLines="1"/>
</t>
<t hangText="'urn:service:warning:geo':"> Geophysical (inc. landslide)<vspace
blankLines="1"/></t>
<t hangText="'urn:service:warning:met':"> Meteorological (inc. flood)<vspace
blankLines="1"/></t>
<t hangText="'urn:service:warning:safety':"> General emergency and public safety<vspace
blankLines="1"/></t>
<t hangText="'urn:service:warning:security':"> Law enforcement, military, homeland and
local/private security <vspace blankLines="1"/></t>
<t hangText="'urn:service:warning:rescue':"> Rescue and recovery<vspace blankLines="1"/></t>
<t hangText="'urn:service:warning:fire':"> Fire suppression and rescue<vspace
blankLines="1"/></t>
<t hangText="'urn:service:warning:health':"> Medical and public health<vspace
blankLines="1"/></t>
<t hangText="'urn:service:warning:env':"> Pollution and other environmental<vspace
blankLines="1"/></t>
<t hangText="'urn:service:warning:transport':"> Public and private transportation<vspace
blankLines="1"/></t>
<t hangText="'urn:service:warning:infra':"> Utility, telecommunication, other
non-transport infrastructure<vspace blankLines="1"/></t>
<t hangText="'urn:service:warning:cbrne':"> Chemical, Biological, Radiological, Nuclear
or High-Yield Explosive threat or attack</t>
</list>
</t>
</section>
<section title="Initial IANA Registration">
<t> The following table contains the initial IANA registration for early warning services.</t>
<t>
<figure>
<artwork xml:space="preserve">
<![CDATA[
Service Reference Description
------------------------------------------------------------------------
warning RFC TBD Early Warning Services
warning.geo RFC TBD Geophysical (inc. landslide)
warning.met RFC TBD Meteorological (inc. flood)
warning.safety RFC TBD General emergency and public safety
warning.security RFC TBD Law enforcement, military,
homeland and local/private security
warning.rescue RFC TBD Rescue and recovery
warning.fire RFC TBD Fire suppression and rescue
warning.health RFC TBD Medical and public health
warning.env RFC TBD Pollution and other environmental
warning.transport RFC TBD Public and private transportation
warning.infra RFC TBD Utility, telecommunication, other
non-transport infrastructure
warning.cbrne RFC TBD Chemical, Biological,
Radiological, Nuclear or High-Yield
Explosive threat or attack
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Acknowledgments">
<t>We would also like to thank the participants of the Early Warning Adhoc meeting at
IETF#69.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
</middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997"/>
</front>
<format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt" type="TXT"/>
</reference>
<reference anchor="cap">
<front>
<title>Common Alerting Protocol v. 1.1 </title>
<author fullname="Elysa Jones" initials="E." surname="Jones">
<organization>Warning Systems, Inc</organization>
</author>
<author fullname="Art Botterell" initials="A." surname="Botterell">
<organization>Individual</organization>
</author>
<date month="October" year="2005"/>
</front>
<format
target="http://www.oasis-open.org/apps/org/workgroup/emergency/download.php/14205/emergency-CAPv1.1-Committee%20Specification.pdf"
type="PDF"/>
</reference> &I-D.ietf-geopriv-pdif-lo-profile; &RFC5222; &I-D.rosen-sipping-cap;
&RFC5031; </references>
<references title="Informative References">
<reference anchor="XEP-0127">
<front>
<title>Common Alerting Protocol (CAP) Over XMPP</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="B." surname="Fletcher" fullname="Boyd Fletcher">
<organization/>
<address>
<email>Boyd.Fletcher@je.jfcom.mil</email>
</address>
</author>
<date day="09" month="December" year="2004"/>
</front>
<seriesInfo name="XSF XEP" value="0127"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0127.html"/>
</reference> &I-D.forte-ecrit-lost-extensions; &I-D.ietf-ecrit-phonebcp; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-21 00:13:32 |