EU Emergency Services Workshop 2013

Die Präsentationen des EU Emergency Services Workshop 2013 (veranstaltet von der EENA) sind jetzt abrufbar: http://www.eena.org/view/en/112events/Workshops/2013.html

EU-Report über Implementierung von 112

Die EU hat einen neuen Report über den Implementerungs-Status von 112 veröffentlich. Dieser Report basiert auf einer Umfrage unter den Mitgliedsstaaten.
Der Report ist unter http://ec.europa.eu/information_society/newsroom/cf/dae/itemdetail.cfm?item_id=9624 abrufbar.

“PhoneBCP” als RFC 6881 veröffentlicht

Endlich ist auch der als PhoneBCP bekannte Internet Draft als RFC veröffentlich worden, abrufbar unter http://tools.ietf.org/html/rfc6881.

ISCRAM 2013 Konferenz

Die diesjährige ISCRAM (Information Systems for Crisis Response and Management) Konferenz findet von 12-15.5.2013 in Baden-Baden statt. Das vorläufige Programm ist bereits auf der Konferenzwebseite verfügbar.

Konferenzwebseite: http://www.iscram2013.org/

Mailingliste: http://iscram.org/pipermail/iscramlist_iscram.org/

W3C Emergency Information Community Group

Die W3C hat eine “Emergency Information Community Group” gestartet. Weitere Infos dazu sind unter http://www.w3.org/community/emergency/ zu finden.

LoST-Synchronisation als RFC 6739 veröffentlicht

Die IETF hat den LoST-Synchroinsationsmechanismus publiziert: Synchronizing Service Boundaries and
Elements Based on the Location-to-Service Translation (LoST) Protocol http://tools.ietf.org/html/rfc6739

Es wird dabei die Service Boundary basierend auf dem LoST Protokoll synchronisiert. Es sind dabei die beiden Einsatzzwecke genau zu unterscheiden: einerseits können Forest Guides (auf der gleichen hierarchischen Ebene) Daten synchronisieren. Das zweite Anwendungsgebiet ist der Austausch der Zuständigkeitsgebiete zB zwischen Forest Guide und LoST Mapping Servern oder auch zwischen LoST Mapping Servern untereinander.

Jedenfalls ist RFC 6739 ein wichtiger Bestandteil um die LoST Architektur erfolgreich umsetzen zu können.

IETF Notrufframework als RFC 6443 veröffentlicht

Die IETF Notrufarchitektur wurde nun von der IETF als RFC 6443 publiziert (Framework for Emergency Calling Using Internet Multimedia): http://tools.ietf.org/html/rfc6443

In diesem Dokument ist die Architektur für Notrufe über das Internet von der IETF beschrieben und ist ein wichtiger Meilenstein in der Standardisierung. Ausständig ist weiterhin noch das Dokument phoneBCP (http://tools.ietf.org/html/draft-ietf-ecrit-phonebcp-20).

Neuer RFC für “geodetic” Standortinformation per DHCP

RFC 3825 wurde mit der Veröffentlichung von RFC 6225 für obsolet erklärt. Der neue RFC für die Konfiguration von “geodetic” Standortinformation (also mit Hilfe von Koordinaten) ist unter der folgenden Adresse aufrufbar:

http://www.rfc-editor.org/rfc/rfc6225.txt

Die DHCP Option für “civic” Standortinformation bleibt unverändert.

NG911 Architektur von NENA verabschiedet

Die Nordamerikanische Notruforganisation NENA hat am 16. Juni offiziell ihre “Next Generation 911 Architektur” verabschiedet: die technische Architektur sowie die Komponenten des zukünftigen Notrufsystems in Nordamerika sind somit festgelegt und werden auch die Abwicklung von VoIP-basierten Notrufen erlauben. Die NENA Architektur (i3) basiert auf dem Notrufframework der IETF und spezifiziert darüber hinaus wichtige Elemente für sogenannte IP-basierte Emergency Service Networks.

Mehr Information sind in der Aussendung der NENA zu finden: http://www.nena.org/stories/technical/executive-board-approves-i3-standard

Die NG911 Architektur, bekannt unter dem Namen i3, ist unter http://www.nena.org/standards/technical/i3-solution abrufbar.

“Service List Boundary” für LoST als RFC 6197 veröffentlicht

Eine Erweiterung für das LoST Protokoll wurde heute von der IETF als RFC 6197 publiziert: die Service List Boundary. LoST (RFC 5222) bietet die Möglichkeit, eine Service Liste für einen bestimmten Standort abzufragen, gibt dem Client aber keinen Hinweis, für welches Gebiet diese spezielle Service Liste gültig ist. Daher könnte es passieren, daß ein sich bewegender Client eine Änderung der Service Liste nicht bemerkt. Die im RFC 6197 beschriebene Service List Boundary schafft hier Abhilfe: der Server kann eine Boundary zurückliefern, für welche die Service List gültig ist. Bewegt sich der Client außerhalb dieser Boundary, muß eine neue Service Liste vom Server angefordert werden. Damit ist sichergestellt, daß ein Client Änderungen der Servcie List bemerkt und dem Nutzer somit immer alle verfügbaren Service Nummern (insbesondere Notrufnummern) zur Verfügung stehen.

http://www.rfc-editor.org/rfc/rfc6197.txt