ECRIT T. Hardie
Internet-Draft Qualcomm, Inc.
Expires: November 14, 2005 A. Newton
Verisign, Inc.
H. Tschofenig
Siemens
May 13, 2005
An IRIS Schema for Emergency Service Contact URIs
draft-hardie-ecrit-iris-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes an XML-based protocol for passing location
information to a server that returns emergency service contact URIs.
It is based on IRIS, the Internet Registry Information Service, and
starts from the premise that the search for emergency service
contacts can be modelled as a database search that uses geolocation
Hardie, et al. Expires November 14, 2005 [Page 1]
Internet-Draft IRIS-ECON May 2005
or civic location as input and returns one or more contact URIs as
output. It is intended to fit within a larger framework of
standards. specifically, it presumes the existence of a URI scheme
appropriate for signaling that emergency service is required and
distinguishing among emergency services if appropriate. It also
presumes that an entity requesting this response will be able to
handle the URIs returned as input to appropriate handlers.
Table of Contents
1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 5
3.1 Query Derivatives . . . . . . . . . . . . . . . . . . . . 5
3.1.1 <findEconByCivic> Query . . . . . . . . . . . . . . . 5
3.1.2 <findEconByGeo> Query . . . . . . . . . . . . . . . . 5
3.2 Service Types . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Result Derivatives . . . . . . . . . . . . . . . . . . . . 6
3.3.1 <emergencyContact> Result . . . . . . . . . . . . . . 6
3.4 Error Derivatives . . . . . . . . . . . . . . . . . . . . 6
3.4.1 <invalidCivicData> . . . . . . . . . . . . . . . . . . 6
3.4.2 <invalidGeoData> . . . . . . . . . . . . . . . . . . . 7
4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5.1 Impersonating a PSAP . . . . . . . . . . . . . . . . . . . 11
5.2 Message Modification and Replay Attacks . . . . . . . . . 11
5.3 Loss of confidentiality . . . . . . . . . . . . . . . . . 12
5.4 Impersonating an IRIS Sever . . . . . . . . . . . . . . . 12
5.5 Denial of Service . . . . . . . . . . . . . . . . . . . . 12
6. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 14
6.1 Message Pattern . . . . . . . . . . . . . . . . . . . . . 14
6.2 Server Authentication . . . . . . . . . . . . . . . . . . 14
7. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Application Service Label . . . . . . . . . . . . . . . . 15
8. Internationalization Considerations . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1 XML Namespace URN Registration . . . . . . . . . . . . . . 17
9.2 S-NAPTR Registration . . . . . . . . . . . . . . . . . . . 17
9.3 BEEP Registration . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1 Normative References . . . . . . . . . . . . . . . . . . . 18
10.2 Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19
A. Example Request and Response . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 23
Hardie, et al. Expires November 14, 2005 [Page 2]
Internet-Draft IRIS-ECON May 2005
1. Requirements notation
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 [8].
Hardie, et al. Expires November 14, 2005 [Page 3]
Internet-Draft IRIS-ECON May 2005
2. Introduction
This document describes a protocol for taking location information
compatible with PIDF-LO [11] and passing it to an IRIS [3] server
using an XML schema specific to the task of returning emergency
service contact URIs. These URIs may be of multiple forms, including
sip, xmpp, and tel, and multiple URIs may be returned to a single
query. This document does not presume that this activity takes place
at any specific point in a call flow. It is a feature of the overall
system of which this forms a part that multiple entities may request
the lookup and perform the substitution of the emergency service
contact URI.
One consequence of this flexibility is that there are multiple
methods for discovering an IRIS server at which to start the query
process. An IRIS server may be preconfigured in the call processing
software performing the lookup. If an appropriate option is
specified, it could be configured dynamically using DHCP [4]. It
might also be discovered using a mechanism like DDDS [5].
It is likely that a combination of these methods will be needed to
ensure complete coverage; the delegation of an infrastructure domain
or the deployment of well-known servers may also be required. Note
that once a server has been discovered, IRIS can use referrals to
indicate that a different server will be a more appropriate query
target.
Hardie, et al. Expires November 14, 2005 [Page 4]
Internet-Draft IRIS-ECON May 2005
3. Schema Description
IRIS [3] requires the derivation of both query and result elements by
a registry schema. These descriptions follow.
References to XML elements without a namespace qualifier are from the
schema defined in this document. References to elements and
attributes with the "iris" XML namespace qualifier are from the
schema defined in IRIS [3]. Reference to elements and attributes
with the "civilLoc" XML namespace qualifier are from the civil
location schema defined in PIDF-LO [11]. References to elements and
attributes with the "gml" XML namespace qualifier are from the GML
[10].
The descriptions contained within this section refer to XML elements
and attributes and their relation to the exchange of data within the
protocol. These descriptions also contain specifications outside the
scope of the formal XML syntax. This section will use terms defined
by RFC 2119 to describe these. While reading this section, please
refer below for needed details on the formal XML syntax.
3.1 Query Derivatives
3.1.1 <findEconByCivic> Query
The <findEconByCivic> query allows a client to search for an
emergency contact using civic information. Civic information is
communicated via a <civilAddress> element defined in the
urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc namespace defined by
the civil location schema in PIDF-LO [11].
This query may also have the <service> (Section 3.2) element.
3.1.2 <findEconByGeo> Query
The <findEconByGeo> query allows a client to search for an emergency
contact using geo-spatial location information. This geo-spatial
information is communicated via a <location> element defined by GML
[10].
This query may also have the <service> (Section 3.2) element.
3.2 Service Types
Queries may be focused on certain types of emergency contact using
the optional <service> element. This element may contain the
following well-known tokens:
Hardie, et al. Expires November 14, 2005 [Page 5]
Internet-Draft IRIS-ECON May 2005
1. ecc
2. fire
3. rescue
4. marine
5. police
6. mountain
This information is provided as a hint from the client to the server
and is not intended to produce no results should the <service>
element not be given or if its specified type is not available. In
other words, servers MUST ignore this information if it would cause
no result to be returned.
3.3 Result Derivatives
3.3.1 <emergencyContact> Result
The <emergencyContact> result provides describes the URIs to be used
to reach an emergency contact. It may have an optional <displayName>
element which may be used by user agents for user feedback purposes.
The primary information relayed in this result are URIs to be used to
make contact with emergency services. This result may contain
multiple URIs. These URIs are not provided in preference order, and
clients MUST NOT attach preference to any URI based upon its position
in the list. Servers MUST NOT provide more than one URI of the
scheme in a result (e.g. two "sip:" URIs are not allowed). The
purpose of providing multiple URIs is to offer multiple methods of
contact. The protocols associated with specific contact methods may
have internal mechanisms for forking or forwarding contacts, and,
since these will likely be based on fresher data than that associated
with a search service, they are used in preference to multiple same-
scheme URIS.
3.4 Error Derivatives
3.4.1 <invalidCivicData>
Servers may use the <invalidCivicData> error to inform clients of
semantically invalid civil address information sent in a query.
Hardie, et al. Expires November 14, 2005 [Page 6]
Internet-Draft IRIS-ECON May 2005
3.4.2 <invalidGeoData>
Servers may use the <invalidGeoData> error to inform clients of
semantically invalid geo-spatial data sent in a query.
Hardie, et al. Expires November 14, 2005 [Page 7]
Internet-Draft IRIS-ECON May 2005
4. Formal Syntax
This registry schema is specified in the XML Schema notation (see [1]
and [2]). The formal syntax presented here is a complete schema
representation suitable for automated validation of an XML instance
when combined with the formal schema syntax of IRIS [3], PIDF-LO [11]
Civil Location, and GML [10].
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:econ="urn:ietf:params:xml:ns:econ1"
xmlns:iris="urn:ietf:params:xml:ns:iris1"
xmlns:civilLoc="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:gml="http://www.opengis.net/gml"
targetNamespace="urn:ietf:params:xml:ns:econ1"
elementFormDefault="qualified" >
<import namespace="urn:ietf:params:xml:ns:iris1" />
<import
namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc" />
<import namespace="http://www.opengis.net/gml" />
<annotation>
<documentation>
A schema for finding Emergency Contacts (ECON)
using the Internet Registry Information Service (IRIS)
</documentation>
</annotation>
<!-- -->
<!-- Query types -->
<!-- -->
<complexType name="findEconByCivicType">
<complexContent>
<extension base="iris:queryType">
<sequence>
<element name="civilAddress"
type="civilLoc:civilAddress"/>
<element name="service"
type="econ:serviceType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="findEconByCivic"
Hardie, et al. Expires November 14, 2005 [Page 8]
Internet-Draft IRIS-ECON May 2005
type="econ:findEconByCivicType"
substitutionGroup="iris:query" />
<complexType name="findEconByGeoType">
<complexContent>
<extension base="iris:queryType">
<sequence>
<element
ref="gml:location"/>
<element name="service"
type="econ:serviceType" minOccurs="0"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="findEconByGeo"
type="econ:findEconByGeoType"
substitutionGroup="iris:query" />
<simpleType
name="serviceType">
<restriction
base="string">
<enumeration value="ecc" />
<enumeration value="fire" />
<enumeration value="rescue" />
<enumeration value="marine" />
<enumeration value="police" />
<enumeration value="mountain" />
</restriction>
</simpleType>
<!-- -->
<!-- Result types -->
<!-- -->
<complexType name="emergencyContactType">
<complexContent>
<extension base="iris:resultType">
<sequence>
<element name="displayName"
type="normalizedString" minOccurs="0" />
<element name="uri"
type="anyURI"
minOccurs="1" maxOccurs="unbounded" />
</sequence>
</extension>
Hardie, et al. Expires November 14, 2005 [Page 9]
Internet-Draft IRIS-ECON May 2005
</complexContent>
</complexType>
<element name="emergencyContact"
type="econ:emergencyContactType"
substitutionGroup="iris:result" />
<!-- -->
<!-- Error types -->
<!-- -->
<element name="invalidCivicData"
type="iris:codeType"
substitutionGroup="iris:genericCode" />
<element name="invalidGeoData"
type="iris:codeType"
substitutionGroup="iris:genericCode" />
</schema>
Figure 1: econ.xsd
Hardie, et al. Expires November 14, 2005 [Page 10]
Internet-Draft IRIS-ECON May 2005
5. Security Considerations
Security considerations specific to IRIS are treated in the general
IRIS [3] document as well as in the specific transport documents
IRIS-BEEP [7] IRIS-LWZ [12]. Security threats and requirements for
ECRIT are treated in draft-tschofenig-ecrit-security-threats-00.txt
[6]. Please note that IRIS-LWZ does not provide built-in security
and relies on external mechanisms, such as IPsec, and might therefore
not be suitable to fulfill the requirements listed in [6].
Investigations regarding the suitability of the other transport
mechanisms, such as the work in progress approach of IRIS-LWZ, are
necessary since they do not allow TLS or SASL to be used. Hence, the
discussion of the security threats and their countermeasures mainly
focus on transport mechanisms used by IRIS that can benefit from TLS
and/or SASL security.
In general, there are multiple threats to the overall emergency
system. A subset of them are applicable for this document. More
specifically the following security aspects need to be addressed:
5.1 Impersonating a PSAP
Threat: An attacker might want to provide emergency callers with
wrong information about emergency service contact URIs. An
adversary can accomplish this goal in various ways, including
message modification, spoofing the IRIS server or corrupting the
IRIS database. Section 4.4 and 5.4 of [6] describe this threat in
more detail.
Countermeasure: In addition to the countermeasures described in
subsequent sections (for example, countermeasures against message
modification) it is necessary for the client to authenticate and
to authorize the IRIS server that provides the emergency service
contact URIs since these these URIs are later used to contact a
PSAP. This functionality is accomplished either using TLS (with
server-side authentication), SASL or a combination of them as part
of the transport mechanisms utilized by IRIS (such as BEEP or
XPC).
5.2 Message Modification and Replay Attacks
Threat: An adversary might attempt to modify the IRIS message
communication described in this document. A successful
modification might prevent the emergency caller from contact
further IRIS servers or PSAPs or might redirect them to wrong
entities. Additionaly it might be possible to replay past
communication exchanges to fool an emergency caller by returning
Hardie, et al. Expires November 14, 2005 [Page 11]
Internet-Draft IRIS-ECON May 2005
incorrect or no results.
Countermeasure: In order to prevent this threat integrity and replay
protection mechanism must be provided as offered by the TLS Record
Layer and by SASL. The required session keys are established as
part of the authentication and key exchange protocol, such as the
TLS Handshake protocol in case of TLS. SASL provides similar
functionality by establishing an integrity and replay protected
channel.
5.3 Loss of confidentiality
Threat: An attacker that can eavesdrop on the communication
requesting this lookup can surmise the existence of an emergency
and possibly its nature, and may be able to use this as a
springboard to a physical attack.
Countermeasure: To prevent an adversary from learning information
about the content of the communication between client and the
server it is necessary to provide confidentiality protection. The
TLS Record Layer and SASL provide this type of protection as long
as the respective cipher suites are negotiated.
5.4 Impersonating an IRIS Sever
Threat: An adversary might run a faked IRIS server aiming to pretend
that it is a legitimate server.
Countermeasure: It is necessary for the client to authenticate and to
authorize the IRIS server as part of the authentication and key
exchange protocol. Assuming that there is no prior relationship
between the emergency caller and the IRIS server (in the worst
case) public key based authentication seems to be the best choice.
Additional approaches for bootstrapping the security
associationship by exploiting existing relationships (such as
between the network access infrastructure provider and an IRIS
server) might simplify the key management. The authorization
aspects need further study.
5.5 Denial of Service
Hardie, et al. Expires November 14, 2005 [Page 12]
Internet-Draft IRIS-ECON May 2005
Threat: An adversary might want to mount a denial of service attack
against one or multiple IRIS server to prevent an emergency caller
from obtaining emergency service contact URIs.
Countermeasure: Dealing with all sorts of denial of service attacks
against the emergency infrastructure and at IRIS servers is
difficult. Protection needs to be provided at different protocol
layers and also at different locations in the network. From the
viewpoint of this document it needs to be ensured that the used
security mechanisms do not increase the vulnerability against
denial of service attacks. TLS, for example, does not provide the
same degree of denial of service protection as IKEv2 (with its
stateless cookie approach). Still, it seems to provide enough
protection to counter most attacks. Additionally, it is essential
to ensure that IRIS queries submitted by adversary towards the
IRIS server do not cause a major performance impact for the server
with the consequence that potentially genuine requests may need to
be rejected due to overload and a timely response is not possible.
It must be noted that clients will typically not be authenticated
by the IRIS server either due to the missing client-side public
key infrastructure and due to the authentication-override
principle that exists for emergency calls.
Hardie, et al. Expires November 14, 2005 [Page 13]
Internet-Draft IRIS-ECON May 2005
6. BEEP Transport Compliance
Though it is envisioned that an ECON service will be deployed with a
lightweight transport such as [12], it is still possible to use ECON
with the [7] transport. The use of this transport is completely at
the descretion of the server operator.
IRIS allows several extensions of the core capabilities. This
section outlines those extensions allowable by IRIS-BEEP [7].
6.1 Message Pattern
This registry type uses the default message pattern as described in
IRIS-BEEP [7].
6.2 Server Authentication
This registry type uses the default server authentication method as
described in IRIS-BEEP [7].
Hardie, et al. Expires November 14, 2005 [Page 14]
Internet-Draft IRIS-ECON May 2005
7. URI Resolution
7.1 Application Service Label
The application service label associated with this registry type MUST
be "ECON1". This is the abbreviated form of the URN for this
registry type, urn:ietf:params:xml:ns:econ1.
Hardie, et al. Expires November 14, 2005 [Page 15]
Internet-Draft IRIS-ECON May 2005
8. Internationalization Considerations
Implementers should be aware of considerations for
internationalization in IRIS [3].
Hardie, et al. Expires November 14, 2005 [Page 16]
Internet-Draft IRIS-ECON May 2005
9. IANA Considerations
9.1 XML Namespace URN Registration
This document makes use of a proposed XML namespace and schema
registry specified in XML_URN [9]. Accordingly, the following
registration information is provided for the IANA:
o URN/URI:
* urn:ietf:params:xml:ns:econ1
o Contact:
* Andrew Newton <andy@hxr.us>
* Ted Hardie <hardie@qualcomm.com>
o XML:
* The XML Schema specified in Section 4
9.2 S-NAPTR Registration
The following S-NAPTR application service label will need to be
registered with IANA according to the IANA considerations defined in
IRIS [3]:
ECON1
9.3 BEEP Registration
The following BEEP Profile URI is to be registeried with IANA, in
addition to the registration provided in IRIS-BEEP [7].
http://iana.org/beep/iris1/econ1
Hardie, et al. Expires November 14, 2005 [Page 17]
Internet-Draft IRIS-ECON May 2005
10. References
10.1 Normative References
[1] World Wide Web Consortium, "XML Schema Part 2: Datatypes",
W3C XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
[2] World Wide Web Consortium, "XML Schema Part 1: Structures",
W3C XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[3] Newton, A. and M. Sanz, "Internet Registry Information
Service", RFC 3891, January 2005.
[4] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[5] Daigle, L. and A. Newton, "Domain-Based Application Service
Location using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
[6] Tschofenig, H., "Security Threats and Requirements for
Emergency Calling",
draft-tschofenig-ecrit-security-threats-00.txt (work in
progress), May 2005.
[7] Newton, A. and M. Sanz, "Internet Registry Information Service
(IRIS) over Blocks Extensible Exchange Protocol (BEEP)",
RFC 3893, January 2005.
[8] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[9] Mealling, M., "The IETF XML Registry",
draft-mealling-iana-xmlns-registry-03 (work in progress),
November 2001.
[10] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC OGC 02-023r4, January 2003.
[11] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
September 2004.
Hardie, et al. Expires November 14, 2005 [Page 18]
Internet-Draft IRIS-ECON May 2005
10.2 Informative References
[12] Newton, A., "A Lightweight UDP Transport for IRIS",
draft-ietf-crips-iris-lwz-01 (work in progress), January 2005.
Authors' Addresses
Ted Hardie
Qualcomm, Inc.
675 Campbell Technology Parkway
Campbell, CA
USA
Email: hardie@qualcomm.com
Andrew Newton
Verisign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
USA
Email: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.verisignlabs.com/
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Hardie, et al. Expires November 14, 2005 [Page 19]
Internet-Draft IRIS-ECON May 2005
Appendix A. Example Request and Response
The example in this section use the string "C:" to denote data sent
by a client to a server and the string "S:" to denote data sent by a
server to a client.
The following example demonstrates a query based on civil location
information and a response to that query.
Hardie, et al. Expires November 14, 2005 [Page 20]
Internet-Draft IRIS-ECON May 2005
C: <request xmlns="urn:ietf:params:xml:ns:iris1">
C:
C: <searchSet>
C:
C: <findEconByCivic
C: xmlns="urn:ietf:params:xml:ns:econ1" >
C:
C: <civilAddress>
C: <country>US</country>
C: <A1>New York</A1>
C: <A3>New York</A3>
C: <A6>Broadway</A6>
C: <HNO>123</HNO>
C: <LOC>Suite 75</LOC>
C: <PC>10027-0401</PC>
C: </civilAddress>
C:
C: <service>police</service>
C:
C: </findEconByCivic>
C:
C: </searchSet>
C:
C: </request>
S: <response xmlns="urn:ietf:params:xml:ns:iris1">
S:
S: <resultSet>
S: <answer>
S:
S: <emergencyContact xmlns="urn:ietf:params:xml:ns:econ1"
S: authority="nyc.example" registryType="econ1"
S: entityClass="econ" entityName="nypd" >
S:
S: <displayName>
S: New York City Police Department
S: </displayName>
S: <uri>
S: sip://nypd.example/
S: </uri>
S:
S: </emergencyContact>
S:
S: </answer>
S:
S: </resultSet>
S:
S: </response>
Hardie, et al. Expires November 14, 2005 [Page 21]
Internet-Draft IRIS-ECON May 2005
Figure 2: Example 1
Hardie, et al. Expires November 14, 2005 [Page 22]
Internet-Draft IRIS-ECON May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hardie, et al. Expires November 14, 2005 [Page 23]