Dear EM TC -
This is a longish informational email.
At the last Geo/GIS Subcommittee meeting, we discussed my providing
information about IETF standards related activities of importance to the
EM and Alerting communities. To this list of information, I am also adding
some NENA NG 911 information and some very recent OGC warning and alerting
related information.
First, the IETF. The Internet Engineering Task Force (IETF) is a large
open international community of network designers, operators, vendors, and
researchers concerned with the evolution of the Internet architecture and
the smooth operation of the Internet.
For the last six years, the IETF (Internet Engineering Task Force) has had
a very active Working Group titled GeoPRIV. The WG name is a bit
misleading as the majority of the work is being driven by EM use cases and
has a very strong geo. The charter for the GeoPRIV WG is here:
http://www.ietf.org/dyn/wg/charter/geopriv-charter.html . I have been
involved with the IETF since 2005. When considering the work of the
GeoPRIV WG, one must think about the membership of the group: Most are
internet or mobile telecommunications infrastructure folks. Companies such
as Southern Bell, CISCO, BBN, AT&T, Motorola, Andrews corp and so forth.
These are the companies that implement and support the infrastructure of
the internet and our telecommunications backbone.
So, the GeoPRIV WG has proposed and had accepted a number of what are now
internet RFCs (standards). These are listed at the bottom of the GeoPRIV
charter page. The important ones include:
1. Dynamic Host Configuration Protocol Option for Coordinate-based
Location Configuration Information (RFC 3825) (In revision)
2. A Presence-based GEOPRIV Location Object Format RFC 4119.
http://tools.ietf.org/html/rfc4119
3. Revised Civic Location Format for Presence Information Data Format
Location Object (PIDF-LO) (RFC 5139). http://tools.ietf.org/html/rfc5139
4. GEOPRIV Presence Information Data Format Location Object (PIDF-LO)
Usage Clarification, Considerations, and Recommendations (RFC 5491).
http://tools.ietf.org/html/rfc5491
Now, look more closely at LO - Location Object. The LO is a payload
encoding. There are two sub-types for the LO: Civic and Geodetic. Civic is
typically an address. Geodetic are what we would think of as geometries
(coordinates). The Civic elements have been discussed and harmonized (some
work in progress) with the work in NENA as to the elements required. The
geodetic expression of the payload is a GML application schema. The actual
document describing the schema and the .xsd's are an OGC Best Practice
document that was submitted by the IETF to the OGC. The OGC document is
titled GML PIDF-LO Geometry Shape Application Schema for use in the IETF
and can be found here
http://portal.opengeospatial.org/files/?artifact_id=21630.
The LO has been proposed and is also now part (by extension) of several
other internet standards:
RADIUS - Remote Authentication Dial-In User Service
DIAMETER - Diameter is a computer networking protocol for AAA
(authentication, authorization and accounting).
SIP - Session Initiation Protocol.
The RADIUS and DIAMETER guidance is in Carrying Location Objects in RADIUS
and Diameter [RFC 5580] http://www.ietf.org/rfc/rfc5580.txt . Some
information on location and SIP is here:
http://www.faqs.org/rfcs/rfc5606.html . More aspect of location and SIP
are being worked. There are also issues related to harmonization with
XMPP.
Why is all of this important? For one, much of the information that could
end up in a CAP of EDXL message will comes from the current 911 and in the
future NG 911 implementation. The NENA NG 911 Working Groups have already
approved PIDF-LO (and the GML application schema) as mandatory must
implement. NENA NG WGs have also defined and approved a GIS Data Model
(for sharing GIS content between and among PSAPS and local governements
and so forth). GML is the encoding language for the GIS Data Model.
This all has implications for where location and related data elements
will be provided from and provided to organizations that will be
generating CAP and EDXL messages.
Now (and getting near the end of this email), the OGC has had and
continues to have considerable activity in the EM warning and alerting
domain. The OGC currently is working OGC Web Services 7.0 test bed. In
that test bed, there is an alerting/warning thread. OWS-7 is doing a lot
of testing related to alert notification capabilities. They are currently
looking at a new service tentatively titled SES (Sensor Event Service)
http://portal.opengeospatial.org/files/?artifact_id=29576 (earlier
discussion paper) which is being enhanced to output the alert in several
different formats: CAP, ATOM, and I believe GeoRSS/ATOM. I believe the
Sensor part of the Event Service is a misnomer as this service will not be
tied to only Sensor Webs so I think the name will change eventually. As I
understand it SES is a method of delivery of the message (email, Short
Message Service (SMS), Instant Messaging (IM), automated phone calls or
faxes) as such is more of a message transport service.
Now, finally, the OASIS "where" activity, GeoRSS GML, and the GML
application schema for LO are all consistent! This is because they are
all (or will be) based on the same information model. This definitely
makes mapping much easier!
That's it for now. Any questions, please let me know.
Cheers
Carl