draft-ietf-ecrit-requirements-09.txt   draft-ietf-ecrit-requirements-10.txt 
ECRIT H. Schulzrinne ECRIT H. Schulzrinne
Internet-Draft Columbia U. Internet-Draft Columbia U.
Expires: November 18, 2006 R. Marshall, Ed. Expires: December 11, 2006 R. Marshall, Ed.
TCS TCS
May 17, 2006 June 9, 2006
Requirements for Emergency Context Resolution with Internet Requirements for Emergency Context Resolution with Internet
Technologies Technologies
draft-ietf-ecrit-requirements-09.txt draft-ietf-ecrit-requirements-10.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 18, 2006. This Internet-Draft will expire on December 11, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document enumerates requirements for the context resolution of This document enumerates requirements for the context resolution of
emergency calls placed by the public using voice-over-IP (VoIP) and emergency calls placed by the public using voice-over-IP (VoIP) and
general Internet multimedia systems, where Internet protocols are general Internet multimedia systems, where Internet protocols are
skipping to change at page 6, line 9 skipping to change at page 6, line 9
Voice Service Provider (VSP): A specific type of Application Service Voice Service Provider (VSP): A specific type of Application Service
Provider which provides voice related services based on IP, such Provider which provides voice related services based on IP, such
as call routing, a SIP URI, or PSTN termination. In this as call routing, a SIP URI, or PSTN termination. In this
document, unless noted otherwise, any reference to "Voice Service document, unless noted otherwise, any reference to "Voice Service
Provider" or "VSP" may be used interchangeably with "Application/ Provider" or "VSP" may be used interchangeably with "Application/
Voice Service Provider" or "ASP/VSP". Voice Service Provider" or "ASP/VSP".
Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call Emergency Service Routing Proxy (ESRP): An ESRP is an emergency call
routing support entity that invokes the location-to-PSAP URI routing support entity that invokes the location-to-PSAP URI
mapping, to return either the URI for the appropriate PSAP, or the mapping, to return either the URI for the appropriate PSAP, or the
URL for another ESRP. (In a SIP system, the ESRP would typically URI for another ESRP. (In a SIP system, the ESRP would typically
be a SIP proxy, but may also be a Back-to-back user agent be a SIP proxy, but may also be a Back-to-back user agent
(B2BUA)). (B2BUA)).
Emergency Call Routing Support (ECRS): An intermediary function which Emergency Call Routing Support (ECRS): An intermediary function which
assists in the routing of an emergency call via IP. An ESRP is an assists in the routing of an emergency call via IP. An ESRP is an
example of an Emergency call routing support entity. example of an emergency call routing support entity.
Public Safety Answering Point (PSAP): Physical location where Public Safety Answering Point (PSAP): Physical location where
emergency calls are received under the responsibility of a public emergency calls are received under the responsibility of a public
authority. (This terminology is used by both ETSI, in ETSI SR 002 authority. (This terminology is used by both ETSI, in ETSI SR 002
180, and NENA.) In the United Kingdom, PSAPs are called Operator 180, and NENA.) In the United Kingdom, PSAPs are called Operator
Assistance Centres, in New Zealand, Communications Centres. Assistance Centres, in New Zealand, Communications Centres.
Within this document, it is assumed, unless stated otherwise, that Within this document, it is assumed, unless stated otherwise, that
PSAP is that which supports the receipt of emergency calls over PSAP is that which supports the receipt of emergency calls over
IP. It is also assumed that the PSAP is reachable by IP-based IP. It is also assumed that the PSAP is reachable by IP-based
protocols, such as SIP for call signaling and RTP for media. protocols, such as SIP for call signaling and RTP for media.
Location: A geographic identification assigned to a region or feature Location: A geographic identification assigned to a region or feature
based on a specific coordinate system, or by other precise based on a specific coordinate system, or by other precise
information such as a street number and name. It can be either a information such as a street number and name. It can be either a
civic or geographic location. civic or geographic location.
Civic location: A described location based on some defined grid, such Civic location: A described location based on some defined grid, such
as a jurisdictional, postal, metropolitan, or rural reference as a jurisdictional, postal, metropolitan, or rural reference
system, (e.g., street address). system, (e.g., street address).
Geographic location: A reference to a locatable point described by a Geographic location: A reference to a point which is able to be
set of defined coordinates within a geographic coordinate system, located as described by a set of defined coordinates within a
(e.g., lat/lon within the WGS-84 datum). For example, (2-D) geographic coordinate system, (e.g., lat/lon within the WGS-84
geographic location is defined as an x,y coordinate value pair datum). For example, (2-D) geographic location is defined as an
according to the distance North or South of the equator and East x,y coordinate value pair according to the distance North or South
or West of the prime meridian. of the equator and East or West of the prime meridian.
Location validation: A caller location is considered valid if the Location validation: A caller location is considered valid if the
civic or geographic location is recognizable within an acceptable civic or geographic location is recognizable within an acceptable
location reference system (e.g., USPS, WGS-84, etc.), and can be location reference system (e.g., USPS, WGS-84, etc.), and can be
mapped to one or more PSAPs. While it is desirable to determine mapped to one or more PSAPs. While it is desirable to determine
that a location exists, validation may not ensure that such a that a location exists, validation may not ensure that such a
location exists. Location validation ensures that a location is location exists, but rather may only ensure that the location
able to be referenced for mapping, but makes no assumption about falls within some range of known values. Location validation
the association between the caller and the caller's location. ensures that a location is able to be referenced for mapping, but
makes no assumption about the association between the caller and
the caller's location.
(Location-dependent) emergency dial string: Location-dependent (Location-dependent) emergency dial string: A location-dependent
emergency dial strings should be thought of as the digit sequence emergency dial string should be thought of as the digit sequence
that is dialed in order to reach emergency services. There are that is dialed in order to reach emergency services. There are
two dial strings, namely either a "home emergency dial string", or two dial strings described within this document, namely a "home
a "visited emergency dial string", and is something separate from emergency dial string", and a "visited emergency dial string".
an emergency service identifier, since each represents specific
emergency dial string key sequences which are recognized within a
local geographic area or jurisdiction.
Home emergency dial string: A home emergency dial string represents a Home emergency dial string: A home emergency dial string represents a
(e.g., dialed) sequence of digits, that is used to initiate an (e.g., dialed) sequence of digits, that is used to initiate an
emergency call within a geographically correct location of a emergency call within a geographically correct location of a
caller if it is considered to be a user's "home" location or caller if it is considered to be a user's "home" location or
vicinity. vicinity.
Visited emergency dial string: A visited emergency dial string Visited emergency dial string: A visited emergency dial string
represents a sequence of digits that is used to initiate an represents a sequence of digits that is used to initiate an
emergency call within a geographically correct location of the emergency call within a geographically correct location of the
skipping to change at page 8, line 20 skipping to change at page 8, line 20
Mapping client: A mapping client interacts with the mapping server to Mapping client: A mapping client interacts with the mapping server to
learn one or more PSAP URIs for a given location. learn one or more PSAP URIs for a given location.
Mapping protocol: A protocol used to convey the mapping request and Mapping protocol: A protocol used to convey the mapping request and
response. response.
Mapping server: The mapping server holds information about the Mapping server: The mapping server holds information about the
location-to-PSAP URI mapping. location-to-PSAP URI mapping.
Mapping service: A network service which uses a distributed mapping Mapping service: A network service which uses a distributed mapping
protocol, to perform a mapping between a location and a PSAP, or protocol to perform a mapping between a location and a PSAP, or
intermediary which knows about the PSAP, and is used to assist in intermediary which knows about the PSAP, and is used to assist in
routing an emergency call. routing an emergency call.
(Emergency) caller: The term "caller" or "emergency caller" refer to (Emergency) caller: The term "caller" or "emergency caller" refer to
the person placing an emergency call or sending an emergency the person placing an emergency call or sending an emergency
instant message (IM). instant message (IM).
Call taker: A call taker is an agent at the PSAP that accepts calls Call taker: A call taker is an agent at the PSAP that accepts calls
and may dispatch emergency help. Sometimes the functions of call and may dispatch emergency help. Sometimes the functions of call
taking and dispatching are handled by different groups of people, taking and dispatching are handled by different groups of people,
skipping to change at page 10, line 41 skipping to change at page 10, line 41
Internet Attachment Provider (e.g., using DHCP or application layer Internet Attachment Provider (e.g., using DHCP or application layer
signaling protocols). signaling protocols).
(3) The emergency caller might need to consult a mapping service to (3) The emergency caller might need to consult a mapping service to
determine the PSAP (or other relevant information) that is determine the PSAP (or other relevant information) that is
appropriate for the physical location of the emergency caller, appropriate for the physical location of the emergency caller,
possibly considering other attributes such as appropriate language possibly considering other attributes such as appropriate language
support by the emergency call taker. support by the emergency call taker.
(4) The emergency caller might get assistance for emergency call (4) The emergency caller might get assistance for emergency call
routing by infrastructure elements that are Emergency Call Routing routing by infrastructure elements that are emergency call routing
Support entities, e.g., an Emergency Service Routing Proxy (ESRP), in support entities, (e.g., an Emergency Service Routing Proxy (ESRP),
SIP). in SIP).
(5) Location information is used by emergency call routing entities (5) Location information is used by emergency call routing support
for subsequent mapping requests. entities for subsequent mapping requests.
(6) Emergency call routing support entities might need to consult a (6) Emergency call routing support entities might need to consult a
mapping service to determine where to route the emergency call. mapping service to determine where to route the emergency call.
(7) For infrastructure-based emergency call routing (in contrast to (7) For infrastructure-based emergency call routing (in contrast to
UE-based emergency call routing), the emergency call routing support UE-based emergency call routing), the emergency call routing support
entity needs to forward the call to the PSAP. entity needs to forward the call to the PSAP.
(8) The emergency caller (UE) may interact directly with the PSAP (8) The emergency caller (UE) may interact directly with the PSAP
(e.g., UE invokes mapping, and initiates a connection), without (e.g., UE invokes mapping, and initiates a connection), without
skipping to change at page 12, line 32 skipping to change at page 12, line 32
protocols and protocol extensions which support IP-based emergency protocols and protocol extensions which support IP-based emergency
calls. calls.
Motivation: It must be possible for a device or software developed Motivation: It must be possible for a device or software developed
or purchased in one country to place emergency calls in another or purchased in one country to place emergency calls in another
country. System components should not be biased towards a country. System components should not be biased towards a
particular set of emergency numbers or languages. Also, different particular set of emergency numbers or languages. Also, different
countries have evolved different ways of organizing emergency countries have evolved different ways of organizing emergency
services, e.g., either centralizing them or having smaller services, e.g., either centralizing them or having smaller
regional subdivisions such as United States counties or regional subdivisions such as United States counties or
municipalities handle emergency calls. municipalities which handle emergency calls.
Re3. Distributed administration: Deployment of IP-based emergency Re3. Distributed administration: Deployment of IP-based emergency
services MUST NOT depend on a sole central administration services MUST NOT depend on a sole central administration
authority. authority.
Motivation: The design mapping protocol must make it possible to Motivation: The design of the mapping protocol must make it
deploy and administer emergency calling features on a regional or possible to deploy and administer emergency calling features on a
national basis without requiring coordination with other regions regional or national basis without requiring coordination with
or nations. The system cannot assume, for example, that there is other regions or nations. The system cannot assume, for example,
a single global entity issuing certificates for PSAPs, ASP/VSPs, that there is a single global entity issuing certificates for
IAPs or other participants. PSAPs, ASP/VSPs, IAPs or other participants.
Re4. Multi-mode communication: IP-based emergency calls MUST support Re4. Multi-mode communication: IP-based emergency calls MUST support
multiple communication modes, including, for example, audio, video multiple communication modes, including, for example, audio, video
and text. and text.
Motivation: In PSTN, voice and text telephony (often called TTY or Motivation: Within the PSTN, voice and text telephony (often
text-phone in North America) are the only commonly supported called TTY or text-phone in North America) are the only commonly
media. Emergency calling must support a variety of media. Such supported media. Emergency calling must support a variety of
media should include voice, conversational text (RFC 4103 [5]), media. Such media should include voice, conversational text (RFC
instant messaging and video. 4103 [5]), instant messaging and video.
Re5. Alternate mapping sources: The mapping protocol MUST implement Re5. Alternate mapping sources: The mapping protocol MUST implement
a mechanism that allows for the retrieval of mapping information a mechanism that allows for the retrieval of mapping information
from different sources. from different sources.
Motivation: This provides the possibility of having available Motivation: This provides the possibility of having available
alternative sources of mapping information when the normal source alternative sources of mapping information when the normal source
is unavailable or unreachable. is unavailable or unreachable.
Re6. Currency indication: The mapping protocol SHOULD support an Re6. Currency indication: The mapping protocol SHOULD support an
skipping to change at page 15, line 8 skipping to change at page 15, line 8
true identity of the target for which the location information is true identity of the target for which the location information is
attributed. attributed.
Motivation: Ideally, no identity information is provided via the Motivation: Ideally, no identity information is provided via the
mapping protocol. Where identity information is provided, it may mapping protocol. Where identity information is provided, it may
be in the form of an unlinked pseudonym (RFC 3693 [3]). be in the form of an unlinked pseudonym (RFC 3693 [3]).
5. Identifying the Caller's Location 5. Identifying the Caller's Location
Location can either be provided directly, or by reference, and Location can either be provided directly, or by reference, and
represents either a civic location, or a geospatial location. An represents either a civic location, or a geographic location. An
important question is how and when to attach location information to important question is how and when to attach location information to
the VoIP emergency signaling. In general, we can distinguish three the VoIP emergency signaling. In general, we can distinguish three
modes of operation of how a location is associated with an emergency modes of operation of how a location is associated with an emergency
call: call:
UA-inserted: The caller's user agent inserts the location information UA-inserted: The caller's user agent inserts the location information
into the call signaling message. The location information is into the call signaling message. The location information is
derived from sources such as GPS, DHCP (see [4] for geospatial derived from sources such as GPS, DHCP (see [4] for geographic
location information and [10]) for civic location information or location information and [10]) for civic location information or
utilizing the Link Layer Discovery Protocol (LLDP) [see utilizing the Link Layer Discovery Protocol (LLDP) [see
IEEE8021AB]. IEEE8021AB].
UA-referenced: The caller's user agent provides a pointer (i.e., a UA-referenced: The caller's user agent provides a pointer (i.e., a
location reference), via a permanent or temporary identifier, to location reference), via a permanent or temporary identifier, to
the location which is stored by a location server somewhere else the location which is stored by a location server somewhere else
and then retrieved by the PSAP, ESRP, or other authorized service and then retrieved by the PSAP, ESRP, or other authorized service
entity. entity.
Proxy-inserted: A proxy along the call path inserts the location or Proxy-inserted: A proxy along the call path inserts the location or
location reference. location reference.
Lo1. Reference datum: The mapping protocol MUST support the WGS-84 Lo1. Reference datum: The mapping protocol MUST support the WGS-84
coordinate reference system and MAY support other coordinate coordinate reference system and MAY support other coordinate
reference systems. reference systems.
Motivation: Though many different datums exist around the world,
the WGS-84 datum is recommended here since it is designed to
describe the whole earth, rather than a single continent, etc.
Lo2. Location object/info preservation: The mapping protocol MUST Lo2. Location object/info preservation: The mapping protocol MUST
retain any location information which is provided to it, even retain any location information which is provided to it, even
after mapping is performed. after mapping is performed.
Motivation: The ESRP and the PSAP use the same location Motivation: The ESRP and the PSAP use the same location
information object, but for a different purpose. Therefore, it is information object, but for a different purpose. Therefore, it is
imperative that the mapping protocol does not remove the location imperative that the mapping protocol does not remove the location
information from the messaging, so that it can be provided to the information from the messaging, so that it can be provided to the
PSAP. PSAP.
skipping to change at page 18, line 18 skipping to change at page 18, line 18
service URNs [8], but which may also refer to other identifiers which service URNs [8], but which may also refer to other identifiers which
are not service URNs, for example, a tel URI. In protocol exchanges, are not service URNs, for example, a tel URI. In protocol exchanges,
any request to invoke an emergency service along with the specific any request to invoke an emergency service along with the specific
type of emergency service desired, such as fire department or police, type of emergency service desired, such as fire department or police,
is indicated by the service URN. is indicated by the service URN.
Since this document addresses only emergency service context specific Since this document addresses only emergency service context specific
requirements for mapping, the terms service identifier and service requirements for mapping, the terms service identifier and service
URN, which have a more general applicability than that of only URN, which have a more general applicability than that of only
emergency services, are replaced by the terms "emergency service emergency services, are replaced by the terms "emergency service
identifier" and "emergency service URN", respectively, throughout identifier" (ESI) and "emergency service URN", respectively,
this document. The term "sos service URN" is used interchangeably throughout this document. The term "sos service URN" is used
with "emergency service URN". interchangeably with "emergency service URN".
Id1. Emergency service identifier support: The mapping protocol MUST Id1. Emergency service identifier support: The mapping protocol MUST
be able to return one or multiple emergency service identifiers in be able to return one or multiple emergency service identifiers in
response to a query. response to a query.
Motivation: Since there is a need for any device or network Motivation: Since there is a need for any device or network
element to recognize an emergency call throughout the call setup, element to recognize an emergency call throughout the call setup,
there is also a need to have the mapping protocol provide support there is also a need to have the mapping protocol provide support
for such an identifier. This is regardless of the device location for such an identifier. This is regardless of the device location
or the ASP/VSP used. An example of this kind of identifier might or the ASP/VSP used. An example of this kind of identifier might
skipping to change at page 19, line 16 skipping to change at page 19, line 16
mechanism to discover an existing location-dependent emergency mechanism to discover an existing location-dependent emergency
dial string, (e.g., "9-1-1", "1-1-2"), contextually appropriate dial string, (e.g., "9-1-1", "1-1-2"), contextually appropriate
for the location of the caller. for the location of the caller.
Motivation: Users are trained to dial the appropriate emergency Motivation: Users are trained to dial the appropriate emergency
dial string to reach emergency services. There needs to be a way dial string to reach emergency services. There needs to be a way
to figure out what the dial string is within the local environment to figure out what the dial string is within the local environment
of the caller. of the caller.
Id5. Home emergency dial string translation: There MUST be support Id5. Home emergency dial string translation: There MUST be support
for end device translation (e.g. SIP UA) of a home emergency dial for end device translation (e.g., SIP UA) of a home emergency dial
string into an emergency service identifier. string into an emergency service identifier.
Motivation: The UA would most likely be pre-provisioned with the Motivation: The UA would most likely be pre-provisioned with the
appropriate information in order to make such a translation. The appropriate information in order to make such a translation. The
mapping protocol would be able to support either type for those mapping protocol would be able to support either type for those
clients which may not support dial string translation. clients which may not support dial string translation.
Id6. Emergency dial string replacement: There SHOULD be support for Id6. Emergency dial string replacement: There SHOULD be support for
replacement of the original dial string with a reserved emergency replacement of the original dial string with a reserved emergency
service identifier for each signaling protocol used for an service identifier for each signaling protocol used for an
skipping to change at page 21, line 41 skipping to change at page 21, line 41
Motivation: An over-abundance of similarly-capable choices appears Motivation: An over-abundance of similarly-capable choices appears
undesirable for interoperability. undesirable for interoperability.
Ma2. Extensible protocol: The mapping protocol MUST be designed to Ma2. Extensible protocol: The mapping protocol MUST be designed to
support the extensibility of location data elements, both for new support the extensibility of location data elements, both for new
and existing fields. and existing fields.
Motivation: This is needed, for example, to accommodate future Motivation: This is needed, for example, to accommodate future
extensions to location information that might be included in the extensions to location information that might be included in the
PIDF-LO (RFC 4119 [6]). PIDF-LO ([6]).
Ma3. Incrementally deployable: The mapping protocol MUST be designed Ma3. Incrementally deployable: The mapping protocol MUST be designed
in such a way that supports the incremental deployment of mapping in such a way that supports the incremental deployment of mapping
services. services.
Motivation: It must not be necessary, for example, to have a Motivation: It must not be necessary, for example, to have a
global street level database before deploying the system. It is global street level database before deploying the system. It is
acceptable to have some misrouting of calls when the database does acceptable to have some misrouting of calls when the database does
not (yet) contain accurate PSAP service area information. not (yet) contain accurate PSAP service area information.
Ma4. Any time mapping: The mapping protocol MUST support the ability Ma4. Any time mapping: The mapping protocol MUST support the ability
of the mapping function to be invoked at any time, including while of the mapping function to be invoked at any time, including while
an emergency call is in process and before an emergency call. an emergency call is in process and before an emergency call is
initiated.
Motivation: Used as a fallback mechanism only, if a mapping query Motivation: Used as a fallback mechanism only, if a mapping query
fails at emergency call time, it may be advantageous to have prior fails at emergency call time, it may be advantageous to have prior
knowledge of the PSAP URI. This prior knowledge would be obtained knowledge of the PSAP URI. This prior knowledge would be obtained
by performing a mapping query at any time prior to an emergency by performing a mapping query at any time prior to an emergency
call. call.
Ma5. Anywhere mapping: The mapping protocol MUST support the ability Ma5. Anywhere mapping: The mapping protocol MUST support the ability
to provide mapping information in response to an individual query to provide mapping information in response to an individual query
from any (earthly) location, regardless of where the mapping from any (earthly) location, regardless of where the mapping
skipping to change at page 22, line 29 skipping to change at page 22, line 30
Motivation: The mapping client, such as an ESRP, may not Motivation: The mapping client, such as an ESRP, may not
necessarily be anywhere close to the caller or the appropriate necessarily be anywhere close to the caller or the appropriate
PSAP, but must still be able to obtain mapping information. PSAP, but must still be able to obtain mapping information.
Ma6. Appropriate PSAP: The mapping protocol MUST support the routing Ma6. Appropriate PSAP: The mapping protocol MUST support the routing
of an emergency call to the PSAP responsible for a particular of an emergency call to the PSAP responsible for a particular
geographic area. geographic area.
Motivation: Routing to the wrong PSAP will result in delays in Motivation: Routing to the wrong PSAP will result in delays in
handling emergencies as calls are redirected, and result in handling emergencies as calls are redirected, and therefore will
inefficient use of PSAP resources at the initial point of contact. also result in inefficient use of PSAP resources at the initial
It is important that the location determination mechanism not be point of contact. It is important that the location determination
fooled by the location of IP telephony gateways or dial-in lines mechanism not be fooled by the location of IP telephony gateways
into a corporate LAN (and dispatch emergency help to the gateway or dial-in lines into a corporate LAN (and dispatch emergency help
or campus, rather than the caller), multi-site LANs and similar to the gateway or campus, rather than the caller), multi-site LANs
arrangements. and similar arrangements.
Ma7. Multiple PSAP URIs: The mapping protocol MUST support a method Ma7. Multiple PSAP URIs: The mapping protocol MUST support a method
to return multiple PSAP URIs which cover the same geographic area. to return multiple PSAP URIs which cover the same geographic area.
Motivation: Two different mapping servers may cover the same Motivation: Two different mapping servers may cover the same
geographic area, and therefore have the same set of coverage geographic area, and therefore have the same set of coverage
information. information.
Ma8. Single primary URI per contact protocol: Though the mapping Ma8. Single primary URI per contact protocol: Though the mapping
protocol supports multiple URIs being returned, it SHOULD return protocol supports multiple URIs being returned, it SHOULD return
skipping to change at page 29, line 37 skipping to change at page 29, line 37
Conversation", RFC 4103, June 2005. Conversation", RFC 4103, June 2005.
[6] Peterson, J., "A Presence-based GEOPRIV Location Object [6] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[7] Taylor, T., "Security Threats and Requirements for Emergency [7] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-ietf-ecrit-security-threats-01 Call Marking and Mapping", draft-ietf-ecrit-security-threats-01
(work in progress), April 2006. (work in progress), April 2006.
[8] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [8] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-ietf-ecrit-service-urn-02 (work in progress), April 2006. draft-ietf-ecrit-service-urn-03 (work in progress), May 2006.
[9] Hardie, T., "LoST: A Location-to-Service Translation Protocol", [9] Hardie, T., "LoST: A Location-to-Service Translation Protocol",
draft-hardie-ecrit-lost-00 (work in progress), March 2006. draft-hardie-ecrit-lost-00 (work in progress), March 2006.
[10] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [10] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
and DHCPv6) Option for Civic Addresses Configuration and DHCPv6) Option for Civic Addresses Configuration
Information", draft-ietf-geopriv-dhcp-civil-09 (work in Information", draft-ietf-geopriv-dhcp-civil-09 (work in
progress), January 2006. progress), January 2006.
[11] Wijk, A., "Framework for real-time text over IP using SIP", [11] Wijk, A., "Framework for real-time text over IP using SIP",
 End of changes. 25 change blocks. 
56 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/