[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Information on IETF Emergency Management standards and realted activities
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]