draft-ietf-ecrit-lost-03.txt   draft-ietf-ecrit-lost-04.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: July 21, 2007 SunRocket Expires: August 15, 2007 SunRocket
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
H. Tschofenig H. Tschofenig
Siemens Networks GmbH & Co KG Siemens Networks GmbH & Co KG
January 17, 2007 February 11, 2007
LoST: A Location-to-Service Translation Protocol LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-03.txt draft-ietf-ecrit-lost-04.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 39
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 July 21, 2007. This Internet-Draft will expire on August 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and Requirements Notation . . . . . . . . . . . . 6 2. Terminology and Requirements Notation . . . . . . . . . . . . 6
3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7 3. Overview of Protocol Usage . . . . . . . . . . . . . . . . . . 7
4. LoST Uniform Resource Locators and Their Resolution . . . . . 8 4. LoST servers and Their Resolution . . . . . . . . . . . . . . 8
5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 9 5. The <mapping> Element . . . . . . . . . . . . . . . . . . . . 9
5.1. Data source and version: The 'source', 'sourceId' and 5.1. Data source and version: The 'source', 'sourceId' and
'version' Attributes . . . . . . . . . . . . . . . . . . . 9 'version' Attributes . . . . . . . . . . . . . . . . . . . 9
5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9 5.2. Time of Last Update: The 'lastUpdated' Attribute . . . . . 9
5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9 5.3. Validity: The 'expires' Attribute . . . . . . . . . . . . 9
5.4. Describing the Service with the <displayName> Element . . 10 5.4. Describing the Service with the <displayName> Element . . 10
5.5. The Mapped Service: the <service> Element . . . . . . . . 10 5.5. The Mapped Service: the <service> Element . . . . . . . . 10
5.6. Defining the Service Region with the <serviceBoundary> 5.6. Defining the Service Region with the <serviceBoundary>
Element . . . . . . . . . . . . . . . . . . . . . . . . . 10 Element . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.7. Service Boundaries by Reference: the 5.7. Service Boundaries by Reference: the
<serviceBoundaryReference> Element . . . . . . . . . . . . 11 <serviceBoundaryReference> Element . . . . . . . . . . . . 11
5.8. The Service Number . . . . . . . . . . . . . . . . . . . . 11 5.8. The Service Number Element . . . . . . . . . . . . . . . . 11
5.9. Service URLs: the <uri> Element . . . . . . . . . . . . . 11 5.9. Service URLs: the <uri> Element . . . . . . . . . . . . . 12
6. Path of Request: <path> Element . . . . . . . . . . . . . . . 12 6. Path of Request: <path> Element . . . . . . . . . . . . . . . 13
7. Mapping a Location and Service to URLs: <findService> . . . . 13 7. Mapping a Location and Service to URLs: <findService> . . . . 14
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 13 7.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 13 7.2.1. Example Using Geodetic Coordinates . . . . . . . . . . 14
7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 14 7.2.2. Civic Address Mapping Example . . . . . . . . . . . . 15
7.3. Components of the <findService> Request . . . . . . . . . 16 7.3. Components of the <findService> Request . . . . . . . . . 17
7.3.1. The <location> Element . . . . . . . . . . . . . . . . 16 7.3.1. The <location> Element . . . . . . . . . . . . . . . . 17
7.3.2. Identifying the Service: The <service> Element . . . 17 7.3.2. Identifying the Service: The <service> Element . . . 18
7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 17 7.3.3. Recursion . . . . . . . . . . . . . . . . . . . . . . 18
7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 17 7.3.4. Service Boundary . . . . . . . . . . . . . . . . . . . 18
7.3.5. Requesting Civic Location Validation . . . . . . . . . 17 7.3.5. Requesting Civic Location Validation . . . . . . . . . 18
7.4. Components of the Mapping Response 7.4. Components of the Mapping Response
<findServiceResponse> . . . . . . . . . . . . . . . . . . 19 <findServiceResponse> . . . . . . . . . . . . . . . . . . 20
7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 19 7.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 20
7.4.2. Civic Address Validation: the 7.4.2. Civic Address Validation: the
<locationValidation> Element . . . . . . . . . . . . . 20 <locationValidation> Element . . . . . . . . . . . . . 21
8. Retrieving the Service Boundary via <getServiceBoundary> . . . 21 8. Retrieving the Service Boundary via <getServiceBoundary> . . . 22
9. List Services: <listServices> . . . . . . . . . . . . . . . . 24 9. List Services: <listServices> . . . . . . . . . . . . . . . . 25
10. List Services By Location: <listServicesByLocation> . . . . . 25 10. List Services By Location: <listServicesByLocation> . . . . . 26
11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 27 11. Location Profiles . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 28 11.1. Location Profile Usage . . . . . . . . . . . . . . . . . . 29
11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 30 11.2. Two Dimensional Geodetic Profile . . . . . . . . . . . . . 32
11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 31 11.3. Basic Civic Profile . . . . . . . . . . . . . . . . . . . 33
12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 32 12. Errors, Warnings, and Redirects . . . . . . . . . . . . . . . 34
12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 32 12.1. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 34
12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 33 12.2. Warnings . . . . . . . . . . . . . . . . . . . . . . . . . 35
12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 34 12.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 36
13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 35 13. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 37
14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 36 14. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 38
15. Internationalization Considerations . . . . . . . . . . . . . 43 15. Internationalization Considerations . . . . . . . . . . . . . 45
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46
16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 44 16.1. U-NAPTR Registrations . . . . . . . . . . . . . . . . . . 46
16.2. Content-type registration for 'application/lost+xml' . . . 44 16.2. Content-type registration for 'application/lost+xml' . . . 46
16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 46 16.3. LoST Relax NG Schema Registration . . . . . . . . . . . . 48
16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 46 16.4. LoST Namespace Registration . . . . . . . . . . . . . . . 48
16.5. URL Registration Template . . . . . . . . . . . . . . . . 47 16.5. LoST Location Profile Registry . . . . . . . . . . . . . . 49
16.6. LoST Location Profile Registry . . . . . . . . . . . . . . 48 17. Security Considerations . . . . . . . . . . . . . . . . . . . 50
17. Security Considerations . . . . . . . . . . . . . . . . . . . 49 18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
18. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 53
19. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 52 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 20.1. Normative References . . . . . . . . . . . . . . . . . . . 54
20.1. Normative References . . . . . . . . . . . . . . . . . . . 53 20.2. Informative References . . . . . . . . . . . . . . . . . . 55
20.2. Informative References . . . . . . . . . . . . . . . . . . 54 Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 56
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 70
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 69 Intellectual Property and Copyright Statements . . . . . . . . . . 71
Intellectual Property and Copyright Statements . . . . . . . . . . 70
1. Introduction 1. Introduction
This document describes a protocol for mapping a service identifier This document describes a protocol for mapping a service identifier
[10] and location information compatible with PIDF-LO [8], namely [10] and location information compatible with PIDF-LO [7], namely
revised civic location information [11] and GML [13]) to one or more revised civic location information [11] and GML [13]) to one or more
service URL. Example service URL schemes include sip [14], xmpp service URL. Example service URL schemes include sip [14], xmpp
[15], and tel [16]. While the initial focus is on providing mapping [15], and tel [16]. While the initial focus is on providing mapping
functions for emergency services, it is likely that the protocol is functions for emergency services, it is likely that the protocol is
applicable to any service URN. For example, in the United States, applicable to any service URN. For example, in the United States,
the "2-1-1" and "3-1-1" service numbers follow a similar location-to- the "2-1-1" and "3-1-1" service numbers follow a similar location-to-
service behavior as emergency services. 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
skipping to change at page 4, line 36 skipping to change at page 4, line 36
location data to facilitate debugging and proper user feedback, but location data to facilitate debugging and proper user feedback, but
also provides best-effort answers. also provides best-effort answers.
LoST queries can be resolved recursively or iteratively. To minimize LoST queries can be resolved recursively or iteratively. To minimize
round trips and to provide robustness against network failures, LoST round trips and to provide robustness against network failures, LoST
caches individual mappings and indicates the region for which the caches individual mappings and indicates the region for which the
same answer would be returned ("service region"). same answer would be returned ("service region").
As defined in this document, LoST messages are carried in HTTP and As defined in this document, LoST messages are carried in HTTP and
HTTPS protocol exchanges, facilitating use of TLS for protecting the HTTPS protocol exchanges, facilitating use of TLS for protecting the
integrity and confidentiality of requests and responses. integrity and confidentiality of requests and responses. Later
documents may describe how LoST messages could be carried over other
transports.
This document focuses on the description of the protocol between the This document focuses on the description of the protocol between the
mapping client (seeker or resolver) and the mapping server (resolver mapping client and the mapping server. The relationship between
or other servers). The relationship between other functions, such as other functions, such as discovery of mapping servers, data
discovery of mapping servers, data replication and the overall replication and the overall mapping server architecture are described
mapping server architecture are described in a separate document in a separate document [19].
[19].
The query message carries location information and a service The query message carries location information and a service
identifier encoded as a Uniform Resource Name (URN) (see [10]) from identifier encoded as a Uniform Resource Name (URN) (see [10]) from
the LoST client to the LoST server. The LoST server uses its the LoST client to the LoST server. The LoST server uses its
database to map the input values to one or more Uniform Resource database to map the input values to one or more Uniform Resource
Identifiers (URI) and returns those URIs along with optional Identifiers (URI) and returns those URIs along with optional
information, such as hints about the service boundary, in a response information, such as hints about the service boundary, in a response
message to the LoST client. If the server cannot resolve the query message to the LoST client. If the server cannot resolve the query
itself, it may in turn query another server or return the address of itself, it may in turn query another server or return the address of
another LoST server, identified by a LoST URL (Section 4). In another LoST server, identified by a LoST server name. In addition
addition to the mapping function described in Section 7, the protocol to the mapping function described in Section 7, the protocol also
also allows to retrieve the service boundary (see Section 8) and to allows to retrieve the service boundary (see Section 8) and to list
list the services available for a particular location (see the services available for a particular location (see Section 10) or
Section 10) or supported by a particular server (see Section 9). supported by a particular server (see Section 9).
2. Terminology and Requirements Notation 2. Terminology and Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [1]. document are to be interpreted as described in [1].
This document furthermore uses the terminology defined in [18]. This document furthermore uses the terminology defined in [18].
3. Overview of Protocol Usage 3. Overview of Protocol Usage
skipping to change at page 8, line 5 skipping to change at page 8, line 5
omit requests for service boundaries or other auxiliary omit requests for service boundaries or other auxiliary
information. information.
A service-specific Best Current Practice (BCP) document, such as A service-specific Best Current Practice (BCP) document, such as
[20], governs whether a client is expected to invoke the mapping [20], governs whether a client is expected to invoke the mapping
service just before needing the service or whether to rely on cached service just before needing the service or whether to rely on cached
answers. Cache entries expire at their expiration time (see answers. Cache entries expire at their expiration time (see
Section 5.3), or they become invalid if the caller's device moves Section 5.3), or they become invalid if the caller's device moves
beyond the boundaries of the service region. beyond the boundaries of the service region.
4. LoST Uniform Resource Locators and Their Resolution 4. LoST servers and Their Resolution
LoST servers are identified by LoST Uniform Resource Locators (URLs),
which follow the format of URLs defined in RFC 3986 [7], with the
following ABNF:
LoST-URI = "lost:" host
'host' is defined in Section 3.2.2 of RFC 3986 [7]. A LoST server may be discovered using a U-NAPTR/DDDS [12] application
unique string (AUS), in the form of a DNS name.
An example is 'lost:lostserver.example.com' An example is 'lostserver.example.com'
If a LoST URL contains a host name rather than an IP address, clients Clients need to use the U-NAPTR [12] specification described below to
need to use U-NAPTR [12] using the U-NAPTR specification described obtain a URI (indicating host and protocol) for the applicable LoST
below to obtain a URI (indicating host and protocol) for the service. In this document, only the HTTP and HTTPS URL schemes are
applicable LoST service. In this document, only the HTTP and HTTPS defined. Note that the HTTP URL can be any valid HTTP URL, including
URL schemes are defined. Note that the HTTP URL can be any valid those containing path elements.
HTTP URL, including those containing path elements.
The following two DNS entries resolve the LoST URL "lost:example.com" The following two DNS entries show the U-NAPTR resolution for the AUS
to the HTTPS URL https://lostserv.example.com/secure or the HTTP URL "example.com" to the HTTPS URL https://lostserv.example.com/secure or
http://lostserver.example.com, with the former being preferred. the HTTP URL http://lostserver.example.com, with the former being
preferred.
example.com. example.com.
IN NAPTR 100 10 "u" "LoST:https" IN NAPTR 100 10 "u" "LoST:https"
"!*.!https://lostserver.example.com/secure!" "" "!*.!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http" IN NAPTR 200 10 "u" "LoST:http"
"!*.!http://lostserver.example.com!" "" "!*.!http://lostserver.example.com!" ""
Clients learn the LoST server's AUS by means beyond the scope of this
specification, such as SIP configuration and DHCP.
5. The <mapping> Element 5. The <mapping> Element
The <mapping> element is the core data element in LoST, describing a The <mapping> element is the core data element in LoST, describing a
service region and the associated service URLs. Its parameters service region and the associated service URLs. Its attributes and
indicate when the mapping was last updated, how long it is valid, its elements are described in subsections below.
version and the authoritative source for the mapping, along with a
unique identifier. Elements within the <mapping> element then
provide a human-readable description, the service URN, a service
boundary, the service URIs, and a service number. All elements
except the service URN are optional. Below, we describe the
components in turn.
5.1. Data source and version: The 'source', 'sourceId' and 'version' 5.1. Data source and version: The 'source', 'sourceId' and 'version'
Attributes Attributes
The 'source', 'sourceId' and 'version' attributes uniquely identify a The 'source', 'sourceId' and 'version' attributes uniquely identify a
particular mapping record. They are created by the authoritative particular mapping record. They are created by the authoritative
source for a mapping and never modified when a mapping is served from source for a mapping and never modified when a mapping is served from
a cache. The 'source' attribute contains a LoST URL identifying the a cache. All three attributes are REQUIRED for all <mapping>
authoritative generator of the mapping. The 'sourceId' attribute elements. A receiver can replace a mapping with another one having
identifies a particular mapping. The attribute contains a token, the same 'source' and 'sourceId' and a higher version number.
which is opaque, but MUST be unique among all different mappings
The 'source' attribute contains a LoST application unique string
identifying the authoritative generator of the mapping. See
Section 4.
The 'sourceId' attribute identifies a particular mapping and contains
an opaque token that MUST be unique among all different mappings
maintained by the authoritative source for that particular service. maintained by the authoritative source for that particular service.
For example, a UUID is a suitable format. The 'version' attribute is For example, a Universally Unique Identifier (UUID) is a suitable
a positive integer that is incremented by one for each change in the format.
mapping. Thus, a higher version number refers to a more recent
The 'version' attribute is a positive integer that is incremented for
each change in the mapping. The XML data type does not specify an
upper bound for this attribute and thus, the value MUST NOT wrap
around. Thus, a higher version number refers to a more recent
mapping. A mapping maintains its sourceId value as long as it mapping. A mapping maintains its sourceId value as long as it
remains logically the same, e.g., represents the same service remains logically the same, e.g., represents the same service
boundary or replaces an earlier service boundary. A receiver should boundary or replaces an earlier service boundary.
be able to replace a mapping with another one having the same
'source' and 'sourceId' and a higher version number. All three
attributes are REQUIRED for all <mapping> elements.
5.2. Time of Last Update: The 'lastUpdated' Attribute 5.2. Time of Last Update: The 'lastUpdated' Attribute
The 'lastUpdated' attribute describes when the mapping was last The 'lastUpdated' attribute describes when the mapping was last
changed. The contents of this attribute is a timezoned XML type changed. The contents of this attribute has the XML data type
dateTime, in canonical representation. The attribute is REQUIRED. dateTime in its timezoned form, using canonical UTC representation
with the letter 'Z' as the timezone indicator. The attribute is
REQUIRED.
5.3. Validity: The 'expires' Attribute 5.3. Validity: The 'expires' Attribute
The 'expires' attribute contains the absolute time until which the The 'expires' attribute contains the absolute time at which the
mapping is to be considered valid. The contents of this attribute is mapping becomes invalid. The contents of this attribute is a
a timezoned XML type dateTime, in canonical representation. See timezoned XML type dateTime, in canonical representation. See
Section 3 regarding how this value is to be utilized with a cache. Section 3 regarding how this value is to be utilized with a cache.
The 'expires' attribute is REQUIRED to be included in the <mapping> The 'expires' attribute is REQUIRED to be included in the <mapping>
element. element.
On occasion, a resolver 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. Seekers and resolvers MAY cache the mapping return a usable answer. Clients and servers MAY cache the mapping so
so that they have at least some information available. Resolvers that they have at least some information available. Caching servers
SHOULD re-attempt the query each time a seeker requests a mapping. that have such stale information SHOULD re-attempt the query each
time a client requests a mapping.
5.4. Describing the Service with the <displayName> Element 5.4. Describing the Service with the <displayName> Element
The <displayName> element describes the service with a string that is Zero or more <displayName> elements describe the service with a
suitable for display to human users, annotated with the 'xml:lang' string that is suitable for display to human users, each annotated
attribute that contains a language tag to aid in the rendering of with the 'xml:lang' attribute that contains a language tag to aid in
text. the rendering of text.
5.5. The Mapped Service: the <service> Element 5.5. The Mapped Service: the <service> Element
The 'service' element identifies the service for which this mapping The <service> element identifies the service for which this mapping
applies. It is usually the same service URN as in the request. applies. Two cases need to be distinguished when the LoST server
However, if the requested service, identified by the service URN [10] sets the <service> element in the response message:
in the <service> element in the request, does not exist for the
location indicated, the server can either return an 1. If the requested service, identified by the service URN [10] in
the <service> element of the request, exists for the location
indicated, then the LoST server puts the service URN from the
request into the <service> element.
2. If, however, the requested service, identified by the service URN
[10] in the <service> element in the request, does not exist for
the location indicated, the server can either return an
<serviceNotImplemented> (Section 12.1) error or can provide an <serviceNotImplemented> (Section 12.1) error or can provide an
alternate service that approximates the desired service for that alternate service that approximates the desired service for that
location. In the latter case, the server MUST include a <service> location. In the latter case, the server MUST include a
element with the alternative service URN. The choice of service URN <service> element with the alternative service URN. The choice
is left to local policy, but the alternate service should be able to of service URN is left to local policy, but the alternate service
satisfy the original service request. The <service> element may also should be able to satisfy the original service request.
be required if the mapping is to be digitally signed.
The <service> element is optional but may also be required if the
mapping is to be digitally signed.
5.6. Defining the Service Region with the <serviceBoundary> Element 5.6. Defining the Service Region with the <serviceBoundary> Element
A response can indicate the region for which the service URL returned A response MAY indicate the region for which the service URL returned
would be the same as in the actual query, the so-called _service would be the same as in the actual query, the so-called _service
region_. The service region can be indicated by value or by region_. The service region can be indicated by value or by
reference (see Section 5.7). If a client moves outside the service reference (see Section 5.7). If a client moves outside the service
area and wishes to obtain current service data, it MUST send a new area and wishes to obtain current service data, it sends a new query
query with its current location. The service region is described by with its current location. The service region is described by value
value in one or more <serviceBoundary> elements, each formatted in one or more <serviceBoundary> elements, each formatted according
according to a different location profile, identified by the to a different location profile, identified by the 'profile' atribute
'profile' atribute. The client only processes the first element that (see Section 11). The response MUST contain at least one service
it can understand according to its list of supported location boundary using the same profile as the request. The client only
profiles. Thus, the elements are alternative descriptions of the processes the first element that it can understand according to its
same service region, not additive geometries. list of supported location profiles. Thus, elements with geospatial
coordinates are alternative descriptions of the same service region,
not additive geometries.
The server returns all suitable service regions, using all available A response MAY contain more than one <serviceBoundary> element with
location profiles, so that intermediate caches have this information profile 'civic'. Each <serviceBoundary> element describes a set of
available for future queries. civic addresses that fall within the service boundary, namely all
addresses that textually match the civic address elements provided,
regardless of the value of other address elements. A location falls
within the mapping's service boundary if it matches any of the
<serviceBoundary> elements.
5.7. Service Boundaries by Reference: the <serviceBoundaryReference> 5.7. Service Boundaries by Reference: the <serviceBoundaryReference>
Element Element
Since geodetic service boundaries may contain thousands of points and Since geodetic service boundaries may contain thousands of points and
thus be quite large, clients may opt to conserve bandwidth and thus be quite large, clients may opt to conserve bandwidth and
request a reference to the service boundary instead of the value request a reference to the service boundary instead of the value
described in Section 5.6. The identifier of the service boundary is described in Section 5.6. The identifier of the service boundary is
returned as an attribute of the <serviceBoundaryReference> element, returned as an attribute of the <serviceBoundaryReference> element,
along with a LoST URL identifying the server from where it can be along with a LoST application unique string (see Section 4)
retrieved. The actual value of the service boundary is then identifying the server from where it can be retrieved. The actual
retrieved with the getServiceBoundary (Section 8) request. value of the service boundary is then retrieved with the
getServiceBoundary (Section 8) request.
The identifier is a random token with at least 128 bits of entropy The identifier is a random token with at least 128 bits of entropy
and can be assumed to be globally unique. It uniquely references a and can be assumed to be globally unique. It uniquely references a
particular boundary. If the boundary changes, a new identifier MUST particular boundary. If the boundary changes, a new identifier MUST
be chosen. Because of these properties, a client receiving a mapping be chosen. Because of these properties, a client receiving a mapping
response can simply check if it already has a copy of the boundary response can simply check if it already has a copy of the boundary
with that identifier. If so, it can skip checking with the server with that identifier. If so, it can skip checking with the server
whether the boundary has been updated. Since service boundaries are whether the boundary has been updated. Since service boundaries are
likely to remain unchanged for extended periods of time, possibly likely to remain unchanged for extended periods of time, possibly
exceeding the normal lifetime of the service URL, this approach exceeding the normal lifetime of the service URL, this approach
avoids refreshing the boundary information even if the cached service avoids unnecessarily refreshing the boundary information just because
response has gotten stale. the the remainder of the mapping has become invalid.
5.8. The Service Number 5.8. The Service Number Element
The service number is returned in the optional <serviceNumber> The service number is returned in the optional <serviceNumber>
element. It contains a string of digits, * and # that a user on a element. It contains a string of digits, * and # that a user on a
device with a 12-key dial pad could use to reach that particular device with a 12-key dial pad could use to reach that particular
service. service.
5.9. Service URLs: the <uri> Element 5.9. Service URLs: the <uri> Element
The response returns the service URLs in one or more <uri> elements. The response returns the service URLs in one or more <uri> elements.
The URLs MUST be absolute URLs. The ordering of the URLs has no The URLs MUST be absolute URLs. The ordering of the URLs has no
particular significance. Each URL scheme MUST only appear at most particular significance. Each URL scheme MUST only appear at most
once, but it is permissible to include both secured and regular once, but it is permissible to include both secured and regular
versions of a protocol, such as both 'http' and 'https' or 'sip' and versions of a protocol, such as both 'http' and 'https' or 'sip' and
'sips'. 'sips'.
6. Path of Request: <path> Element 6. Path of Request: <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 URL. The order of <via> elements corresponds to containing a LoST application unique string (see Section 4). The
the order of LoST servers, i.e., the first <via> element identifies order of <via> elements corresponds to the order of LoST servers,
the server that first received the request from the seeker. The i.e., the first <via> element identifies the server that first
authoritative server copies the <path> element verbatim into the received the request from the client. The authoritative server
response. copies the <path> element verbatim into the response.
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.
The example in Figure 5 indicates that the answer was given to the The example in Figure 5 indicates that the answer was given to the
responding server by the LoST server at esgw.ueber-110.de.example, responding server by the LoST server at esgw.ueber-110.de.example,
which got the answer from the LoST server at which got the answer from the LoST server at
polizei.muenchen.de.example. polizei.muenchen.de.example.
7. Mapping a Location and Service to URLs: <findService> 7. Mapping a Location and Service to URLs: <findService>
skipping to change at page 13, line 44 skipping to change at page 14, line 44
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 2: A <findService> geodetic query Figure 2: A <findService> geodetic query
Given the query above, a server would respond with a service, and Given the query above, a server would respond with a service, and
information related to that service. In the example below, the information related to that service. In the example below, the
server has mapped the location given by the client for a police server has mapped the location given by the client for a police
service to the New York City Police Deparment, instructing the client service to the New York City Police Deparment, instructing the client
that it may contact them via the URIs "sip:nypd@example.com" and that it may contact them via the URIs "sip:sfpd@example.com" and
"xmpp:nypd@example.com". The server has also given the client a "xmpp:sfpd@example.com". The server has also given the client a
geodetic, two-dimensional boundary for this service. The mapping was geodetic, two-dimensional boundary for this service. The mapping was
last updated on November 1, 2006 and expires on January 1, 2007. last updated on November 1, 2006 and expires on January 1, 2007. If
This instructs the client that if its location changes beyond the the client's location changes beyond the given service boundary or
give service boundary or the expiration time has been reached, it the expiration time has been reached, it may want to requery for this
would need to requery for this information. information, depending on the usage environment of LoST.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"> xmlns:p2="http://www.opengis.net/gml">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example" source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" version="1"> sourceId="7e3f40b098c711dbb6060800200c9a66" version="1">
<displayName xml:lang="en"> <displayName xml:lang="en">
New York City Police Department San Francisco Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <p2:exterior>
<p2:LinearRing> <p2:LinearRing>
<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:sfpd@example.com</uri>
<uri>xmpp:nypd@example.com</uri> <uri>xmpp:sfpd@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<path> <path>
<via source="lost:authoritative.example"/> <via source="authoritative.example"/>
<via source="lost:resolver.example"/> <via source="resolver.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 3: A <findServiceResponse> geodetic answer Figure 3: A <findServiceResponse> geodetic answer
7.2.2. Civic Address Mapping Example 7.2.2. Civic Address Mapping Example
The following is an example of mapping a service to a location much The following is an example of mapping a service to a location much
like the example in Section 7.2.1, but using civic address location like the example in Section 7.2.1, but using civic address location
information. In this example, the client requests the service information. In this example, the client requests the service
skipping to change at page 15, line 33 skipping to change at page 16, line 33
Figure 4: A <findService> civic address query Figure 4: A <findService> civic address query
Given the query above, a server would respond with a service, and Given the query above, a server would respond with a service, and
information related to that service. In the example below, the information related to that service. In the example below, the
server has mapped the location given by the client for a police server has mapped the location given by the client for a police
service to the Muenchen Polizei-Abteilung, instructing the client service to the Muenchen Polizei-Abteilung, instructing the client
that it may contact them via the URIs sip:munich-police@example.com that it may contact them via the URIs sip:munich-police@example.com
and xmpp:munich-police@example.com. The server has also given the and xmpp:munich-police@example.com. The server has also given the
client a civic address boundary (the city of Munich) for this client a civic address boundary (the city of Munich) for this
service. The mapping was last updated on November 1, 2006 by the service. The mapping was last updated on November 1, 2006 by the
authoritative source "lost:polizei.muenchen.de.example" and expires authoritative source "polizei.muenchen.de.example" and expires on
on January 1, 2007. This instructs the client to requery for the January 1, 2007. This instructs the client to requery for the
information if its location changes beyond the given service boundary information if its location changes beyond the given service boundary
(i.e., beyond the city of Munich) or after January 1, 2007. (i.e., beyond the city of Munich) or after January 1, 2007.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="lost:esgw.ueber-110.de.example" source="esgw.ueber-110.de.example"
sourceId="e8b05a41d8d1415b80f2cdbb96ccf109" version="1" > sourceId="e8b05a41d8d1415b80f2cdbb96ccf109" version="1" >
<displayName xml:lang="de"> <displayName xml:lang="de">
Muenchen Polizei-Abteilung Muenchen Polizei-Abteilung
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary <serviceBoundary
profile="urn:ietf:params:lost:location-profile:basic-civic"> profile="urn:ietf:params:lost:location-profile:basic-civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country> <country>Germany</country>
<A1>Bavaria</A1> <A1>Bavaria</A1>
<A3>Munich</A3> <A3>Munich</A3>
<PC>81675</PC> <PC>81675</PC>
</civicAddress> </civicAddress>
</serviceBoundary> </serviceBoundary>
<uri>sip:munich-police@example.com</uri> <uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber> <serviceNumber>110</serviceNumber>
</mapping> </mapping>
<path> <path>
<via source="lost:esgw.ueber-110.de.example"/> <via source="esgw.ueber-110.de.example"/>
<via source="lost:polizei.muenchen.de.example"/> <via source="polizei.muenchen.de.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 5: A <findServiceResponse> civic address answer Figure 5: A <findServiceResponse> civic address answer
7.3. Components of the <findService> Request 7.3. Components of the <findService> Request
The <findService> request includes attributes that govern whether the The <findService> request includes attributes that govern whether the
request is handled iteratively or recursively, whether location request is handled iteratively or recursively, whether location
validation is performed and which elements must be contained in the validation is performed and which elements must be contained in the
response. response.
7.3.1. The <location> Element 7.3.1. The <location> Element
The <findService> query communicates location using one or more The <findService> query communicates location information using one
<location> elements, which MUST conform to a location profile (see or more <location> elements, which MUST conform to a location profile
Section 11). There MUST be no more than one location element for (see Section 11). There MUST NOT be more than one location element
each distinct location profile. The order of location objects is for each distinct location profile. The order of location objects is
significant; the server uses the first location object where it significant; the server uses the first location object where it
understands the location profile. understands the location profile.
7.3.2. Identifying the Service: The <service> Element 7.3.2. Identifying the Service: The <service> Element
The type of service desired is specified by the <service> element. The type of service desired is specified by the <service> element.
It contains service URNs from the registry established in [10]. It contains service URNs from the registry established in [10].
7.3.3. Recursion 7.3.3. Recursion
LoST <findService> and <listServicesByLocation> queries can be LoST <findService> and <listServicesByLocation> queries can be
recursive, as indicated by the 'recursive' attribute. A value of recursive, as indicated by the 'recursive' attribute. A value of
"true" indicates a recursive query, with the default being "false" "true" indicates a recursive query, with the default being "false"
when the attribute is omitted. In recursive mode, the LoST server when the attribute is omitted. Regardless of the attribute, a server
initiates queries on behalf of the requester and returns the result MAY always answer a query by providing a LoST application unique
to the requester, inserting a <via> element to track the response string (see Section 4), i.e., indirection, however, it MUST NOT
chain. The <via> elements are appended in responses in order of recurse if the attribute is "false".
visit, i.e., the first <via> element contains the authoritative
server and <via> elements below indicate servers that the response In recursive mode, the LoST server initiates queries on behalf of the
traversed on its way back to the original querier. requester and returns the result to the requester, inserting a <via>
element to track the response chain. The <via> elements are appended
in responses in order of visit, i.e., the first <via> element
contains the authoritative server and <via> elements below indicate
servers that the response traversed on its way back to the original
querier.
7.3.4. Service Boundary 7.3.4. Service Boundary
LoST <mapping> elements can describe the service boundary either by LoST <mapping> elements can describe the service boundary either by
value or by reference. Returning a service boundary reference is value or by reference. Returning a service boundary reference is
generally more space-efficient for geospatial (polygon) boundaries generally more space-efficient for geospatial (polygon) boundaries
and if the boundaries change rarely, but does incur an additional and if the boundaries change rarely, but does incur an additional
<getServiceBoundary> request. The querier can express a preference <getServiceBoundary> request. The querier can express a preference
for one or the other modality with the 'serviceBoundary' attribute in for one or the other modality with the 'serviceBoundary' attribute in
the <findService> request, but the server makes the final decision as the <findService> request, but the server makes the final decision as
skipping to change at page 19, line 9 skipping to change at page 20, line 9
</location> </location>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findService> </findService>
Figure 6: A <findService> query with address validation request Figure 6: A <findService> query with address validation request
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"> <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example" source="authoritative.example"
sourceId="4db898df52b84edfa9b6445ea8a0328e" sourceId="4db898df52b84edfa9b6445ea8a0328e"
version="1" > version="1" >
<displayName xml:lang="de"> <displayName xml:lang="de">
Muenchen Polizei-Abteilung Muenchen Polizei-Abteilung
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="civic"> <serviceBoundary profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>Germany</country> <country>Germany</country>
skipping to change at page 19, line 34 skipping to change at page 20, line 34
</serviceBoundary> </serviceBoundary>
<uri>sip:munich-police@example.com</uri> <uri>sip:munich-police@example.com</uri>
<uri>xmpp:munich-police@example.com</uri> <uri>xmpp:munich-police@example.com</uri>
<serviceNumber>110</serviceNumber> <serviceNumber>110</serviceNumber>
</mapping> </mapping>
<locationValidation> <locationValidation>
<valid>country A1 A3 A6</valid> <valid>country A1 A3 A6</valid>
<invalid>PC</invalid> <invalid>PC</invalid>
</locationValidation> </locationValidation>
<path> <path>
<via source="lost:authoritative.example"/> <via source="authoritative.example"/>
<via source="lost:resolver.example"/> <via source="resolver.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 7: A <findServiceResponse> message with address validation Figure 7: A <findServiceResponse> message with address validation
information information
7.4. Components of the Mapping Response <findServiceResponse> 7.4. Components of the Mapping Response <findServiceResponse>
7.4.1. Overview 7.4.1. Overview
skipping to change at page 22, line 10 skipping to change at page 23, line 10
</findService> </findService>
Figure 8: <findService> request and response with service boundary Figure 8: <findService> request and response with service boundary
reference reference
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1" <findServiceResponse xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml"> xmlns:p2="http://www.opengis.net/gml">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example" source="authoritative.example"
sourceId="7e3f40b098c711dbb6060800200c9a66" sourceId="7e3f40b098c711dbb6060800200c9a66"
version="1"> version="1">
<displayName xml:lang="en"> <displayName xml:lang="en">
New York City Police Department San Francisco Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundaryReference <serviceBoundaryReference
source="lost:authoritative.example" source="authoritative.example"
key="7214148E0433AFE2FA2D48003D31172E" /> key="7214148E0433AFE2FA2D48003D31172E" />
<uri>sip:nypd@example.com</uri> <uri>sip:sfpd@example.com</uri>
<uri>xmpp:nypd@example.com</uri> <uri>xmpp:sfpd@example.com</uri>
<serviceNumber>911</serviceNumber> <serviceNumber>911</serviceNumber>
</mapping> </mapping>
<path> <path>
<via source="lost:authoritative.example"/> <via source="authoritative.example"/>
<via source="lost:resolver.example"/> <via source="resolver.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 9: <findServiceResponse> message with service boundary Figure 9: <findServiceResponse> message with service boundary
reference reference
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1" <getServiceBoundary xmlns="urn:ietf:params:xml:ns:lost1"
key="7214148E0433AFE2FA2D48003D31172E"/> key="7214148E0433AFE2FA2D48003D31172E"/>
skipping to change at page 23, line 18 skipping to change at page 24, line 18
<serviceBoundary <serviceBoundary
profile="civic"> profile="civic">
<civicAddress <civicAddress
xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"> xmlns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
<country>US</country> <country>US</country>
<A1>New York</A1> <A1>New York</A1>
<A3>New York</A3> <A3>New York</A3>
</civicAddress> </civicAddress>
</serviceBoundary> </serviceBoundary>
<path> <path>
<via source="lost:authoritative.example"/> <via source="authoritative.example"/>
<via source="lost:resolver.example"/> <via source="resolver.example"/>
</path> </path>
</getServiceBoundaryResponse> </getServiceBoundaryResponse>
Figure 11: Civic Address Service Boundary Response Figure 11: Civic Address Service Boundary Response
9. List Services: <listServices> 9. List Services: <listServices>
A LoST client can ask a LoST server for the list of services that it A LoST client can ask a LoST server for the list of services that it
understands, primarily for diagnostic purposes. The query does not understands, primarily for diagnostic purposes. The query does not
contain location information, as it simply provides an indication of contain location information, as it simply provides an indication of
skipping to change at page 26, line 20 skipping to change at page 27, line 20
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> <path>
<via source="lost:authoritative.example"/> <via source="authoritative.example"/>
<via source="lost:resolver.example"/> <via source="resolver.example"/>
</path> </path>
</listServicesByLocationResponse> </listServicesByLocationResponse>
Figure 15: Example of <ListServices> response Figure 15: Example of <ListServices> response
11. Location Profiles 11. 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
skipping to change at page 28, line 8 skipping to change at page 29, line 8
<serviceBoundary> element; <serviceBoundary> element;
4. The declaration of whether geodetic-2d or civic is to be used as 4. The declaration of whether geodetic-2d or civic is to be used as
the baseline profile. It is necessary to explicitly declare the the baseline profile. It is necessary to explicitly declare the
baseline profile as future profiles may be combinations of baseline profile as future profiles may be combinations of
geodetic and civic location information. geodetic and civic location information.
11.1. Location Profile Usage 11.1. Location Profile Usage
A location profile is identified by a token in an IANA-maintained A location profile is identified by a token in an IANA-maintained
registry (Section 16.6). Clients send location information compliant registry (Section 16.5). Clients send location information compliant
with a location profile, and servers respond with location with a location profile, and servers respond with location
information compliant with that same location profile. information compliant with that same location profile.
When a LoST client sends a <findService> request that provides When a LoST client sends a <findService> request that provides
location information, it includes one or more <location> elements. location information, it includes one or more <location> elements. A
Each of these elements contains location information compliant with a <location> element carries a mandatory 'profile' attribute that
location profile and specifies which profile has been used in the indicates the location format of the child elements. The concept of
'profile' attribute. This allows the client to convey location location profiles are described in Section 11. With the ability to
information for multiple location profiles in the same request. specify more than one <location> element the client is able to convey
location information for multiple location profiles in the same
request.
When a LoST server sends a response that contains location When a LoST server sends a response that contains location
information, it uses the <serviceBoundary> elements much like the information, it uses the <serviceBoundary> elements much like the
client uses the <location> elements. Each <serviceBoundary> element client uses the <location> elements. Each <serviceBoundary> element
contains location information conformant to the location profile contains location information conformant to the location profile
specified in the 'profile' attribute. This allows the server to send specified in the 'profile' attribute. When multiple <location>
location information compliant with multiple location profiles. elements are included then it enables the server to send location
information compliant with multiple location profiles.
Using the location profiles defined in this document, the following Using the location profiles defined in this document, the following
rules insure basic interoperatiblity between clients and servers: rules insure basic interoperatiblity between clients and servers:
1. A client MUST be capable of understanding the response for the 1. A client MUST be capable of understanding the response for the
baseline profiles it used in the request. baseline profiles it used in the request.
2. If a client sends location information conformant to any location 2. If a client sends location information conformant to any location
profile other than geodetic-2d or civic, it MUST also send, in profile other than geodetic-2d or civic, it MUST also send, in
the same request, location information conformant to one of the the same request, location information conformant to one of the
skipping to change at page 30, line 5 skipping to change at page 32, line 4
<location profile="geodetic-2d"> <location profile="geodetic-2d">
<p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326"> <p2:Point id="point1" srsName="urn:ogc:def:crs:EPSG:4326">
<p2:pos>37.775 -122.422</p2:pos> <p2:pos>37.775 -122.422</p2:pos>
</p2:Point> </p2: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"?>
<findServiceResponse <findServiceResponse
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/"> xmlns:p2="http://www.opengis.net/">
<mapping <mapping
expires="2007-01-01T01:44:33Z" expires="2007-01-01T01:44:33Z"
lastUpdated="2006-11-01T01:00:00Z" lastUpdated="2006-11-01T01:00:00Z"
source="lost:authoritative.example" source="authoritative.example"
sourceId="cf19bbb038fb4ade95852795f045387d" sourceId="cf19bbb038fb4ade95852795f045387d"
version="1"> version="1">
<displayName xml:lang="en"> <displayName xml:lang="en">
New York City Police Department San Francisco Police Department
</displayName> </displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<serviceBoundary profile="geodetic-2d"> <serviceBoundary profile="geodetic-2d">
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326"> <p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior> <p2:exterior>
<p2:LinearRing> <p2:LinearRing>
<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>
</mapping> </mapping>
<path> <path>
<via source="lost:authoritative.example"/> <via source="authoritative.example"/>
<via source="lost:resolver.example"/> <via source="resolver.example"/>
</path> </path>
</findServiceResponse> </findServiceResponse>
Figure 17: Example of a <findServiceResponse> message with baseline Figure 17: Example of a <findServiceResponse> message with baseline
profile interoperability profile interoperability
11.2. Two Dimensional Geodetic Profile 11.2. Two Dimensional Geodetic Profile
The geodetic-2d location profile is identified by geodetic-2d. The geodetic-2d location profile is identified by geodetic-2d.
Clients use this profile by placing a GML [13] <position> element Clients use this profile by placing a GML [13] <position> element
skipping to change at page 32, line 37 skipping to change at page 34, line 37
The following errors follow this basic pattern: The following errors follow this basic pattern:
badRequest badRequest
The server could not parse or otherwise understand a request, The server could not parse or otherwise understand a request,
e.g., because the XML was malformed. e.g., because the XML was malformed.
forbidden forbidden
The server refused to send an answer. This generally only occurs The server refused to send an answer. This generally only occurs
for recursive queries, namely if the resolver tried to contact the for recursive queries, namely if the client tried to contact the
authoritative server and was refused. (For HTTP as the underlying authoritative server and was refused. (For HTTP as the underlying
protocol, an HTTP 401 error would be returned.) protocol, an HTTP 401 error would be returned.)
internalError internalError
The server could not satisfy a request due to misconfiguration or The server could not satisfy a request due to misconfiguration or
other operational and non-protocol related reasons. other operational and non-protocol related reasons.
locationProfileUnrecognized locationProfileUnrecognized
skipping to change at page 33, line 34 skipping to change at page 35, line 34
serviceNotImplemented serviceNotImplemented
The requested service URN is not implemented and no substitution The requested service URN is not implemented and no substitution
was available. was available.
An example is below: An example is below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<errors xmlns="urn:ietf:params:xml:ns:lost1" <errors xmlns="urn:ietf:params:xml:ns:lost1"
source="lost:resolver.example"> source="resolver.example">
<internalError message="Software bug." xml:lang="en"/> <internalError message="Software bug." xml:lang="en"/>
</errors> </errors>
Figure 18: Example of an error resonse Figure 18: Example of an error resonse
12.2. Warnings 12.2. Warnings
A response MAY contain zero or more warnings. This pattern defines a A response MAY contain zero or more warnings. This pattern defines a
'message' attribute containing human readable text and an 'xml:lang' 'message' attribute containing human readable text and an 'xml:lang'
attribute denoting the language of the human readable text. One or attribute denoting the language of the human readable text. One or
more such warning elements are contained in the <warnings> element. more such warning elements are contained in the <warnings> element.
This version of the specification does not define any warning This version of the specification does not define any warning
elements. elements.
12.3. Redirects 12.3. Redirects
A LoST server can respond indicating that the querier should redirect A LoST server can respond indicating that the querier should redirect
the query to another server, using the <redirect> element. The the query to another server, using the <redirect> element. The
element includes a 'target' attribute indicating the LoST URL that element includes a 'target' attribute indicating the LoST application
the client SHOULD be contacting next, as well as the 'source' unique string (see Section 4) that the client SHOULD be contacting
attribute indicating the server that generated the redirect response next, as well as the 'source' attribute indicating the server that
and a 'message' attribute explaining the reason for the redirect generated the redirect response and a 'message' attribute explaining
response. During a recursive query, a server receiving a <redirect> the reason for the redirect response. During a recursive query, a
response can decide whether it wants to follow the redirection or server receiving a <redirect> response can decide whether it wants to
simply return the response to its upstream querier. follow the redirection or simply return the response to its upstream
querier.
An example is below: An example is below:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<redirect xmlns="urn:ietf:params:xml:ns:lost1" <redirect xmlns="urn:ietf:params:xml:ns:lost1"
target="lost:eastpsap.example" target="eastpsap.example"
source="lost:westpsap.example" source="westpsap.example"
message="We have temporarily failed over." xml:lang="en"/> message="We have temporarily failed over." xml:lang="en"/>
Figure 19: Example of a redirect resonse Figure 19: Example of a redirect resonse
13. LoST Transport 13. LoST Transport
LoST needs an underlying protocol transport mechanisms to carry LoST needs an underlying protocol transport mechanisms to carry
requests and responses. This document defines the use of LoST over requests and responses. This document defines the use of LoST over
HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future HTTP and LoST over HTTP-over-TLS; other mechanisms are left to future
documents. The available transport mechanisms are determined through documents. The available transport mechanisms are determined through
the use of the LoST U-NAPTR application. In protocols that support the use of the LoST U-NAPTR application. In protocols that support
content type indication, LoST uses the media type application/ content type indication, LoST uses the media type application/
lost+xml. lost+xml.
When using HTTP [3] and HTTP-over-TLS [5], LoST requests use the HTTP When using HTTP [3] and HTTP-over-TLS [4], LoST requests use the HTTP
POST method. All HTTP responses are applicable. The HTTP URL is POST method. All HTTP responses are applicable. The HTTP URL is
derived from the LoST URL via U-NAPTR application, as discussed in derived from the LoST server name via U-NAPTR application, as
Section 4. discussed above
14. Relax NG Schema 14. 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.
default namespace = "http://www.opengis.net/gml" default namespace = "http://www.opengis.net/gml"
namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
namespace ns1 = "urn:ietf:params:xml:ns:lost1" namespace ns1 = "urn:ietf:params:xml:ns:lost1"
skipping to change at page 41, line 9 skipping to change at page 43, line 9
## ##
## Redirect. ## Redirect.
## ##
div { div {
## ##
## Redirect pattern ## Redirect pattern
## ##
redirect = redirect =
element ns1:redirect { element ns1:redirect {
attribute target { xsd:anyURI }, attribute target { appUniqueString },
source, source,
message, message,
extensionPoint extensionPoint
} }
} }
## ##
## Some common patterns. ## Some common patterns.
## ##
div { div {
message = message =
(attribute message { xsd:string }, (attribute message { xsd:string },
attribute xml:lang { xsd:language })? attribute xml:lang { xsd:language })?
service = element ns1:service { xsd:anyURI }? service = element ns1:service { xsd:anyURI }?
source = attribute source { xsd:anyURI } appUniqueString =
xsd:string { pattern = "([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+" }
source = attribute source { appUniqueString }
serviceList = serviceList =
element ns1:serviceList { element ns1: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 44, line 30 skipping to change at page 46, line 30
o o
Application Protocol Tag: http Application Protocol Tag: http
Defining Publication: RFC 2616 [3] Defining Publication: RFC 2616 [3]
o o
Application Protocol Tag: https Application Protocol Tag: https
Defining Publication: RFC 2818 [5] Defining Publication: RFC 2818 [4]
16.2. Content-type registration for 'application/lost+xml' 16.2. Content-type registration for 'application/lost+xml'
This specification requests the registration of a new MIME type This specification requests the registration of a new MIME type
according to the procedures of RFC 4288 [9] and guidelines in RFC according to the procedures of RFC 4288 [8] and guidelines in RFC
3023 [6]. 3023 [5].
MIME media type name: application MIME media type name: application
MIME subtype name: lost+xml MIME subtype name: lost+xml
Mandatory parameters: none Mandatory parameters: none
Optional parameters: charset Optional parameters: charset
Indicates the character encoding of enclosed XML. Indicates the character encoding of enclosed XML.
Encoding considerations: Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See RFC 3023 [6], Section 3.2. character encoding used. See RFC 3023 [5], Section 3.2.
Security considerations: Security considerations:
This content type is designed to carry LoST protocol payloads. This content type is designed to carry LoST protocol payloads.
Interoperability considerations: None Interoperability considerations: None
Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number of this specification.] this replace XXXX with the RFC number of this specification.] this
document document
skipping to change at page 46, line 7 skipping to change at page 48, line 7
Intended usage: LIMITED USE Intended usage: LIMITED USE
Author: Author:
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> delegated to the IETF ECRIT working
group, if it is still active.
16.3. LoST Relax NG Schema Registration 16.3. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:lost1 URI: urn:ietf:params:xml:ns:lost1
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com). (Hannes.Tschofenig@siemens.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 14. Its first line is in Section 14. Its first line is
skipping to change at page 47, line 6 skipping to change at page 49, line 26
<h1>Namespace for LoST</h1> <h1>Namespace for LoST</h1>
<h2>urn:ietf:params:xml:ns:lost1</h2> <h2>urn:ietf:params:xml:ns:lost1</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX <p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR: [NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this Please replace XXXX with the RFC number of this
specification.]</a>.</p> specification.]</a>.</p>
</body> </body>
</html> </html>
END END
16.5. URL Registration Template 16.5. LoST Location Profile Registry
This registration template is in accordance with [4].
URL scheme name:
lost
URL scheme syntax:
See Section 4
Character encoding considerations:
See Section 4
Intended Use:
The intended usage is described in this document.
Application and protocols which use this scheme:
The usage of the LoST URL scheme is targeted for this document and
hence for location-based services that make use of the mapping
protocol specified in this document.
Interoperability considerations:
None
Security considerations:
See Section 17
Relevant publications:
This document provides the relevant context for this URL scheme.
Contact:
Hannes Tschofenig, Hannes.Tschofenig@siemens.com
Author/Change controller:
The IESG <iesg@ietf.org>
16.6. LoST Location Profile Registry
This document seeks to create a registry of location profile names This document seeks to create a registry of location profile names
for the LoST protocol. Profile names are XML tokens. This registry for the LoST protocol. Profile names are XML tokens. This registry
will operate in accordance with RFC 2434 [2], Standards Action. will operate in accordance with RFC 2434 [2], Standards Action.
geodetic-2d: geodetic-2d:
Defined in Section 11.2 Defined in Section 11.2
civic: civic:
skipping to change at page 49, line 17 skipping to change at page 50, line 17
There are multiple threats to the overall system of which service There are multiple 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, the use
of channels security, such as TLS, is RECOMMENDED. of channel security, such as TLS, is RECOMMENDED.
Generally, authentication and authorization is not required for
mapping queries. If it is, authentication mechanism of the
underlying transport mechanism, such as HTTP basic and digest
authentication, MAY be used. (Basic authentication SHOULD only be
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].
18. Acknowledgments 18. Acknowledgments
We would like to the thank the following working group members for We would like to the thank the following working group members for
the detailed review of previous LoST document versions: the detailed review of previous LoST document versions:
o Barbara Stark (Review in Jan. 2007) o Martin Thomson (Review July 2006)
o Martin Thomson (Review in Dec. 2006, Review Jul. 2006) o Jonathan Rosenberg (Review July 2006)
o Shida Schubert (Review Nov. 2006) o Leslie Daigle (Review September 2006)
o Leslie Daigle (Review Sep. 2006) o Shida Schubert (Review November 2006)
o Jonathan Rosenberg (Review Jul. 2006) o Martin Thomson (Review December 2006)
o Barbara Stark (Review January 2007)
o Patrik Faeltstroem (Review January 2007
o Shida Schubert (Review January 2007 as a designated expert
reviewer)
We would also like to thank the following working group members for We would also like to thank the following working group members for
their input to selected design aspects of the LoST protocol: their input to selected design aspects of the LoST protocol:
o Leslie Daigle and Martin Thomson (Input to DNS-based LoST o Leslie Daigle and Martin Thomson (DNS-based LoST discovery
discovery procedure) procedure)
o John Schnizlein (Authoritive LoST Answers) o John Schnizlein (authoritive LoST answers)
o Rohan Mahy (Display Names) o Rohan Mahy (display names)
o James Polk (Error Handling) o James Polk (error handling)
o Ron Watro and Richard Barnes (Expiry of cached data) o Ron Watro and Richard Barnes (expiry of cached data)
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson and James
Winterbottom (Indication of PSAP Confidence Level) Winterbottom (Indication of PSAP Confidence Level)
o Martin Thomson (Service Boundary references) o Martin Thomson (service boundary references)
o Martin Thomson (Service URN in LoST response message) o Martin Thomson (service URN in LoST response message)
o Cullen Jennings (Service Boundaries) o Cullen Jennings (service boundaries)
o Clive D.W. Feather, Martin Thomson (Validation Functionality) o Clive D.W. Feather, Martin Thomson (Validation Functionality)
o Roger Marshall (PSAP Preference in LoST response) o Roger Marshall (PSAP Preference in LoST response)
o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor, o James Winterbottom, Marc Linsner, Keith Drage, Tom-PT Taylor,
Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W. Martin Thomson, John Schnizlein, Shida Schubert, Clive D.W.
Feather, Richard Stastny, John Hearty, Roger Marshall, Jean- Feather, Richard Stastny, John Hearty, Roger Marshall, Jean-
Francois Mule, Pierre Desjardins (Location Profiles) Francois Mule, Pierre Desjardins (Location Profiles)
o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson, o Michael Hammer, Patrik Faeltstroem, Stastny Richard, Thomson,
Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage,
Keith (List Services functionality) Keith (List Services functionality)
o Thomson, Martin, Michael Hammer (Mapping of Services) o Thomson, Martin, Michael Hammer (Mapping of Services)
o Shida Schubert, James Winterbottom, Keith Drage (default service o Shida Schubert, James Winterbottom, Keith Drage (default service
URN) URN)
o Otmar Lendl (LoST aggregation) o Otmar Lendl (LoST aggregation)
skipping to change at page 51, line 15 skipping to change at page 52, line 22
Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage, Martin, Roger Marshall, Tom-PT Taylor, Spencer Dawkins, Drage,
Keith (List Services functionality) Keith (List Services functionality)
o Thomson, Martin, Michael Hammer (Mapping of Services) o Thomson, Martin, Michael Hammer (Mapping of Services)
o Shida Schubert, James Winterbottom, Keith Drage (default service o Shida Schubert, James Winterbottom, Keith Drage (default service
URN) URN)
o Otmar Lendl (LoST aggregation) o Otmar Lendl (LoST aggregation)
The following working group members provided miscellaneous input to Klaus Darilion and Marc Linsner provided miscellaneous input to the
the design of the protocol: design of the protocol. Finally, we would like to thank Brian Rosen
who participated in almost every discussion thread.
o Klaus Darilion
o Marc Linsner
Finally, we would like to particularly thank Brian Rosen as a long
term contributor who participated in almost every discussion thread.
19. Open Issues 19. Open Issues
Please find open issues at: http://www.ietf-ecrit.org:8080/lost/ Please find open issues at: http://www.ietf-ecrit.org:8080/lost/
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.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999. HTTP/1.1", RFC 2616, June 1999.
[4] Petke, R. and I. King, "Registration Procedures for URL Scheme [4] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Names", BCP 35, RFC 2717, November 1999.
[5] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", [5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001. RFC 3023, January 2001.
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005. January 2005.
[8] Peterson, J., "A Presence-based GEOPRIV Location Object [7] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
[9] Freed, N. and J. Klensin, "Media Type Specifications and [8] 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.
[9] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
Registration Procedures for New URI Schemes", BCP 115,
RFC 4395, February 2006.
[10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [10] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-ietf-ecrit-service-urn-05 (work in progress), draft-ietf-ecrit-service-urn-05 (work in progress),
August 2006. August 2006.
[11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format [11] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in
progress), September 2006. progress), September 2006.
[12] Daigle, L., "Domain-based Application Service Location Using [12] Daigle, L., "Domain-based Application Service Location Using
URIs and the Dynamic Delegation Discovery Service (DDDS)", URIs and the Dynamic Delegation Discovery Service (DDDS)",
skipping to change at page 65, line 10 skipping to change at page 66, line 10
<div> <div>
<a:documentation> <a:documentation>
Redirect. Redirect.
</a:documentation> </a:documentation>
<define name="redirect"> <define name="redirect">
<a:documentation> <a:documentation>
Redirect pattern Redirect pattern
</a:documentation> </a:documentation>
<element name="redirect"> <element name="redirect">
<attribute name="target"> <attribute name="target">
<data type="anyURI" /> <ref name="appUniqueString" />
</attribute> </attribute>
<ref name="source" /> <ref name="source" />
<ref name="message" /> <ref name="message" />
<ref name="extensionPoint" /> <ref name="extensionPoint" />
</element> </element>
</define> </define>
</div> </div>
<div> <div>
skipping to change at page 65, line 46 skipping to change at page 66, line 46
</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">
<data type="string">
<param name="pattern">([a-zA-Z0-9\-]+\.)+[a-zA-Z0-9]+</param>
</data>
</define>
<define name="source"> <define name="source">
<attribute name="source"> <attribute name="source">
<data type="anyURI" /> <ref name="appUniqueString" />
</attribute> </attribute>
</define> </define>
<define name="serviceList" > <define name="serviceList" >
<element name="serviceList"> <element name="serviceList">
<list> <list>
<zeroOrMore> <zeroOrMore>
<data type="anyURI" /> <data type="anyURI" />
</zeroOrMore> </zeroOrMore>
</list> </list>
</element> </element>
</define> </define>
 End of changes. 104 change blocks. 
305 lines changed or deleted 303 lines changed or added

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