Internet DRAFT - draft-ietf-atoca-requirements
draft-ietf-atoca-requirements
ATOCA H. Schulzrinne
Internet-Draft Columbia University
Intended status: Informational S. Norreys
Expires: September 13, 2012 BT Group
B. Rosen
NeuStar, Inc.
H. Tschofenig
Nokia Siemens Networks
March 12, 2012
Requirements, Terminology and Framework for Exigent Communications
draft-ietf-atoca-requirements-03.txt
Abstract
Before, during and after emergency situations various agencies need
to provide information to a group of persons or to the public within
a geographical area. While many aspects of such systems are specific
to national or local jurisdictions, emergencies span such boundaries
and notifications need to reach visitors from other jurisdictions.
This document provides terminology, requirements and an architectural
description for protocols exchanging alerts between IP-based end
points.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 13, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Schulzrinne, et al. Expires September 13, 2012 [Page 1]
Internet-Draft Exigent Communications March 2012
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Classical Early Warning Situations . . . . . . . . . . . . 3
1.2. Exigent Communications . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Originator . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Gateway . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.4. Receiver . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Small Group Alert Delivery . . . . . . . . . . . . . . . . 8
3.2. Mass Alert Delivery . . . . . . . . . . . . . . . . . . . 8
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Requirements for the Discovery of an Alert
Distribution Server . . . . . . . . . . . . . . . . . . . 10
4.2. Requirements for Multicast/Broadcast Alert Message
Delivery . . . . . . . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Supplementary Requirements . . . . . . . . . . . . . 14
A.1. Requirements for Alert Subscription . . . . . . . . . . . 14
A.2. Point-to-Point Alert Delivery . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Schulzrinne, et al. Expires September 13, 2012 [Page 2]
Internet-Draft Exigent Communications March 2012
1. Introduction
1.1. Classical Early Warning Situations
During large-scale emergencies, public safety authorities need to
reliably communicate with citizens in the affected areas, to provide
warnings, indicate whether citizens should evacuate and how, and to
dispel misinformation. Accurate information can reduce the impact of
such emergencies.
Traditionally, emergency alerting has used church bells, sirens,
loudspeakers, radio and television to warn citizens and to provide
information. However, techniques, such as sirens and bells, provide
limited information content; loud speakers cover only very small
areas and are often hard to understand, even for those not hearing
impaired or fluent in the local language. Radio and television offer
larger information volume, but are hard to target geographically and
do not work well to address the "walking wounded" or other
pedestrians. Both are not suitable for warnings, as many of those
needing the information will not be listening or watching at any
given time, particularly during work/school and sleep hours.
This problem has been illustrated by the London underground bombing
on July 7, 2006, as described in a government report [July2005]. The
UK authorities could only use broadcast media and could not, for
example, easily announce to the "walking wounded" where to assemble.
1.2. Exigent Communications
With the usage of the term 'Exigent Communications' this document
aims to generalize the concept of conveying alerts to IP-based
systems and at the same time to describe the actors that participate
in the messaging communication. More precisely, exigent
communications is defined as:
Communication that requirs immediate action or remedy.
Information about the reason for action and details about the
steps that have to be taken are provided in the alert message.
An alert message (or warning message) is a cautionary advice about
something imminent (especially imminent danger or other
unpleasantness). In the context of exigent communication such an
alert message refers to a future, ongoing or past event as the
signaling exchange itself may relate to different stages of the
lifecycle of the event. The alert message itself, and not the
signaling protocol that convey it, provides sufficient context
about the specific state of the lifecycle the alert message refers
to.
Schulzrinne, et al. Expires September 13, 2012 [Page 3]
Internet-Draft Exigent Communications March 2012
On a high level the communication occurs in two phases with the
subscription phase sometimes being implicit:
Subscription:
In this step Recipients express their interest in receiving
certain types of alerts. This step happens prior to the actual
delivery of the alert. This expression of interest may be in form
of an explicit communication step by having the Receiver send a
subscribe message (potentially with an indication of the type of
alerts they are interested in, the duration of the subscription
and a number of other indicators). For example, parents may want
to be alerted of emergencies affecting the school attended by
their children and adult children may need to know about
emergencies affecting elderly parents. The subscription step may,
however, also happen outside the Internet communication
infrastructure and instead by the Recipient signing a contract and
thereby agreeing to receive certain alerts. The Receiver, a
software application, still needs to be configured in such a way
that incoming alerts are accepted, processed and passed up to the
user interface alerting a Recipient. Additionally, certain
subscriptions may happen without the Recipient's explicit consent
and without the Receiver sending a subscription. For example, a
Tsunami flood alert may be delivered to all Receivers in case they
are located in a specific geographical area.
It is important to note that a protocol interaction initiated by
the Receiver may need to take place to subscribe to certain types
of alerts. In some other cases the subscription does not require
such interaction from the Receiver. Orthogonal to the need to
have a protocol interaction is the question of opt-in vs. opt-out.
Whether the Recipient, as a human actor, needs to consent to
receive certain types of alerts is a policy decision that is
largely outside the scope of a technical specification.
Alert Delivery:
In this step the alert message is distributed to one or multiple
Receivers. The Receiver as a software module that presents the
alert message to the Recipient. The alert encoding is
accomplished via the Common Alerting Protocol (CAP) and such an
alert message contains useful information needed for dealing with
the imminent danger.
Note that an alert receiver software modules may not necessarily only
be executed on end devices humans typically carry around, such as
mobile phones, Internet tablets, or laptops. Instead, alerts may
well be directly sent to displays in subway stations, or electronic
Schulzrinne, et al. Expires September 13, 2012 [Page 4]
Internet-Draft Exigent Communications March 2012
bill boards. Furthermore, a software module that obtains an alert
may not necessarily need to interact with a human (as the Recipient)
but may instead use it as input to another process to trigger
automated behaviors, such as closing vents during a chemical spill or
activating sirens or other warning systems in commercial buildings.
This document provides terminology, requirements and an architectural
description. Note that the requirements focus on the communication
protocols for subscription and alert delivery rather than on the
content of the alert message itself. With the usage of CAP these
alert message content requirements are delegated to the Authors and
Originators of alerts.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119], with the
important qualification that, unless otherwise stated, these terms
apply to the design of a protocol conveying warning messages, not its
implementation or application.
Alert messages are typically produced by humans and consumed by
users, Authors and Recipients in our system, are the sources and
sinks of alert messages.
The Author is a human responsible for creating the content of the
alert message, and to make a decision about the intended recipients,
even though the exact list of recipients may be unknown to the Author
at the time of writing the alert message. Instead, the recipients
may, for example, be described in terms of a geographical region, or
recipients with interest in a specific alert type.
The Recipient is a consumer of the delivered alert message. It is a
human reading the alert message.
From the user's perspective, all alert message transfer activities
are performed by a monolithic Message Handling Service (MHS), even
though the actual service can be provided by many independent
organizations. The Message Handling Service (MHS) performs a single
end-to-end transfer of warning messages on behalf of the Author to
reach the Recipients.
Figure 1 shows the relationships among transfer participants.
Transfers typically entail one or more Relays. However, direct
delivery from the Originator to Receiver is possible.
Schulzrinne, et al. Expires September 13, 2012 [Page 5]
Internet-Draft Exigent Communications March 2012
++==========++ ++===========++
|| Author || || Recipient ||
++====++====++ ++===========++
|| /\
|| ||
\/ ||
+----------+ +---++----+
| | | |
/-+----------+----------------------------+---------+---\
| | | Message Handling | | |
| |Originator| System (MHS) |Receiver | |
| | | | | |
| +---++-----+ +---------+ |
| || /\ |
| || || |
| \/ || |
| +---------+ +---------+ +-+--++---+ |
| | Relay +======-=>| Relay +=======>| Relay | |
| +---------+ +----++---+ +---------+ |
| || |
| || |
| \/ |
| +---------+ |
| | Gateway +--> |
| +---------+ |
\-------------------------------------------------------/
Legend: === and || lines indicate primary (possibly
indirect) transfers or roles
Figure 1: Relationships Among MHS Actors
2.1. Originator
The Originator ensures that a warning message is valid for transfer
and then submits it to a Relay. A message is valid if it conforms to
both communication and warning message encapsulation standards and
local operational policies. The Originator can simply review the
message for conformance and reject it if it finds errors, or it can
create some or all of the necessary information.
The Originator serves the Author and can be the same entity in
absence of a human crafting alert messages.
The Originator also performs any post-submission, Author-related
administrative tasks associated with message transfer and delivery.
Notably, these tasks pertain to sending error and delivery notices,
and enforcing local policies. The Author creates the message, but
Schulzrinne, et al. Expires September 13, 2012 [Page 6]
Internet-Draft Exigent Communications March 2012
the Originator handles any transmission issues with it.
2.2. Relay
The Relay performs MHS-level transfer-service routing and store-and-
forward, by transmitting or retransmitting the message to its
Recipients. The Relay may add history information (e.g., the SIP
History Info [RFC4244] serves as a good example of the type of
information that may be conveyed) or security related protection
(e.g., as available with SIP Identity [RFC4474]) but does not modify
the envelope information or the message content semantics.
A Message Handling System (MHS) network consists of a set of Relays.
This MHS network is typically above any underlying IP network but may
involve technologies like IP multicast.
2.3. Gateway
A Gateway connects heterogeneous communication infrastructures and
its purpose is to emulate a Relay and the closer it comes to this,
the better. A Gateway needs the ability to modify message content.
Differences between the different communication systems can be as
small as minor syntax variations, but they usually encompass
significant, semantic distinctions. Hence, the Relay function in a
Gateway presents a significant design challenge, if the resulting
performance is to be seen as nearly seamless. The challenge is to
ensure end-to-end communication between the communication services,
despite differences in their syntax and semantics.
2.4. Receiver
The Receiver performs final delivery and is typically responsible for
ensuring that the appropriate user interface rendering is executed to
interact with the Recipient.
3. Framework
Section 1 describes the basic two steps that are involved with the
alert message handling, namely subscription and alert delivery. From
an architectural point of view there are, however, a few variations
possible depending on the characteristics of the subscription process
and the style of message delivery. This section offers more details
on the communication architecture. Note that this document does not
mandate a specific deployment architecture. Instead it aims to
illustrate how various different protocol components fit together to
present the reader with the 'big picture'.
Schulzrinne, et al. Expires September 13, 2012 [Page 7]
Internet-Draft Exigent Communications March 2012
3.1. Small Group Alert Delivery
We start our description with the so-called "school closed" example
where school authorities send alerts to all parents to notify them
about the fact that their children cannot attend school. Parents
subscribe to these events when their children start attending the
school and unsubscribe when they are finished with a particular
school. The subscription procedures establishes some form of group
communication by requiring an initial registration procedure.
Typically, alert messages stay within the closed group and are not
shared with others and alert message delivery is point-to-point with
whatever communication protocol is most suitable. This also means
that the alerts reach those who have subscribed rather than those who
are in the vicinity of the school. The number of Recipients is
typically rather small, in the order of hundreds to several
thousands.
A variation of the "school closed" example is an explicit
subscription model where no closed group pattern exists. The main
difference to the former case is in the authorization model.
Consider a traveler who would like to receive weather alerts about a
specific geographical region. He may have to manually search for how
to subscribe to alerts for the desired region, potentially looking a
different subscription points for different types of alerts. As an
automated version of this procedure some form of discovery may help
to find these subscription servers. The approach described in
[I-D.rosen-ecrit-lost-early-warning] is one possible way to discovery
such alert subscription servers. The number of alert message
Recipients is much larger than in the previous school example but
will typically stay below the millions.
These alert delivery examples are supported by a number of
standardized communication protocols, such as SIP, XMPP, eMail, or
RSS feeds.
Note that there are optimizations for application layer alert
delivery that mimic a multicast delivery with the help of Relays.
However, a subscription is still necessary by the Receiver and the
last-hop delivery of the alert is still done using unicast
transmission.
While these two examples are important for many deployments they are
not in focus of the ATOCA working group.
3.2. Mass Alert Delivery
With the next category we move to a scenario where large number of
Recipients shall be notified but the subscription itself is implicit,
Schulzrinne, et al. Expires September 13, 2012 [Page 8]
Internet-Draft Exigent Communications March 2012
as it is the case when persons are within a specific region that can
easily be reached by making use of broadcast link layer technologies.
The placement of the actors from Figure 1 is thereby important. An
Originator distributes the alert message to Relays within the
geographically affected area. Those Relays are located within
Internet Service Providers so that multicast and broadcast
communication protocols can be utilized for efficient distribution to
a large number of Recipients within the affected area. When the
alert message delivery has to be accomplished at the network layer
then various requirements, such as the ability to traverse NATs and
firewalls, have to be met by such a protocol. In this scenario the
number of alert message Recipients is very large, potentially in the
millions.
As a variation of the previously described model consider an alert
distribution with subscriptions to the alerts. Figure 2 shows the
architecture.
A discovery server ensures that Receivers are able to learn the local
alert distribution servers. Once a Receiver had discovered a local
alert distribution server it sends a subscribe message to it. As a
response, it will receive information about the security credentials
the alert distribution server is going to use for subsequent alert
delivery.
When an Author creates an alert for distribution the affected region
will be indicated and so the alert will be sent to a Relay within the
realm of the local alert distribution server and a notification will
be sent to all the subscribed Receivers.
Schulzrinne, et al. Expires September 13, 2012 [Page 9]
Internet-Draft Exigent Communications March 2012
,-----------.
| Discovery |
| Server |
`...........'
:
:
,''''''''''''''''''''''''\ :
| Local ,------. | :
| Alert | Local| | : ...................
| Distribution | Relay|.|..: Alert | +------+ Author |
| Server `......'-+<------------------+-|Sender| O |
| | | Notification | | | /|\ |
'`'''''''''''''''''+'''''' | +------+ / \ |
^ Alert | `-----------------'
Subscr. +---------+
| | Notification
| |
| V
.....................
| +------+ Recipient|
| |Recvr | O |
| | | /|\ |
| +------+ / \ |
`-------------------'
Figure 2: Multicast/Broadcast Alert Delivery Mechanism with Explicit
Subscription
4. Requirements
The requirements listed below focus on the goal of mass alert
distribution, which has to utilize multicast/broadcast communication
for scalability reasons. The requirements for point-to-point alert
delivery are shown in Appendix A for completeness reasons only since
the focus of the IETF ATOCA working group is on the multicast/
broadcast alert delivery.
4.1. Requirements for the Discovery of an Alert Distribution Server
Req-D1:
The protocol solution MUST allow a receiver to discover a local
alert distribution server, as discussed in Section 3 and shown in
Figure 2, and to discover the necessary security credentials for
subsequent alert message distribution.
Schulzrinne, et al. Expires September 13, 2012 [Page 10]
Internet-Draft Exigent Communications March 2012
4.2. Requirements for Multicast/Broadcast Alert Message Delivery
Req-B1:
The protocol solution MUST leverage multicast/broadcast
technologies. This implies non-TCP transport and congestion
control being considered.
Req-B2:
The protocol solution MUST allow delivery of messages
simultaneously to a large audience.
Req-B3:
The protocol solution MUST be able to traverse firewalls and NATs
as they are common in today's deployments.
5. IANA Considerations
This document does not require actions by IANA.
6. Security Considerations
Figure 1 shows the actors for delivering an alert message assuming
that a prior subscription has taken place already. The desired
security properties of an MHS for conveying alerts will depend on the
number of administrative domains involved. Each administrative
domain can have vastly different operating policies and trust-based
decision-making. One obvious example is the distinction between
alert messages that are exchanged within an closed group (such as
alert messages received by parents affecting the school attended by
their children) and alert messages that are exchanged between
independent organizations (e.g., in case of large scale disasters).
The rules for handling both types of communication architectures tend
to be quite different. That difference requires defining the
boundaries of each.
Operation of communication systems that are used to convey alert
messages are typically carried out by different providers (or
operators). Since each be in operated in an independent
administrative domain it is useful to consider administrative domain
boundaries in the description to facilitate discussion about designs,
policies and operations that need to distinguish between internal
issues and external entities. Most significant is that the entities
communicating across administrative boundaries typically have the
Schulzrinne, et al. Expires September 13, 2012 [Page 11]
Internet-Draft Exigent Communications March 2012
added burden of enforcing organizational policies concerning external
communications. For example, routing alerts between administrative
domains can create requirements, such as needing to route alert
messages between organizational partners over specially trusted
paths.
The communication interactions are subject to the policies of that
domain, which cover concerns such as these:
o Reliability
o Access control
o Accountability
o Content evaluation, adaptation, and modification
Many communication systems make the distinction of administrative
domains since they impact the requirements on security solutions.
However, with the distribution of alert messages a number of
additional security threats need to be addressed. Due to the nature
of alerts it is quite likely that end device implementations will
offer user interface enhancements to get the Recipients attention
whenever an alert arrives, which is an attractive property for
adversaries to exploit. Below we list the most important threats any
solution will have to deal with.
Originator Impersonation:
An attacker could then conceivably attempt to impersonate the
Originator of an alert message. This threat is particularly
applicable to those deployment environments where authorization
decisions are based on the identity of the Originator.
Alert Message Forgery:
An attacker could forge or alter an alert message in order to
convey custom messages to Recipients to get their immediate
attention.
Replay:
An attacker could obtain previously distributed alert messages and
to replay them at a later time in the hope that Recipients could
be tricked into believing they are fresh.
Unauthorized Distribution:
When a Receiver receives an alert message it has to determine
whether the Author distributing the alert messages is genuine to
avoid accepting messages that are injected by malicious entities
Schulzrinne, et al. Expires September 13, 2012 [Page 12]
Internet-Draft Exigent Communications March 2012
with the potential desire to at least get the immediate attention
of the Recipient.
Amplification Attack:
An attacker may use the Message Handling System to inject a single
alert message for distribution that may then be instantly turned
into potentially millions of alert messages for distribution.
One important security challenge is related to authorization. When
an alert message arrives at the Receiver then certain security checks
may need to be performed to ensure that the alert message meets
certain criteria. The final consumer of the alert message is,
however, the Recipient - a human. From a security point of view the
work split between the Recipient and the Receiver for making the
authorization decision is important, particularly when an alert
message is rejected due to a failed security verification by the
Receiver. False positives may be fatal but accepting every alert
message lowers the trustworthiness in the overall system.
7. Acknowledgments
This document re-uses text from [RFC5598]. The authors would like to
thank Dave Crocker for his work.
The authors would like to thank Martin Thomson, Carl Reed, Leopold
Murhammer, and Tony Rutkowski for their comments.
At IETF#79 the following persons provided feedback leading to changes
in this document: Keith Drage, Scott Bradner, Ken Carberg, Keeping
Li, Martin Thomson, Igor Faynberg, Mark Wood, Peter Saint-Andre.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009.
8.2. Informative References
[I-D.rosen-ecrit-lost-early-warning]
Rosen, B., Schulzrinne, H., and H. Tschofenig, "A Uniform
Schulzrinne, et al. Expires September 13, 2012 [Page 13]
Internet-Draft Exigent Communications March 2012
Resource Name (URN) for Early Warning Emergency Services
and Location-to-Service Translation (LoST) Protocol
Usage", draft-rosen-ecrit-lost-early-warning-01 (work in
progress), July 2009.
[July2005]
, ., "Report of the 7 July Review Committee, ISBN 1
85261 878 7", (PDF document), http://www.london.gov.uk/
assembly/reports/7july/report.pdf, June 2006.
[RFC4244] Barnes, M., "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 4244,
November 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC5582] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", RFC 5582, September 2009.
Appendix A. Supplementary Requirements
A.1. Requirements for Alert Subscription
The requirements listed below refer to the alert subscription phase
as it is used to tailor alert message delivery in a point-to-point
alert delivery scenario. As noted in the main part of the document
these requirements are not the main focus of the ATOCA work.
Req-S1:
The protocol solution MUST allow a potential Recipient to indicate
the language used by alert messages.
Req-S2:
The protocol solution MUST allow a potential Recipient to express
the geographical area it wants to receive alerts about.
Req-S3:
The protocol solution MUST allow a potential Recipient to indicate
preferences about the type of alerts it wants to receive.
Schulzrinne, et al. Expires September 13, 2012 [Page 14]
Internet-Draft Exigent Communications March 2012
Req-S4:
The protocol solution MUST allow a potential Recipient to express
preference for certain media types. The support for different
media types depends on the content of the warning message but also
impacts the communication protocol. This functionality is, for
example, useful for hearing and vision impaired persons.
A.2. Point-to-Point Alert Delivery
Req-P1:
The protocol solution MUST build on existing communication
protocols and support the delivery of alert messages. Examples of
such protocols are SIP, XMPP, Atom, eMail.
Req-P2:
The protocol solution MUST allow targeting notifications to
specific subscribers.
Authors' Addresses
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
US
Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Steve Norreys
BT Group
1 London Road
Brentwood, Essex CM14 4QP
UK
Phone: +44 1277 32 32 20
Email: steve.norreys@bt.com
Schulzrinne, et al. Expires September 13, 2012 [Page 15]
Internet-Draft Exigent Communications March 2012
Brian Rosen
NeuStar, Inc.
470 Conrad Dr
Mars, PA 16046
US
Phone:
Email: br@brianrosen.net
Hannes Tschhofenig
Nokia Siemens Networks
Linnoitustie 6
Espoo 02600
Finland
Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Schulzrinne, et al. Expires September 13, 2012 [Page 16]