draft-ietf-ecrit-lost-06.txt   draft-ietf-ecrit-lost-07.txt 
ECRIT T. Hardie ECRIT T. Hardie
Internet-Draft Qualcomm, Inc. Internet-Draft Qualcomm, Inc.
Intended status: Standards Track A. Newton Intended status: Standards Track A. Newton
Expires: February 11, 2008 TranTech, Inc. Expires: August 10, 2008 American Registry for Internet
Numbers
H. Schulzrinne H. Schulzrinne
Columbia University Columbia University
H. Tschofenig H. Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
August 10, 2007 February 7, 2008
LoST: A Location-to-Service Translation Protocol LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-06.txt draft-ietf-ecrit-lost-07.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 39 skipping to change at page 1, line 40
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 February 11, 2008. This Internet-Draft will expire on August 8, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document describes an XML-based protocol for mapping service This document describes an XML-based protocol for mapping service
identifiers and geodetic or civic location information to service identifiers and geodetic or civic location information to service
contact URIs. In particular, it can be used to determine the contact URIs. In particular, it can be used to determine the
location-appropriate PSAP for emergency services. location-appropriate PSAP for emergency services.
Table of Contents Table of Contents
skipping to change at page 3, line 27 skipping to change at page 3, line 27
17.2. Content-type registration for 'application/lost+xml' . . . 51 17.2. Content-type registration for 'application/lost+xml' . . . 51
17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53 17.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 53
17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53 17.4. LoST Namespace Registration . . . . . . . . . . . . . . . 53
17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54 17.5. LoST Location Profile Registry . . . . . . . . . . . . . . 54
18. Security Considerations . . . . . . . . . . . . . . . . . . . 55 18. Security Considerations . . . . . . . . . . . . . . . . . . . 55
19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 19. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58
20.1. Normative References . . . . . . . . . . . . . . . . . . . 58 20.1. Normative References . . . . . . . . . . . . . . . . . . . 58
20.2. Informative References . . . . . . . . . . . . . . . . . . 59 20.2. Informative References . . . . . . . . . . . . . . . . . . 59
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 74 Appendix B. Examples On-line . . . . . . . . . . . . . . . . . . 74
Intellectual Property and Copyright Statements . . . . . . . . . . 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75
Intellectual Property and Copyright Statements . . . . . . . . . . 76
1. Introduction 1. Introduction
Protocols such as NAPTR records and the Service Location Protocol Protocols such as NAPTR records and the Service Location Protocol
(SLP) can be used to discover servers offering a particular service. (SLP) can be used to discover servers offering a particular service.
However, for an important class of services the appropriate specific However, for an important class of services the appropriate specific
service instance depends both on the identity of the service and the service instance depends both on the identity of the service and the
geographic location of the entity that needs to reach it. Emergency geographic location of the entity that needs to reach it. Emergency
telecommunications services are an important example; here, the telecommunications services are an important example; here, the
service instance is a Public Safety Answering Point (PSAP) that has service instance is a Public Safety Answering Point (PSAP) that has
jurisdiction over the location of the user making the call. The jurisdiction over the location of the user making the call. The
desired PSAP isn't necessarily the one that is topologically or even desired PSAP isn't necessarily the one that is topologically or even
line-of-sight closest to the caller; rather, it is the one that line-of-sight closest to the caller; rather, it is the one that
serves the callers location based on jurisdictional boundaries. serves the caller's location based on jurisdictional boundaries.
This document describes a protocol for mapping a service identifier This document describes a protocol for mapping a service identifier
(service URNs) [9] and location information compatible with PIDF-LO and location information compatible with PIDF-LO PIDF-LO [6] to one
[6], namely revised civic location information [10] and a subset of or more service URIs. Service identifiers take the form of the
the PIDF-LO profile [13] and consequently with the Geo-Shapes [12] service URNs described in [9]. Location information here includes
defined for GML [11]) to one or more service URLs. Example service revised civic location information [10] and a subset of the PIDL-LO
URL schemes include sip [14], xmpp [15], and tel [16]. While the profile [13] which consequently includes the Geo-Shapes [12] defined
initial focus is on providing mapping functions for emergency for GML [11]. Example service URI schemes include sip [14], xmpp
services, it is likely that the protocol is applicable to other [15], and tel [16]. While the initial focus is on providing mapping
service URNs. For example, in the United States, the "2-1-1" and functions for emergency services, it is likely that the protocol is
"3-1-1" service numbers follow a similar location-to-service behavior applicable to other service URNs. For example, in the United States,
as emergency services. the "2-1-1" and "3-1-1" service numbers follow a similar location-to-
service behavior as emergency services.
This document names this protocol "LoST", for Location-to-Service This document names this protocol "LoST", for Location-to-Service
Translation. LoST Satisfies the requirements [18] for mapping Translation. LoST Satisfies the requirements [18] for mapping
protocols. LoST provides a number of operations, centered around protocols. LoST provides a number of operations, centered around
mapping locations and service URNs to service URLs and associated mapping locations and service URNs to service URLs and associated
information. LoST mapping queries can contain either civic or information. LoST mapping queries can contain either civic or
geodetic location information. For civic addresses, LoST can geodetic location information. For civic addresses, LoST can
indicate which parts of the civic address are known to be valid or indicate which parts of the civic address are known to be valid or
invalid, thus providing address validation, as described in Section invalid, thus providing address validation, as described in Section
3.5 of [18]. LoST indicates errors in the location data to 3.5 of [18]. LoST indicates errors in the location data to
skipping to change at page 11, line 8 skipping to change at page 11, line 8
'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is 'NO-EXPIRATION' instead of a dateTime value. The value 'NO-CACHE' is
an indication that the mapping should not be cached. The value of an indication that the mapping should not be cached. The value of
'NO-EXPIRATION' is an indication that the mapping does not expire. 'NO-EXPIRATION' is an indication that the mapping does not expire.
On occasion, a server may be forced to return an expired mapping if On occasion, a server may be forced to return an expired mapping if
it cannot reach the authoritative server or the server fails to it cannot reach the authoritative server or the server fails to
return a usable answer. Clients and servers MAY cache the mapping so return a usable answer. Clients and servers MAY cache the mapping so
that they have at least some information available. Caching servers that they have at least some information available. Caching servers
that have such stale information SHOULD re-attempt the query each that have such stale information SHOULD re-attempt the query each
time a client requests a mapping. Since the expired mapping will be time a client requests a mapping. Since the expired mapping will be
returned to the client as a non-error/non-warning response it is the returned to the client as a non-error/non-warning response ,the
responsibility of the client to check the 'expires' attribute client MUST check the 'expires' attribute; if the mapping has
associated with mapping data returned in a LoST response to determine expired, local policy at the client determines whether it discards
whether the mapping is fresh. the answer and tries again later or uses the possibly stale response.
5.3. Describing the Service with the <displayName> Element 5.3. Describing the Service with the <displayName> Element
Zero or more <displayName> elements describe the service with a Zero or more <displayName> elements describe the service with a
string that is suitable for display to human users, each annotated string that is suitable for display to human users, each annotated
with the 'xml:lang' attribute that contains a language tag to aid in with the 'xml:lang' attribute that contains a language tag to aid in
the rendering of text. the rendering of text.
5.4. The Mapped Service: the <service> Element 5.4. The Mapped Service: the <service> Element
skipping to change at page 14, line 13 skipping to change at page 14, line 13
'sips'. 'sips'.
6. Path of a Request: the <path> Element 6. Path of a Request: the <path> Element
To prevent loops and to allow tracing of request and response paths, To prevent loops and to allow tracing of request and response paths,
all requests that allow recursion include a <path> element that all requests that allow recursion include a <path> element that
contains one or more <via> elements, each possessing an attribute contains one or more <via> elements, each possessing an attribute
containing a LoST application unique string (see Section 4). The containing a LoST application unique string (see Section 4). The
order of <via> elements corresponds to the order of LoST servers, order of <via> elements corresponds to the order of LoST servers,
i.e., the first <via> element identifies the server that initially i.e., the first <via> element identifies the server that initially
received the request from the client issuing the request. The <via> received the request from the client issuing the request. Every
element is inserted logically on receipt of the request, so that server in a recursive query operation is included in the
every server in a recursive query operation is included in the <path> <path>elelment, including the first server to receive it.
element.
The server that answers the request instead of forwarding it, such as The server that answers the request instead of forwarding it, such as
the authoritative server, copies the <path> element verbatim into the the authoritative server, copies the <path> element verbatim into the
response. The <path> element is not modified in responses as the response. The <path> element is not modified in responses as the
responses traverses the server chain back to the querying client. responses traverses the server chain back to the querying client.
If a query is answered iteratively, the querier includes all servers If a query is answered iteratively, the querier includes all servers
that it has already contacted. that it has already contacted.
When a cached mapping is returned then the <path> element cached When a cached mapping is returned then the <path> element cached
skipping to change at page 15, line 15 skipping to change at page 15, line 15
7. Identifying the Location Element Used for Mapping: <locationUsed> 7. Identifying the Location Element Used for Mapping: <locationUsed>
Several of the requests can provide one or more <location> elements, Several of the requests can provide one or more <location> elements,
among which the server gets to choose. It is useful for the client among which the server gets to choose. It is useful for the client
to be able to determine which one was actually used in producing the to be able to determine which one was actually used in producing the
result. For that purpose, the <location> tag MUST contain an 'id' result. For that purpose, the <location> tag MUST contain an 'id'
attribute that uniquely identifies the <location> element. The attribute that uniquely identifies the <location> element. The
format of the identifier is left to the client; it could, for format of the identifier is left to the client; it could, for
example, use a hash of the location information. The server returns example, use a hash of the location information. The server returns
the identifier for the <location> element it used in the the identifier for the <location> element it used in the
<locationUsed> tag. <locationUsed> tag. See Section 8.3.1 for more details.
8. Mapping a Location and Service to URLs: <findService> 8. Mapping a Location and Service to URLs: <findService>
8.1. Overview 8.1. Overview
The <findService> query constitutes the core of the LoST The <findService> query constitutes the core of the LoST
functionality, mapping civic or geodetic locations to URLs and functionality, mapping civic or geodetic locations to URLs and
associated data. After giving an example, we enumerate the elements associated data. After giving an example, we enumerate the elements
of the query and response. of the query and response.
skipping to change at page 19, line 41 skipping to change at page 19, line 41
<via source="esgw.ueber-110.de.example"/> <via source="esgw.ueber-110.de.example"/>
<via source="polizei.muenchen.de.example"/> <via source="polizei.muenchen.de.example"/>
</path> </path>
<locationUsed id="627b8bf819d0bad4d"/> <locationUsed id="627b8bf819d0bad4d"/>
</findServiceResponse> </findServiceResponse>
Figure 5: A <findServiceResponse> civic address answer Figure 5: A <findServiceResponse> civic address answer
8.3. Components of the <findService> Request 8.3. Components of the <findService> Request
The <findService> request includes attributes that govern whether the The <findService> request includes attributes and elements that
request is handled iteratively or recursively, whether location govern whether the request is handled iteratively or recursively,
validation is performed and which elements may be contained in the whether location validation is performed and which elements may be
response. contained in the response.
8.3.1. The <location> Element 8.3.1. The <location> Element
The <findService> query communicates location information using one The <findService> query communicates location information using one
or more <location> elements, which MUST conform to a location profile or more <location> elements, which MUST conform to a location profile
(see Section 12). There MUST NOT be more than one location element (see Section 12). There MUST NOT be more than one location element
for each distinct location profile. The order of location elements for each distinct location profile. The order of location elements
is significant; the server uses the first location element where it is significant; the server uses the first location element where it
understands the location profile. understands the location profile.
skipping to change at page 27, line 42 skipping to change at page 27, line 42
urn:service:sos.animal-control urn:service:sos.animal-control
urn:service:sos.fire urn:service:sos.fire
urn:service:sos.gas urn:service:sos.gas
urn:service:sos.mountain urn:service:sos.mountain
urn:service:sos.marine urn:service:sos.marine
urn:service:sos.physician urn:service:sos.physician
urn:service:sos.poison urn:service:sos.poison
urn:service:sos.police urn:service:sos.police
urn:service:sos.suicide urn:service:sos.suicide
</serviceList> </serviceList>
<path>
<via source="resolver.example"/>
<via source="authoritative.example"/>
</path>
</listServicesResponse> </listServicesResponse>
Figure 13: Example of <ListServiceResponse> Figure 13: Example of <ListServiceResponse>
11. List Services By Location: <listServicesByLocation> 11. List Services By Location: <listServicesByLocation>
A LoST client can ask a LoST server for the list of services it knows A LoST client can ask a LoST server for the list of services it knows
about for a particular area. The <listServicesByLocation> query about for a particular area. The <listServicesByLocation> query
contains one or more <location> elements, each from a different contains one or more <location> elements, each from a different
location profile (Section 12), and may contain the <service> element. location profile (Section 12), and may contain the <service> element.
skipping to change at page 30, line 15 skipping to change at page 30, line 15
12. Location Profiles 12. Location Profiles
LoST uses location information in <location> elements in requests and LoST uses location information in <location> elements in requests and
<serviceBoundary> elements in responses. Such location information <serviceBoundary> elements in responses. Such location information
may be expressed in a variety of ways. This variety can cause may be expressed in a variety of ways. This variety can cause
interoperability problems where a request or response contains interoperability problems where a request or response contains
location information in a format not understood by the server or the location information in a format not understood by the server or the
client, respectively. To achieve interoperability, this document client, respectively. To achieve interoperability, this document
defines two mandatory-to-implement baseline location profiles to defines two mandatory-to-implement baseline location profiles to
define the manner in which location information is transmitted. It define the manner in which location information is transmitted. It
is possible to standardize other profiles in the future. The three is possible to standardize other profiles in the future. The
baseline profiles are: baseline profiles are:
geodetic-2d: geodetic-2d:
a profile for two-dimensional geodetic location information, as a profile for two-dimensional geodetic location information, as
described in Section 12.2; described in Section 12.2;
civic: civic:
a profile consisting of civic address location information, as a profile consisting of civic address location information, as
skipping to change at page 33, line 12 skipping to change at page 33, line 12
This is possible because both Client X and Server Y understand the This is possible because both Client X and Server Y understand the
baseline profile. baseline profile.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findService <findService
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:gml="http://www.opengis.net/gml" xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gs="http://www.opengis.net/pidflo/1.0"
recursive="true" recursive="true"
serviceBoundary="value"> serviceBoundary="value">
<location profile="not-yet-standardized-prism-profile"> <location id="ABC 123"
profile="not-yet-standardized-prism-profile">
<gs:Prism srsName="urn:ogc:def:crs:EPSG::4979"> <gs:Prism srsName="urn:ogc:def:crs:EPSG::4979">
<gs:base> <gs:base>
<gml:Polygon> <gml:Polygon>
<gml:exterior> <gml:exterior>
<gml:LinearRing> <gml:LinearRing>
<gml:posList> <gml:posList>
42.556844 -73.248157 36.6 42.556844 -73.248157 36.6
42.656844 -73.248157 36.6 42.656844 -73.248157 36.6
42.656844 -73.348157 36.6 42.656844 -73.348157 36.6
42.556844 -73.348157 36.6 42.556844 -73.348157 36.6
skipping to change at page 33, line 34 skipping to change at page 33, line 35
</gml:posList> </gml:posList>
</gml:LinearRing> </gml:LinearRing>
</gml:exterior> </gml:exterior>
</gml:Polygon> </gml:Polygon>
</gs:base> </gs:base>
<gs:height uom="urn:ogc:def:uom:EPSG::9001"> <gs:height uom="urn:ogc:def:uom:EPSG::9001">
2.4 2.4
</gs:height> </gs:height>
</gs:Prism> </gs:Prism>
</location> </location>
<location profile="geodetic-2d"> <location id="DEF 345" profile="geodetic-2d">
<gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <gml:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<gml:pos>42.656844 -73.348157</gml:pos> <gml:pos>42.656844 -73.348157</gml:pos>
</gml:Point> </gml:Point>
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 16: Example of a <findServices> query with baseline profile Figure 16: Example of a <findServices> query with baseline profile
interoperability interoperability
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
skipping to change at page 34, line 31 skipping to change at page 34, line 31
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos> <p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos> <p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos> <p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos> <p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing> </p2:LinearRing>
</p2:exterior> </p2:exterior>
</p2:Polygon> </p2:Polygon>
</serviceBoundary> </serviceBoundary>
<uri>sip:nypd@example.com</uri> <uri>sip:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</mapping> </mapping>
<path> <path>
<via source="resolver.example"/> <via source="resolver.example"/>
<via source="authoritative.example"/> <via source="authoritative.example"/>
</path> </path>
<locationUsed id="6020688f1ce1896d"/> <locationUsed id="6020688f1ce1896d"/>
</findServiceResponse> </findServiceResponse>
Figure 17: Example of a <findServiceResponse> message with baseline Figure 17: Example of a <findServiceResponse> message with baseline
profile interoperability profile interoperability
skipping to change at page 42, line 26 skipping to change at page 42, line 26
POST method. The HTTP request MUST use the Cache-Control response POST method. The HTTP request MUST use the Cache-Control response
directive "no-cache" to HTTP-level "caching even by caches that have directive "no-cache" to HTTP-level "caching even by caches that have
been configured to return stale responses to client requests." been configured to return stale responses to client requests."
All LoST responses, including those indicating a LoST warning or All LoST responses, including those indicating a LoST warning or
error, are carried in 2xx responses, typically 200 (OK). Other 2xx error, are carried in 2xx responses, typically 200 (OK). Other 2xx
responses, in particular 203 (Non-authoritative information) may be responses, in particular 203 (Non-authoritative information) may be
returned by HTTP caches that disregard the caching instructions. 3xx, returned by HTTP caches that disregard the caching instructions. 3xx,
4xx and 5xx HTTP response codes indicates that the HTTP request 4xx and 5xx HTTP response codes indicates that the HTTP request
itself failed or was redirected; these responses do not contain any itself failed or was redirected; these responses do not contain any
LoST XML elements. LoST XML elements. The 3xx responses are distinct from the redirects
which are described in Section 13.3; the 13.3 redirects occur after a
LoST server processes the request. Where an HTTP-layer redirect will
be general, a LoST server redirect as described in 13.3 might be
specific to a specific service or be the result of other processing
by the LoST server.
The HTTP URL is derived from the LoST server name via U-NAPTR The HTTP URL is derived from the LoST server name via U-NAPTR
application, as discussed above. application, as discussed above.
15. Relax NG Schema 15. Relax NG Schema
This section provides the Relax NG schema used by LoST protocol in This section provides the Relax NG schema used by LoST protocol in
the compact form. The verbose form is included in Appendix A. the compact form. The verbose form is included in Appendix A.
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
skipping to change at page 43, line 38 skipping to change at page 43, line 38
| getServiceBoundaryResponse | getServiceBoundaryResponse
| errors | errors
| redirect | redirect
## ##
## The queries. ## The queries.
## ##
div { div {
findService = findService =
element findService { element findService {
element location { locationInformation }+, requestLocation,
commonRequestPattern, commonRequestPattern,
attribute validateLocation { attribute validateLocation {
xsd:boolean >> a:defaultValue [ "false" ] xsd:boolean >> a:defaultValue [ "false" ]
}?, }?,
attribute serviceBoundary { attribute serviceBoundary {
("reference" | "value") >> a:defaultValue [ "reference" ] ("reference" | "value") >> a:defaultValue [ "reference" ]
}?, }?,
attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }? attribute recursive { xsd:boolean >> a:defaultValue [ "false" ] }?
} }
listServices = element listServices { commonRequestPattern } listServices = element listServices { commonRequestPattern }
listServicesByLocation = listServicesByLocation =
element listServicesByLocation { element listServicesByLocation {
element location { locationInformation }*, requestLocation,
commonRequestPattern, commonRequestPattern,
attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }? attribute recursive { xsd:boolean >> a:defaultValue [ "true" ] }?
} }
getServiceBoundary = getServiceBoundary =
element getServiceBoundary { serviceBoundaryKey, extensionPoint } element getServiceBoundary { serviceBoundaryKey, extensionPoint }
} }
## ##
## The responses. ## The responses.
## ##
div { div {
findServiceResponse = findServiceResponse =
element findServiceResponse { element findServiceResponse {
mapping+, locationValidation?, commonResponsePattern mapping+, locationValidation?, commonResponsePattern, locationUsed
} }
listServicesResponse = listServicesResponse =
element listServicesResponse { serviceList, commonResponsePattern } element listServicesResponse { serviceList, commonResponsePattern }
listServicesByLocationResponse = listServicesByLocationResponse =
element listServicesByLocationResponse { element listServicesByLocationResponse {
serviceList, commonResponsePattern serviceList, commonResponsePattern, locationUsed
} }
getServiceBoundaryResponse = getServiceBoundaryResponse =
element getServiceBoundaryResponse { element getServiceBoundaryResponse {
serviceBoundary, commonResponsePattern serviceBoundary, commonResponsePattern
} }
} }
## ##
## A pattern common to some of the queries. ## A pattern common to some of the queries.
## ##
skipping to change at page 44, line 48 skipping to change at page 44, line 48
} }
## ##
## A pattern common to responses. ## A pattern common to responses.
## ##
div { div {
commonResponsePattern = warnings*, path, extensionPoint commonResponsePattern = warnings*, path, extensionPoint
} }
## ##
## Location in Requests
##
div {
requestLocation =
element location {
attribute id { xsd:token },
locationInformation
}+
}
##
## Location Information ## Location Information
## ##
div { div {
locationInformation = locationInformation =
extensionPoint+, extensionPoint+,
attribute profile { xsd:NMTOKEN }? attribute profile { xsd:NMTOKEN }?
} }
## ##
## Service Boundary ## Service Boundary
skipping to change at page 45, line 39 skipping to change at page 45, line 50
## places through which information flowed ## places through which information flowed
## ##
div { div {
path = path =
element path { element path {
element via { source, extensionPoint }+ element via { source, extensionPoint }+
} }
} }
## ##
## Location Used
##
div {
locationUsed =
element locationUsed {
attribute id { xsd:token }
}?
}
##
## Expires pattern ## Expires pattern
## ##
div { div {
expires = expires =
attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" } attribute expires { xsd:dateTime | "NO-CACHE" | "NO-EXPIRATION" }
} }
## ##
## A QName list ## A QName list
## ##
skipping to change at page 46, line 19 skipping to change at page 46, line 41
mapping = mapping =
element mapping { element mapping {
element displayName { element displayName {
xsd:string, xsd:string,
attribute xml:lang { xsd:language } attribute xml:lang { xsd:language }
}*, }*,
service, service,
(serviceBoundary | serviceBoundaryReference)?, (serviceBoundary | serviceBoundaryReference)?,
element uri { xsd:anyURI }*, element uri { xsd:anyURI }*,
element serviceNumber { element serviceNumber {
xsd:string { pattern = "[0-9*#]+" } xsd:token { pattern = "[0-9*#]+" }
}?, }?,
extensionPoint, extensionPoint,
expires, expires,
attribute lastUpdated { xsd:dateTime }, attribute lastUpdated { xsd:dateTime },
source, source,
attribute sourceId { xsd:token }, attribute sourceId { xsd:token },
message message
} }
} }
skipping to change at page 48, line 21 skipping to change at page 48, line 44
message, message,
extensionPoint extensionPoint
} }
} }
## ##
## Some common patterns. ## Some common patterns.
## ##
div { div {
message = message =
(attribute message { xsd:string }, (attribute message { xsd:token },
attribute xml:lang { xsd:language })? attribute xml:lang { xsd:language })?
service = element service { xsd:anyURI }? service = element service { xsd:anyURI }?
appUniqueString = appUniqueString =
xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" } xsd:token { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
source = attribute source { appUniqueString } source = attribute source { appUniqueString }
serviceList = serviceList =
element serviceList { element serviceList {
list { xsd:anyURI* } list { xsd:anyURI* }
} }
} }
## ##
## Patterns for inclusion of elements from schemas in ## Patterns for inclusion of elements from schemas in
## other namespaces. ## other namespaces.
skipping to change at page 53, line 11 skipping to change at page 53, line 11
This specification is a work item of the IETF ECRIT working group, This specification is a work item of the IETF ECRIT working group,
with mailing list address <ecrit@ietf.org>. with mailing list address <ecrit@ietf.org>.
Change controller: Change controller:
The IESG <iesg@ietf.org> The IESG <iesg@ietf.org>
17.3. LoST Relax NG Schema Registration 17.3. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:lost1 URI: urn:ietf:params:xml:schema:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@nsn.com). (Hannes.Tschofenig@nsn.com).
Relax NG Schema: The Relax NG schema to be registered is contained Relax NG Schema: The Relax NG schema to be registered is contained
in Section 15. Its first line is in Section 15. Its first line is
default namespace = "urn:ietf:params:xml:ns:lost1" default namespace = "urn:ietf:params:xml:ns:lost1"
and its last line is and its last line is
skipping to change at page 55, line 16 skipping to change at page 55, line 16
There are several threats to the overall system of which service There are several threats to the overall system of which service
mapping forms a part. An attacker that can obtain service contact mapping forms a part. An attacker that can obtain service contact
URIs can use those URIs to attempt to disrupt those services. An URIs can use those URIs to attempt to disrupt those services. An
attacker that can prevent the lookup of contact URIs can impair the attacker that can prevent the lookup of contact URIs can impair the
reachability of such services. An attacker that can eavesdrop on the reachability of such services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an communication requesting this lookup can surmise the existence of an
emergency and possibly its nature, and may be able to use this to emergency and possibly its nature, and may be able to use this to
launch a physical attack on the caller. launch a physical attack on the caller.
To avoid that an attacker can modify the query or its result, the use To avoid that an attacker can modify the query or its result, TLS
of channel security, such as TLS, is RECOMMENDED. MUST be implemented and SHOULD be used. Use is RECOMMENDED both for
clients' queries to servers and for queries among servers; this
latter recommendation is to help avoid cache poisoning attacks by
replacing answers given to caching servers. The use of server
identity checks is also RECOMMENDED, as described in [4]
Generally, authentication and authorization is not required for Generally, authentication and authorization is not required for
mapping queries. If it is, authentication mechanism of the mapping queries. If it is, authentication mechanism of the
underlying transport mechanism, such as HTTP basic and digest underlying transport mechanism, such as HTTP basic and digest
authentication, MAY be used. (Basic authentication SHOULD only be authentication, MAY be used. (Basic authentication SHOULD only be
used in combination with TLS.) used in combination with TLS.)
A more detailed description of threats and security requirements are A more detailed description of threats and security requirements are
provided in [17]. provided in [17].
skipping to change at page 58, line 5 skipping to change at page 57, line 51
o Wonsang Song o Wonsang Song
o Jong-Yul Kim o Jong-Yul Kim
o Anna Makarowska o Anna Makarowska
o Krzysztof Rzecki o Krzysztof Rzecki
o Blaszczyk Piotr o Blaszczyk Piotr
We would like to thank Jon Peterson for his IESG review comments.
20. References 20. References
20.1. Normative References 20.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
skipping to change at page 58, line 35 skipping to change at page 58, line 35
[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] Freed, N. and J. Klensin, "Media Type Specifications and [7] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Daigle, L., "Domain-Based Application Service Location Using [8] Daigle, L., "Domain-Based Application Service Location Using
URIs and the Dynamic Delegation Discovery Service (DDDS)", URIs and the Dynamic Delegation Discovery Service (DDDS)",
RFC 4848, April 2007. RFC 4848, April 2007.
[9] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [9] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
draft-ietf-ecrit-service-urn-06 (work in progress), March 2007. and Other Well-Known Services", draft-ietf-ecrit-service-urn-07
(work in progress), August 2007.
[10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [10] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-05 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-07 (work in
progress), February 2007. progress), December 2007.
[11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside, [11] Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
"Geographic information - Geography Markup Language (GML)", OGC "Geographic information - Geography Markup Language (GML)", OGC
Standard OpenGIS 03-105r1, April 2004. Standard OpenGIS 03-105r1, April 2004.
[12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application [12] Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
Schema for use by the Internet Engineering Task Force (IETF)", Schema for use by the Internet Engineering Task Force (IETF)",
Candidate OpenGIS Implementation Specification , December 2006. Candidate OpenGIS Implementation Specification , December 2006.
20.2. Informative References 20.2. Informative References
[13] Tschofenig, H., "GEOPRIV PIDF-LO Usage Clarification, [13] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Considerations and Recommendations", PIDF-LO Usage Clarification, Considerations and
draft-ietf-geopriv-pdif-lo-profile-08 (work in progress), Recommendations", draft-ietf-geopriv-pdif-lo-profile-10 (work
July 2007. in progress), October 2007.
[14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [14] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[15] Saint-Andre, P., Ed., "Extensible Messaging and Presence [15] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC 3921, Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
October 2004. October 2004.
[16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. December 2004.
[17] Taylor, T., "Security Threats and Requirements for Emergency [17] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-ietf-ecrit-security-threats-04 Call Marking and Mapping", draft-ietf-ecrit-security-threats-05
(work in progress), April 2007. (work in progress), August 2007.
[18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [18] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-13 (work in progress), draft-ietf-ecrit-requirements-13 (work in progress),
March 2007. March 2007.
[19] Schulzrinne, H., "Location-to-URL Mapping Architecture and [19] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-02 (work in Framework", draft-ietf-ecrit-mapping-arch-03 (work in
progress), July 2007. progress), September 2007.
[20] Rosen, B. and J. Polk, "Best Current Practice for [20] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Communications Services in support of Emergency Calling",
draft-ietf-ecrit-phonebcp-01 (work in progress), March 2007. draft-ietf-ecrit-phonebcp-03 (work in progress), November 2007.
URIs
[21] <http://www.tschofenig.com/svn/draft-ietf-ecrit-lost/RelaxNG>
Appendix A. Non-Normative RELAX NG Schema in XML Syntax Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost1" <grammar ns="urn:ietf:params:xml:ns:lost1"
xmlns="http://relaxng.org/ns/structure/1.0" xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0" xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes"> datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start> <start>
skipping to change at page 60, line 42 skipping to change at page 61, line 42
</choice> </choice>
</start> </start>
<div> <div>
<a:documentation> <a:documentation>
The queries. The queries.
</a:documentation> </a:documentation>
<define name="findService"> <define name="findService">
<element name="findService"> <element name="findService">
<oneOrMore> <ref name="requestLocation" />
<element name="location">
<ref name="locationInformation" />
</element>
</oneOrMore>
<ref name="commonRequestPattern" /> <ref name="commonRequestPattern" />
<optional> <optional>
<attribute name="validateLocation"> <attribute name="validateLocation">
<data type="boolean" /> <data type="boolean" />
<a:defaultValue>false</a:defaultValue> <a:defaultValue>false</a:defaultValue>
</attribute> </attribute>
</optional> </optional>
<optional> <optional>
<attribute name="serviceBoundary"> <attribute name="serviceBoundary">
<choice> <choice>
skipping to change at page 61, line 32 skipping to change at page 62, line 28
</define> </define>
<define name="listServices"> <define name="listServices">
<element name="listServices"> <element name="listServices">
<ref name="commonRequestPattern" /> <ref name="commonRequestPattern" />
</element> </element>
</define> </define>
<define name="listServicesByLocation"> <define name="listServicesByLocation">
<element name="listServicesByLocation"> <element name="listServicesByLocation">
<zeroOrMore> <ref name="requestLocation" />
<element name="location">
<ref name="locationInformation" />
</element>
</zeroOrMore>
<ref name="commonRequestPattern" /> <ref name="commonRequestPattern" />
<optional> <optional>
<attribute name="recursive"> <attribute name="recursive">
<data type="boolean" /> <data type="boolean" />
<a:defaultValue>true</a:defaultValue> <a:defaultValue>true</a:defaultValue>
</attribute> </attribute>
</optional> </optional>
</element> </element>
</define> </define>
skipping to change at page 62, line 12 skipping to change at page 63, line 4
<ref name="extensionPoint" /> <ref name="extensionPoint" />
</element> </element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
The responses. The responses.
</a:documentation> </a:documentation>
<define name="findServiceResponse"> <define name="findServiceResponse">
<element name="findServiceResponse"> <element name="findServiceResponse">
<oneOrMore> <oneOrMore>
<ref name="mapping" /> <ref name="mapping" />
</oneOrMore> </oneOrMore>
<optional> <optional>
<ref name="locationValidation" /> <ref name="locationValidation" />
</optional> </optional>
<ref name="commonResponsePattern" /> <ref name="commonResponsePattern" />
<ref name="locationUsed" />
</element> </element>
</define> </define>
<define name="listServicesResponse"> <define name="listServicesResponse">
<element name="listServicesResponse"> <element name="listServicesResponse">
<ref name="serviceList" /> <ref name="serviceList" />
<ref name="commonResponsePattern" /> <ref name="commonResponsePattern" />
</element> </element>
</define> </define>
<define name="listServicesByLocationResponse"> <define name="listServicesByLocationResponse">
<element name="listServicesByLocationResponse"> <element name="listServicesByLocationResponse">
<ref name="serviceList" /> <ref name="serviceList" />
<ref name="commonResponsePattern" /> <ref name="commonResponsePattern" />
<ref name="locationUsed" />
</element> </element>
</define> </define>
<define name="getServiceBoundaryResponse"> <define name="getServiceBoundaryResponse">
<element name="getServiceBoundaryResponse"> <element name="getServiceBoundaryResponse">
<ref name="serviceBoundary"/> <ref name="serviceBoundary"/>
<ref name="commonResponsePattern" /> <ref name="commonResponsePattern" />
</element> </element>
</define> </define>
skipping to change at page 63, line 33 skipping to change at page 64, line 25
<zeroOrMore> <zeroOrMore>
<ref name="warnings" /> <ref name="warnings" />
</zeroOrMore> </zeroOrMore>
<ref name="path" /> <ref name="path" />
<ref name="extensionPoint" /> <ref name="extensionPoint" />
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Location in Requests
</a:documentation>
<define name="requestLocation">
<oneOrMore>
<element name="location">
<attribute name="id" >
<data type="token" />
</attribute>
<ref name="locationInformation" />
</element>
</oneOrMore>
</define>
</div>
<div>
<a:documentation>
Location Information Location Information
</a:documentation> </a:documentation>
<define name="locationInformation"> <define name="locationInformation">
<oneOrMore> <oneOrMore>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
</oneOrMore> </oneOrMore>
<optional> <optional>
<attribute name="profile"> <attribute name="profile">
<data type="NMTOKEN" /> <data type="NMTOKEN" />
skipping to change at page 65, line 8 skipping to change at page 66, line 18
<ref name="source" /> <ref name="source" />
<ref name="extensionPoint" /> <ref name="extensionPoint" />
</element> </element>
</oneOrMore> </oneOrMore>
</element> </element>
</define> </define>
</div> </div>
<div> <div>
<a:documentation> <a:documentation>
Location Used
</a:documentation>
<define name="locationUsed">
<optional>
<element name="locationUsed">
<attribute name="id">
<data type="token" />
</attribute>
</element>
</optional>
</define>
</div>
<div>
<a:documentation>
Expires pattern Expires pattern
</a:documentation> </a:documentation>
<define name="expires"> <define name="expires">
<attribute name="expires"> <attribute name="expires">
<choice> <choice>
<data type="dateTime"/> <data type="dateTime"/>
<value>NO-CACHE</value> <value>NO-CACHE</value>
<value>NO-EXPIRATION</value> <value>NO-EXPIRATION</value>
</choice> </choice>
skipping to change at page 66, line 17 skipping to change at page 67, line 42
<ref name="serviceBoundaryReference"/> <ref name="serviceBoundaryReference"/>
</choice> </choice>
</optional> </optional>
<zeroOrMore> <zeroOrMore>
<element name="uri"> <element name="uri">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
</zeroOrMore> </zeroOrMore>
<optional> <optional>
<element name="serviceNumber"> <element name="serviceNumber">
<data type="string"> <data type="token">
<param name="pattern">[0-9*#]+</param> <param name="pattern">[0-9*#]+</param>
</data> </data>
</element> </element>
</optional> </optional>
<ref name="extensionPoint"/> <ref name="extensionPoint"/>
<ref name="expires"/> <ref name="expires"/>
<attribute name="lastUpdated"> <attribute name="lastUpdated">
<data type="dateTime"/> <data type="dateTime"/>
</attribute> </attribute>
<ref name="source" /> <ref name="source" />
skipping to change at page 67, line 33 skipping to change at page 69, line 10
<optional> <optional>
<ref name="badRequest" /> <ref name="badRequest" />
</optional> </optional>
<optional> <optional>
<ref name="internalError" /> <ref name="internalError" />
</optional> </optional>
<optional> <optional>
<ref name="serviceSubstitution" /> <ref name="serviceSubstitution" />
</optional> </optional>
<optional> <optional>
<ref name="defaultMappingReturned" />
</optional>
<optional>
<ref name="forbidden" /> <ref name="forbidden" />
</optional> </optional>
<optional> <optional>
<ref name="notFound" /> <ref name="notFound" />
</optional> </optional>
<optional> <optional>
<ref name="loop" /> <ref name="loop" />
</optional> </optional>
<optional> <optional>
<ref name="serviceNotImplemented" /> <ref name="serviceNotImplemented" />
skipping to change at page 69, line 4 skipping to change at page 70, line 30
<element name="badRequest"> <element name="badRequest">
<ref name="basicException"/> <ref name="basicException"/>
</element> </element>
</define> </define>
<define name="internalError"> <define name="internalError">
<element name="internalError"> <element name="internalError">
<ref name="basicException"/> <ref name="basicException"/>
</element> </element>
</define> </define>
<define name="serviceSubstitution"> <define name="serviceSubstitution">
<element name="serviceSubstitution"> <element name="serviceSubstitution">
<ref name="basicException"/> <ref name="basicException"/>
</element> </element>
</define> </define>
<define name="defaultMappingReturned">
<element name="defaultMappingReturned">
<ref name="basicException"/>
</element>
</define>
<define name="forbidden"> <define name="forbidden">
<element name="forbidden"> <element name="forbidden">
<ref name="basicException"/> <ref name="basicException"/>
</element> </element>
</define> </define>
<define name="notFound"> <define name="notFound">
<element name="notFound"> <element name="notFound">
<ref name="basicException"/> <ref name="basicException"/>
</element> </element>
skipping to change at page 70, line 51 skipping to change at page 72, line 36
<div> <div>
<a:documentation> <a:documentation>
Some common patterns. Some common patterns.
</a:documentation> </a:documentation>
<define name="message"> <define name="message">
<optional> <optional>
<group> <group>
<attribute name="message"> <attribute name="message">
<data type="string"/> <data type="token"/>
</attribute> </attribute>
<attribute name="xml:lang"> <attribute name="xml:lang">
<data type="language"/> <data type="language"/>
</attribute> </attribute>
</group> </group>
</optional> </optional>
</define> </define>
<define name="service"> <define name="service">
<optional> <optional>
skipping to change at page 71, line 19 skipping to change at page 73, line 4
</optional> </optional>
</define> </define>
<define name="service"> <define name="service">
<optional> <optional>
<element name="service"> <element name="service">
<data type="anyURI"/> <data type="anyURI"/>
</element> </element>
</optional> </optional>
</define> </define>
<define name="appUniqueString"> <define name="appUniqueString">
<data type="string"> <data type="token">
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param> <param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
</data> </data>
</define> </define>
<define name="source"> <define name="source">
<attribute name="source"> <attribute name="source">
<ref name="appUniqueString" /> <ref name="appUniqueString" />
</attribute> </attribute>
</define> </define>
skipping to change at page 73, line 4 skipping to change at page 74, line 35
can be added. can be added.
</a:documentation> </a:documentation>
<zeroOrMore> <zeroOrMore>
<ref name="notLost" /> <ref name="notLost" />
</zeroOrMore> </zeroOrMore>
</define> </define>
</div> </div>
</grammar> </grammar>
Figure 25 Figure 25
Appendix B. Examples On-line
The XML examples and Relax NG schemas may be found on-line [21].
Authors' Addresses Authors' Addresses
Ted Hardie Ted Hardie
Qualcomm, Inc. Qualcomm, Inc.
Email: hardie@qualcomm.com Email: hardie@qualcomm.com
Andrew Newton Andrew Newton
TranTech, Inc. American Registry for Internet Numbers
4900 Seminary Road, Suite 215 3635 Concorde Parkway, Suite 200
Alexandria, VA 22311 Chantilly, VA 20151
US US
Phone: +1 703 671 9873 Phone: +1 703 227 9894
Email: andy@hxr.us Email: andy@hxr.us
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
Department of Computer Science Department of Computer Science
450 Computer Science Building 450 Computer Science Building
New York, NY 10027 New York, NY 10027
US US
Phone: +1 212 939 7004 Phone: +1 212 939 7004
Email: hgs+ecrit@cs.columbia.edu Email: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu URI: http://www.cs.columbia.edu
Hannes Tschofenig Hannes Tschofenig
Nokia Siemens Networks Nokia Siemens Networks
Otto-Hahn-Ring 6 Linnoitustie 6
Munich, Bavaria 81739 Espoo 02600
Germany Finland
Phone: +49 89 636 40390 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@nsn.com Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 57 change blocks. 
82 lines changed or deleted 168 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/