draft-ietf-ecrit-lost-00.txt   draft-ietf-ecrit-lost-01.txt 
Network Working Group T. Hardie Network Working Group T. Hardie
Internet-Draft Qualcomm, Inc. Internet-Draft Qualcomm, Inc.
Expires: December 18, 2006 A. Newton Intended status: Standards Track A. Newton
SunRocket Expires: March 8, 2007 SunRocket
H. Schulzrinne H. Schulzrinne
Columbia U. Columbia U.
H. Tschofenig H. Tschofenig
Siemens Siemens
June 16, 2006 September 4, 2006
LoST: A Location-to-Service Translation Protocol LoST: A Location-to-Service Translation Protocol
draft-ietf-ecrit-lost-00.txt draft-ietf-ecrit-lost-01.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 December 18, 2006. This Internet-Draft will expire on March 8, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes an XML-based protocol for mapping service This document describes an XML-based protocol for mapping service
identifiers and geospatial or civic location information to service identifiers and geospatial 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 6
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Server Discovery . . . . . . . . . . . . . . . . . . . . . . . 7 4. Resolving Service URNs Using LoST . . . . . . . . . . . . . . 8
5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Query . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Location Information Element . . . . . . . . . . . . . . . 8 5.1. Location Information Element . . . . . . . . . . . . . . . 9
5.2. Service Identifier Element . . . . . . . . . . . . . . . . 8 5.2. Service Element . . . . . . . . . . . . . . . . . . . . . 9
5.3. Validate Attribute . . . . . . . . . . . . . . . . . . . . 8 5.3. Validate Attribute . . . . . . . . . . . . . . . . . . . . 9
5.4. Query Message Examples . . . . . . . . . . . . . . . . . . 8 5.4. Query Message Examples . . . . . . . . . . . . . . . . . . 9
6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Uniform Resource Identifiers (URI) Element . . . . . . . . 10 6.1. Uniform Resource Identifiers (URI) Element . . . . . . . . 11
6.2. Display Name Element Element . . . . . . . . . . . . . . . 10 6.2. Display Name Element . . . . . . . . . . . . . . . . . . . 11
6.3. Region Element . . . . . . . . . . . . . . . . . . . . . . 10 6.3. Service Element . . . . . . . . . . . . . . . . . . . . . 11
6.4. Dialstring Element . . . . . . . . . . . . . . . . . . . . 10 6.4. ServiceBoundary Element . . . . . . . . . . . . . . . . . 12
6.5. TimeToLive Attribute . . . . . . . . . . . . . . . . . . . 10 6.5. ServiceNumber Element . . . . . . . . . . . . . . . . . . 12
6.6. Validated Element . . . . . . . . . . . . . . . . . . . . 10 6.6. TimeToLive Attribute . . . . . . . . . . . . . . . . . . . 12
6.7. text Attribute . . . . . . . . . . . . . . . . . . . . . . 11 6.7. Validation Element . . . . . . . . . . . . . . . . . . . . 12
6.8. Response Message Examples . . . . . . . . . . . . . . . . 11 6.8. Response Message Examples . . . . . . . . . . . . . . . . 12
7. Miscellaneous Functionality . . . . . . . . . . . . . . . . . 13 7. List Services Query and Response . . . . . . . . . . . . . . . 15
7.1. List Service Query . . . . . . . . . . . . . . . . . . . . 13 7.1. List Service Query . . . . . . . . . . . . . . . . . . . . 15
7.2. Response to a List Service Query . . . . . . . . . . . . . 13 7.2. List Service Response . . . . . . . . . . . . . . . . . . 15
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17
9. Deployment Methods . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17
10. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 17
11. Internationalization Considerations . . . . . . . . . . . . . 24 8.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 17
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8.2.2. 201 Service Substitution . . . . . . . . . . . . . . . 17
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 8.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 17
14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3.1. 301 Move Permanently . . . . . . . . . . . . . . . . . 17
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.3.2. 302 Moved Temporarily . . . . . . . . . . . . . . . . 18
15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.3.3. Example . . . . . . . . . . . . . . . . . . . . . . . 18
15.2. Informative References . . . . . . . . . . . . . . . . . . 28 8.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 8.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 31 8.4.2. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 18
8.4.3. 404 Not Found . . . . . . . . . . . . . . . . . . . . 18
8.4.4. 414 Location Error . . . . . . . . . . . . . . . . . . 18
8.4.5. Example . . . . . . . . . . . . . . . . . . . . . . . 18
8.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 20
8.5.1. 500 Server Internal Error . . . . . . . . . . . . . . 20
8.5.2. 501 Service Not Implemented . . . . . . . . . . . . . 20
8.5.3. 504 Server Time-Out . . . . . . . . . . . . . . . . . 21
8.5.4. Example . . . . . . . . . . . . . . . . . . . . . . . 21
9. LoST Transport . . . . . . . . . . . . . . . . . . . . . . . . 22
10. LoST Uniform Resource Locators . . . . . . . . . . . . . . . . 23
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. Deployment Methods . . . . . . . . . . . . . . . . . . . . . . 26
13. Relax NG Schema . . . . . . . . . . . . . . . . . . . . . . . 28
14. Internationalization Considerations . . . . . . . . . . . . . 33
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
15.1. Content-type registration for 'application/lost+xml' . . . 34
15.2. LoST Relax NG Schema Registration . . . . . . . . . . . . 35
15.3. LoST Namespace Registration . . . . . . . . . . . . . . . 36
15.4. Registration Template . . . . . . . . . . . . . . . . . . 36
16. Security Considerations . . . . . . . . . . . . . . . . . . . 38
17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
18. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 40
19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
19.1. Normative References . . . . . . . . . . . . . . . . . . . 41
19.2. Informative References . . . . . . . . . . . . . . . . . . 42
Appendix A. Non-Normative RELAX NG Schema in XML Syntax . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
Intellectual Property and Copyright Statements . . . . . . . . . . 52
1. Introduction 1. Introduction
This document describes a protocol for mapping a service This document describes a protocol for mapping a service identifier
identifier[6] and location information compatible with PIDF-LO [10] [6] and location information compatible with PIDF-LO [11] to one or
to one or more service contact URIs. Example contact URI schemes more service contact URIs. Example contact URI schemes include sip,
include sip, xmpp, and tel. While the initial focus is on providing xmpp, and tel. While the initial focus is on providing mapping
mapping functions for emergency services, it is likely that the functions for emergency services, it is likely that the protocol is
protocol is applicable to any service URN. For example, in the applicable to any service URN. For example, in the United States,
United States, the "2-1-1" and "3-1-1" services follow a similar the "2-1-1" and "3-1-1" services follow a similar location-to-service
location-to-service behavior as emergency services. behavior as emergency services.
This document names this protocol usage "LoST" for Location-to- This document names this protocol usage "LoST" for Location-to-
Service Translation Protocol. The features of LoST are: Service Translation Protocol. The features of LoST are:
o Supports queries using civic as well as geospatial location o Supports queries using civic as well as geospatial location
information. information.
o Can be used in both recursive and iterative resolution. o Support for recursive and iterative resolution.
o Can be used for civic address validation. o Support for address validation.
o A hierarchical deployment of mapping servers is independent of o A hierarchical deployment of mapping servers is independent of
civic location labels. civic location labels.
o Can indicate errors in the location data to facilitate debugging o Indication of errors in the location data to facilitate debugging
and proper user feedback while simultaneously providing best- and proper user feedback while simultaneously providing best-
effort answers. effort answers.
o Mapping can be based on either civic or geospatial location o Mapping can be based on either civic or geospatial location
information, with no performance penalty for either. information, with uniform protocol treatment of both.
o Service regions can overlap. o Support for overlapping service regions.
o Satisfies the requirements [5] for mapping protocols. o Satisfies the requirements [5] for mapping protocols.
o Minimizes round trips by caching individual mappings and by o Minimizes round trips by caching individual mappings and by
supporting return of coverage regions ("hinting"). supporting return of coverage regions ("hinting").
o Facilitates reuse of TLS. o Facilitates reuse of Transport Layer Security (TLS).
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 (seeker or resolver) and the mapping server (resolver
or other servers). The relationship between other functions, such as or other servers). The relationship between other functions, such as
discovery of mapping servers, data replication and the overall discovery of mapping servers, data replication and the overall
mapping server architecture in general, will be described in a mapping server architecture in general, will be described in a
separate document. [12] is a first attempt to describe such a mapping separate document. [20] is a first attempt to describe such a mapping
server architecture. server architecture.
The high-level protocol operation can be described as follows: The high-level protocol operation can be described as follows:
Location Location
Info +----------+ Info +----------+
--------> | | --------> | |
Service | LoST | Service | LoST |
URN | Server | URN | Server |
--------> | | --------> | |
skipping to change at page 4, line 29 skipping to change at page 5, line 29
Optional | LoST | Optional | LoST |
Info (hints)| Server | Info (hints)| Server |
<------- | | <------- | |
+----------+ +----------+
Response Response
Figure 1: Overview Figure 1: Overview
The query message carries location information and a service The query message carries location information and a service
identifier enconded as a Uniform Resource Name (URN) (see [6]) from identifier encoded as a Uniform Resource Name (URN) (see [6]) 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 a Uniform Resource Identifiers database to map the input values to a Uniform Resource Identifiers
(URI) and returns it including optional information such as hints (URI) and returns it including optional information such as hints
about the service boundary in a response message back to the LoST about the service boundary in a response message back to the LoST
client. client.
2. Requirements Notation 2. 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 [3]. document are to be interpreted as described in [3].
3. Usage 3. Usage
The client queries a server, indicating the desired service and the The client queries a server, indicating the desired service and
location object. If the query succeeds, the server returns a result location information. If the query succeeds, the server returns a
that includes one or more URIs for reaching the appropriate service result that includes one or more URIs for reaching the appropriate
for the location indicated. Depending on the query, the result may service for the location indicated. Depending on the query, the
contain a region where the same mapping would apply, a reference to result may contain a service boundary where the same mapping would
another server to which the client should send a query, and error apply, a reference to another server to which the client should send
messages indicating problems with interpretation of location a query, or an error messages indicating problems. The combination
information. The combination of these components are left to the of these components are left to the needs and policy of the
needs and policy of the jurisdiction where the server is being jurisdiction where the server is being operated.
operated.
The client may perform the mapping at any time. Among the common The client may perform the mapping at any time. Among the common
triggers for mapping are: triggers for mapping are:
1. When the client starts up and/or attaches to a new network 1. When the client starts up and/or attaches to a new network
location. location.
2. When the client detects that its location has changed 2. When the client detects that its location has changed
sufficiently that it is outside the bounds of the region returned sufficiently that it is outside the bounds of the region returned
in an earlier query. in an earlier query.
3. When cached mapping information has expired. 3. When cached mapping information has expired.
4. When calling for a particular service. During such calls, a 4. When calling for a particular service. During such calls, a
client MAY request a short response that contains only the client may want to request a short response that contains only
mapping data, omitting region information. In some operational the mapping data, omitting service boundary information.
environments a UDP-based transport may be available and MAY be
used to confirm or update data already available.
Cached answers are expected to be used by clients only after failing Cached answers are expected to be used by clients only after failing
to accomplish a location-to-URI mapping at call time. Cache entries to accomplish a location-to-URI mapping at call time. Cache entries
may expire according to their time-to-live value, or they may become may expire according to their time-to-live value, or they may become
invalid if the location of the caller's device moves outside the invalid if the location of the caller's device moves outside the
boundary limits of the cache entry. Boundaries for cache entries may boundary limits of the cache entry. Boundaries for cache entries may
be set in both geospatial and civic terms. be set in both geospatial and civic terms.
4. Server Discovery 4. Resolving Service URNs Using LoST
There are likely to be a variety of ways that clients can discover If a LoST URL contains a host name rather than an IP address, clients
appropriate LoST servers, including DHCP, SIP device configuration, need to perform an U-NAPTR [17] lookup to obtain a DNS A record and
or DNS records for their signaling protocol domain, e.g., the AOR IP address. These records map the 'host' part of the LoST URL to one
domain for SIP. The appropriate server depends on, among other or more URLs indicating the protocol to carry the LoST request. In
considerations, who operates LoST services, including the Internet this document, only the HTTP and HTTPS URL schemes are defined. Note
Service Provider (ISP), Voice Service Provider (VSP), or the user's that the HTTP URL can be any valid HTTP URL, including those
home domain. A DNS based approach utilizing the S-NAPTR mechanism is containing path elements.
specified in [6].
Here is an example:
example.com.
IN NAPTR 100 10 "u" "LoST:https"
"!*.!https://lostserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "LoST:http"
"!*.!http://lostserver.example.com!" ""
5. Query 5. Query
LoST provides the ability to use civic or geospatial location LoST provides the ability to use civic or geospatial location
information in the query message message. In addition to location information in the query message. In addition to location
information the query also contains a service identifier. An information the query also contains a service identifier. An
optional parameter might furthermore request the LoST server to optional parameter might furthermore request the LoST server to
validate location information. validate location information.
5.1. Location Information Element 5.1. Location Information Element
LoST supports a query using geospatial and civic location information LoST supports a query using geospatial and civic location information
using the findLoSTByCivic and the findLoSTByGeo query. Geospatial using the <findServiceByLocation> query. Geospatial location
location information uses GML format [9] and civic location information uses GML format [10] and civic location information
information utilizes the format defined in [10]. Hence, the location utilizes the format defined in [16]. This document does not define
format is not defined in this document but references already location formats.
available standards.
5.2. Service Identifier Element 5.2. Service Element
The type of service desired is specified by the <service> element. The type of service desired is specified by the <service> element.
The emergency identifiers listed in the registry established with [6] The (emergency) service identifiers listed in the registry
will be used in this document. established with [6] will be used in this document.
The <service> element is a mandatory element. In case the database
at the LoST server does not provided service for the specific
geographical region the LoST server has various choices with regard
to the response:
o It can send an error response.
o It can map one service to another one, if appropriate, and return
a different service identifier as described in Section 6.3.
o It can populate the URIs of one service to another service.
The operation of the LoST server is largely a policy issue. No
behavior is mandated in this document. Guidelines for operating a
LoST server for emergency services is provided in [21].
5.3. Validate Attribute 5.3. Validate Attribute
The 'validate' attribute implements the validation behavior described The 'validate' attribute implements the validation behavior described
in [5]. in [5].
5.4. Query Message Examples 5.4. Query Message Examples
This section shows an example of a query message providing geospatial This section shows an example of a query message providing geospatial
and civic location information. and civic location information.
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<findLoSTByGeo <findServiceByLocation
validate="false"
xmlns:p2="http://www.opengis.net/gml"
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:p2="http://www.opengis.net/gml"
validate="false" operation="recursive">
<p2:location> <locationInfo>
<p2:Point p2:id="point1" srsName="epsg:4326"> <p2:Point id="point1" srsName="epsg:4326">
<p2:coordinates>37:46:30N 122:25:10W</p2:coordinates> <p2:coordinates>37:46:30N 122:25:10W</p2:coordinates>
</p2:Point> </p2:Point>
</p2:location> </locationInfo>
<service>urn:service:sos</service> <service>urn:service:sos.police</service>
</findServiceByLocation>
</findLoSTByGeo>
Figure 2: Query Message Example using Geospatial Location Information Figure 3: Query Message Example using Geospatial Location Information
The example above shows a query using geospatial location information The example above shows a query using geospatial location information
with no validation required and asking for the 'urn:service:sos' with no validation required and asking for the
service. 'urn:service:sos.police' service.
<?xml version="1.0"?>
<findLoSTByCivic
validate="true"
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<?xml version="1.0" encoding="UTF-8"?>
<findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1"
validate="false" operation="recursive">
<locationInfo>
<civicLocation> <civicLocation>
<p2:country>Germany</p2:country> <country>Germany</country>
<p2:A1>Bavaria</p2:A1> <A1>Bavaria</A1>
<p2:A3>Munich</p2:A3> <A3>Munich</A3>
<p2:A6>Neu Perlach</p2:A6> <A6>Neu Perlach</A6>
<p2:HNO>96</p2:HNO> <HNO>96</HNO>
<p2:PC>81675</p2:PC> <PC>81675</PC>
</civicLocation> </civicLocation>
</locationInfo>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findServiceByLocation>
</findLoSTByCivic> Figure 4: Query Message Example using Civic Location Information
Figure 3: Query Message Example using Civic Location Information
The example above shows a query using a civic location in Munich The example above shows a query using a civic location in Munich
asking for the 'urn:service:sos' service. The query also indicates asking for the 'urn:service:sos.police' service. The query indicates
that validation is desired. that validation is not desired and the query has to be executed
recursively.
6. Response 6. Response
A response message might either be a responseGeo or a responseCivic A response message might either contain civic or geospatial location
depending on the type of query message. If the query message was a information depending on the type of the query. If the
findLoSTByCivic then the response will be a responseCivic. If a findServiceByLocation query message contained civic location
findLoSTByGeo message was sent as a query then the response will be a information then the <serviceBoundary> element of the response
findLoSTByGeo. The location information that is provided by the message will also contain civic information. If the
response message depends on the query and refers to the service findServiceByLocation query message contained geospatial location
boundary as described in Section 6.3. information then the <serviceBoundary> element of the response
message will contain a GML polygon. More information about the
<serviceBoundary> element can be found at Section 6.4.
6.1. Uniform Resource Identifiers (URI) Element 6.1. Uniform Resource Identifiers (URI) Element
Each uri element contains an appropriate contact URI for the service Each <uri> element contains an appropriate contact URI for the
for which mapping was requested. uri elements are of type xs:anyURI. service for which mapping was requested. <uri> elements are of type
In the emergency service context operators are strongly discouraged xs:anyURI. In the emergency service context operators are strongly
from using relative URIs, even though these are permitted by the discouraged from using relative URIs, even though these are permitted
type. by the type.
6.2. Display Name Element Element 6.2. Display Name Element
Each displayName element contains a string that is suitable for Each <displayName> element contains a string that is suitable for
display. displayName elements are of type "text" as described in display. <displayName> elements are of type "text" that is suitable
Section 6.7. for internationalized human-readable text.
6.3. Region Element 6.3. Service Element
Each region element contains either one or more civic location The <service> element is an optional element in the response message.
elements derived from the GeoPriv civic address schema or feature.xsd The (emergency) service identifiers listed in the registry
expression from GML. established with [6] will be used in this document. If the service
that was requested by the LoST client is not available for a
particular location then the server MAY return an alternate service.
If it does so, it MUST indicate the actual service returned (i.e.,
its service URN). Alternatively, the LoST server MAY return an error
response indicating that the requested service is not available.
6.4. Dialstring Element The following example illustrates the main idea. If there is a
region that only understands the 'urn:service:sos' service and not
'urn:service:sos.fire', 'urn:service:sos.ambulance', and
'urn:service:sos.police'. If a LoST client asks for the
'urn:service:sos.fire' service then the LoST server could, depending
on the local policy at the LoST server, return:
Each dialstring element contains from one to sixteen digits. Note 1. 'urn:service:sos', or
that a Tel URI may also contain the same target, expressed in a
different format; see RFC 3966 [11].
6.5. TimeToLive Attribute 2. 'urn:service:sos.fire' with the values of 'urn:service:sos' being
populated to 'urn:service:sos.fire', or
3. an error message
In case of (1) the <service> element carries the value of
'urn:service:sos'.
6.4. ServiceBoundary Element
Each <serviceBoundary> element contains either one or more civic
location elements derived from the GeoPriv civic address schema or a
GML-based polygon.
The <serviceBoundary> element indicates where the same query would
yield to the same response, i.e., it provides information about the
service boundary.
6.5. ServiceNumber Element
TBD: This element contains the (emergency) service number, which is a
string of digits used to reach the (emergency) service.
6.6. TimeToLive Attribute
Each timeToLive attribute is a positive integer, expressing the Each timeToLive attribute is a positive integer, expressing the
validity period of the response in seconds. validity period of the response in seconds. The LoST client MUST NOT
consider the returned location current after the expiration of the
validity period.
6.6. Validated Element 6.7. Validation Element
Each validated element contains a string which is composed by by The <validation> element contains a string that is composed of
concatenating the elements from the request which have been concatenated tokens separated by a whitespace. These tokens refer to
recognized as valid by the server. the civic location labels used in child elements of the
<civicAddress> element from the request that have been recognized as
valid by the server.
6.7. text Attribute The following code snippet indicates that the civic address labels
'country', 'A1', 'A3', 'A6, 'PC' have been valided by the LoST
server.
This is a text type suitable for internationalized human readable <validation>country A1 A3 A6 PC</validation>
text.
6.8. Response Message Examples 6.8. Response Message Examples
This section shows an example of a query message providing geospatial This section shows an example of a query message providing geospatial
and civic location information. and civic location information.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<responseGeo <response
timeToLive="10000"
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p2="http://www.opengis.net/gml"> xmlns:p2="http://www.opengis.net/gml">
<result status="200" message="OK" xml:lang="en" timeToLive="1000">
<displayName>New York City Police Department</displayName> <displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service>
<serviceBoundary>
<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>
<uri>sip:nypd@example.com</uri> <uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri>
<dialstring>911</dialstring> <serviceNumber>911</serviceNumber>
</result>
</responseGeo> </response>
Figure 4: Response Message Example using Geospatial Location Service Figure 6: Response Message Example using Geospatial Location Service
Boundary Hints Boundary Hints
This example shows a reponse with two URIs for the previously queried This example shows a response with two URIs for the previously
service URN. Information about the service boundary is provided in queried service URN. Information about the service boundary is
the Polyon. The <dialstring> element indicates the valid dialstring provided by a GML polygon. The <serviceNumber> element indicates the
for the expressed location and service URN. valid service number for the expressed location and service URN.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<responseCivic <response xmlns="urn:ietf:params:xml:ns:lost1">
timeToLive="10000" <result status="200" timeToLive="10000">
xmlns="urn:ietf:params:xml:ns:lost1" <displayName xml:lang="de">Munich Police Department</displayName>
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <service>urn:service:sos.police</service>
xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"> <serviceBoundary>
<civicLocation>
<displayName>Munich Police Department</displayName> <country>Germany</country>
<region> <A1>Bavaria</A1>
<p2:country>Germany</p2:country> <A3>Munich</A3>
<p2:A1>Bavaria</p2:A1> <PC>81675</PC>
<p2:A3>Munich</p2:A3> </civicLocation>
</region> </serviceBoundary>
<validated>country A1 A3 A6 PC</validated>
<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>
<dialstring>110</dialstring> <service-number>110</service-number>
</result>
</responseCivic> </response>
Figure 5: Response Message Example providing Civic Location Service Figure 7: Response Message Example providing Civic Location Service
Boundary Hints Boundary Hints
This example shows a response that returns two URIs (one for SIP and This example shows a response that returns two URIs (one for SIP and
another one for XMPP), a distring that indicates the valid distring another one for XMPP), a distring that indicates the valid distring
for the location provided in the query, a hint about the service for the location provided in the query, a hint about the service
boundary in the <region> element and information about the validated boundary in the <serviceBoundary> element and information about the
civic address fields. The timeToLive indicates that the returned validated civic address fields. The timeToLive attribute indicates
information can be cached for 10000 seconds and provides a that the returned information can be cached for 10000 seconds and
displayName with additional, textual information about the returned provides a *<displayName> element with additional, textual
information. information about the returned information.
7. Miscellaneous Functionality 7. List Services Query and Response
7.1. List Service Query 7.1. List Service Query
This subsection describes a query that offers the LoST client to This subsection describes a mechanism that offers the LoST client to
query for available service identifiers supported by the LoST server. query for available service identifiers supported by the LoST server.
The listServices query MUST carry the <locationInfo> and the
<service> element. The LoST server MUST return only immediate child
elements of the service identifier specified in the <service> element
of the listServices query available for the provided location
information.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<listServices <listServices
xmlns="urn:ietf:params:xml:ns:lost1" xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> xmlns:p2="http://www.opengis.net/gml"
operation="false">
<locationInfo>
<p2:Point id="point1" srsName="epsg:4326">
<p2:coordinates>37:46:30N 122:25:10W</p2:coordinates>
</p2:Point>
</locationInfo>
<service>urn:service:sos</service> <service>urn:service:sos</service>
</listServices> </listServices>
Figure 6: Example for a List Service Query Figure 8: Example for a List Service Query
This listService query aims to query the immediate child elements of This listService query aims to query the immediate child elements of
the 'urn:service:sos' URN. the 'urn:service:sos' URN.
7.2. Response to a List Service Query 7.2. List Service Response
This subsection describes the response message that provides the LoST This subsection describes the response message that provides the LoST
client with the list of immediate child service identifiers based on client with the list of immediate child service identifiers based on
the service identifier provided by LoST client in the query. the service identifier provided by LoST client with respect to the
location information provided in the listService query.
The following example shows the response to the listServices query
example of Figure 8 listing the available services offered by the
LoST server starting with 'urn:service:sos.ambulance' and finishing
with 'urn:service:sos.suicide'.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<returnServices <response xmlns="urn:ietf:params:xml:ns:lost1">
timeToLive="10000" <serviceList status="200" message="OK" xml:lang="en">
xmlns="urn:ietf:params:xml:ns:lost1" urn:service:sos.ambulance
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> urn:service:sos.animal-control
urn:service:sos.fire
urn:service:sos.gas
urn:service:sos.mountain
urn:service:sos.marine
urn:service:sos.physician
urn:service:sos.poison
urn:service:sos.police
urn:service:sos.suicide
</serviceList>
</response>
<service>urn:service:sos.ambulance</service> Figure 9: Example for the Response to a List Service Query
<service>urn:service:sos.animal-control</service>
<service>urn:service:sos.fire</service> 8. Status Code Definitions
<service>urn:service:sos.gas</service>
<service>urn:service:sos.mountain</service> Each response contains a <status> element that conveys a numeric
<service>urn:service:sos.marine</service> status code and a reason phrase indicating the success or failure of
<service>urn:service:sos.physician</service> the response. The appearance of other elements in the response
<service>urn:service:sos.poison</service> depends on the status code. Hence, different elements are used for
groups of status codes.
Status codes always have three digits; the list of status codes is
meant to be extensible by IANA registration and follows the general
pattern of the Session Initiation Protocol (SIP) [22] and HTTP [14].
The first digit indicates the type of response, with '2' signaling a
successful request, '3' a redirection, '4' a request failure due to
client behavior, and '5' a server failure.
If used within HTTP, LoST also utilizes the normal HTTP status codes.
However, the HTTP request can succeed, while the LoST request caused
an error. All LoST status codes appear in HTTP 200 (OK) responses.
For example, a LoST 404, 414 or 500 status would occur in an HTTP 200
response.
Temporary unavailability of the service should be indicated by an
HTTP 505 (Service Unavailable) status code.
[Editor's Note: Does this make any sense or should all or some LoST
errors occur in a non-200 HTTP response?]
8.1. Informational 1xx
This document does not define informational status codes.
8.2. Successful 2xx
8.2.1. 200 OK
The query completed successfully.
8.2.2. 201 Service Substitution
The service requested is not available for the location requested,
but the server is configured to provide a replacement service.
8.3. Redirection 3xx
8.3.1. 301 Move Permanently
The requested location is being mapped by a different server and all
future requests for that location (and locations in the service area)
should be directed to that server.
8.3.2. 302 Moved Temporarily
The requested location is being mapped by a different server, but
future requests should continue to use this server.
8.3.3. Example
This is an example of an error message with a 302 status code:
<?xml version="1.0" encoding="UTF-8"?>
<response xmlns="urn:ietf:params:xml:ns:lost1">
<redirect status="302"
message="County-level routing"
xml:lang="en"
redirect="lost:co.lancaster.pa.us"
</response>
8.4. Client Error 4xx
8.4.1. 400 Bad Request
The request could not be understood due to malformed syntax.
8.4.2. 403 Forbidden
The server understood the request, but is refusing to fulfill it.
Authorization will not help, and the request SHOULD NOT be repeated.
8.4.3. 404 Not Found
The server has definitive information that there is no service
mapping for the location specified.
8.4.4. 414 Location Error
The location provided does not exist or fields within the location
information are contradictory.
8.4.5. Example
The first example shows an error message with a 414 status code that
is attached to the response message indicating that there was a
problem with the postal code:
<?xml version="1.0" encoding="UTF-8"?>
<response xmlns="urn:ietf:params:xml:ns:lost1">
<result status="250" message="Default Route"
xml:lang="en" timeToLive="10000">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>unknown</service>
<serviceBoundary>
<civicLocation>
<country>US</country>
<A1>New York</A1>
<A3>New York</A3>
</civicLocation>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<service-number>911</service-number>
</result>
<failure status="414" message="Address error" xml:lang="en">
<cause name="PC"
message="postal code is outside of service boundary"
xml:lang="en" />
</failure>
</response>
The second example shows an error message with a 414 status code that
is attached to the response message indicating that there was a
problem with the provided geospatial location information:
<?xml version="1.0" encoding="UTF-8"?>
<response
xmlns="urn:ietf:params:xml:ns:lost1"
xmlns:p2="http://www.opengis.net/gml" >
<result status="250" message="Default PSAP"
xml:lang="en" timeToLive="1000">
<displayName xml:lang="en">
New York City Police Department
</displayName>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
<service>urn:service:sos.suicide</service> <serviceBoundary>
<p2:Polygon srsName="urn:ogc:def::crs:EPSG::4326">
<p2:exterior>
<p2:LinearRing>
<p2:pos>37.775 -122.4194</p2:pos>
<p2:pos>37.555 -122.4194</p2:pos>
<p2:pos>37.555 -122.4264</p2:pos>
<p2:pos>37.775 -122.4264</p2:pos>
<p2:pos>37.775 -122.4194</p2:pos>
</p2:LinearRing>
</p2:exterior>
</p2:Polygon>
</serviceBoundary>
<uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri>
<serviceNumber>911</serviceNumber>
</result>
<failure status="414"
message="Invalide Goegraphic Location" xml:lang="en">
<cause name="p2:coordinates"
message="invalid latitude" xml:lang="en" />
</failure>
</response>
</returnServices> 8.5. Server Error 5xx
Figure 7: Example for the Response to a List Service Query 8.5.1. 500 Server Internal Error
This response corresponds to the query of Figure 6. The server encountered an unexpected condition that prevented it from
fulfilling the request. The client MAY retry the request after
several seconds.
8. Example 8.5.2. 501 Service Not Implemented
The server does not implement mapping for the service requested and
cannot provide an alternate service.
8.5.3. 504 Server Time-Out
A server time-out occurs if the server contacted tries to recursively
resolve the query, but cannot get an answer within the time limit set
for the query.
8.5.4. Example
This is an example of an error message with a 500 status code:
<?xml version="1.0" encoding="UTF-8"?>
<response xmlns="urn:ietf:params:xml:ns:lost1">
<status code="500">Server failure</status>
</response>
9. LoST Transport
LoST needs an underlying protocol transport mechanisms to carry
requests and responses. This document defines the use of LoST over
HTTP and HTTP-over-TLS; other mechanisms are left to future
documents. The available transport mechanisms are indicated in the
LoST U-NAPTR DNS resource record. In protocols that support content
type indication, LoST uses the media type application/lost+xml.
When using HTTP [14] and HTTP-over-TLS [15], LoST requests use the
HTTP POST method. All HTTP responses are applicable. The HTTP URL
is derived from the LoST URL via U-NAPTR translation, as discussed in
Section 4.
10. LoST Uniform Resource Locators
LoST Uniform Resource Locators (URLs) follow the format of URLs
defined in RFC 3986 [9], with the following ABNF:
LoST-URI = "lost:" host
'host' is defined in Section 3.2.2 of RFC 3986 [9].
An example is 'lost:lostserver.example.com'
11. Example
After performing link layer attachment and end host performs stateful After performing link layer attachment and end host performs stateful
address autoconfiguration (in our example) using DHCP. Then, DHCP address autoconfiguration (in our example) using DHCP. Then, DHCP
provides the end host with civic location as described in[7]. provides the end host with civic location as described in [19].
+--------+---------------+ +--------+---------------+
| CAtype | CAvalue | | CAtype | CAvalue |
+--------+---------------+ +--------+---------------+
| 0 | US | | 0 | US |
| 1 | New York | | 1 | New York |
| 3 | New York | | 3 | New York |
| 6 | Broadway | | 6 | Broadway |
| 22 | Suite 75 | | 22 | Suite 75 |
| 24 | 10027-0401 | | 24 | 10027-0401 |
+--------+---------------+ +--------+---------------+
Figure 8: DHCP Civic Information Example Figure 14: DHCP Civic Information Example
Additionally, DHCP may provide information about the LoST server that Additionally, DHCP may provide information about the LoST server that
can be contacted. Alternatively, an additional step of indirection can be contacted. Alternatively, an additional step of indirection
is possible, for example by having DHCP return a domain name that has is possible, for example by having DHCP return a domain name that has
to be resolved to one or more IP addresses hosting LoST servers. to be resolved to one or more IP addresses hosting LoST servers.
Both at attachment time and call time, the client places a LoST Both at attachment time and call time, the client places a LoST
request, including its civic location and the desired service. The request, including its civic location and the desired service. The
request is shown below: request is shown below:
<?xml version="1.0"?> <?xml version="1.0" encoding="UTF-8"?>
<findLoSTByCivic <findServiceByLocation xmlns="urn:ietf:params:xml:ns:lost1"
validate="true" validate="false" operation="recursive">
xmlns="urn:ietf:params:xml:ns:lost1" <locationInfo>
xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<civicLocation> <civicLocation>
<p2:country>US</p2:country> <country>US</country>
<p2:A1>New York</p2:A1> <A1>New York</A1>
<p2:A3>New York</p2:A3> <A3>New York</A3>
<p2:A6>Broadway</p2:A6> <A6>Broadway</A6>
<p2:LOC>Suite 75</p2:LOC> <LOC>Suite 75</LOC>
<p2:PC>10027-0401</p2:PC> <PC>10027-0401</PC>
</civicLocation> </civicLocation>
</locationInfo>
<service>urn:service:sos.police</service> <service>urn:service:sos.police</service>
</findServiceByLocation>
</findLoSTByCivic> Mapping Request
Since the contacted LoST server has the requested information Since the contacted LoST server has the requested information
available the following response is returned. The response available the following response is returned. The <displayName>
indicates, as a human readable display string that the 'New York City element indicates, as a human readable display string, that the 'New
Police Department' is responsible for the given geographical area. York City Police Department' is responsible for the given
The indicated URI allows the user to start communication using SIP or geographical area. The indicated URI allows the user to start
XMPP. The 'validated' element indicates which parts of the civic communication using SIP or XMPP. The <validation> element indicates
address were matched successfully against a database and represent a which parts of the civic address were matched successfully against a
known address. Other parts of the address, here, the suite number, database and represent a known address. Other parts of the address,
were ignored and not validated. The returned service boundary here, the suite number, were ignored and not validated. The
indicates that all of New York City would result in the same <serviceBoundary> element indicates that all of New York City would
response. The dialstring element indicates that the service can be result in the same response. The <serviceNumber> element indicates
reached via the dial string 9-1-1. that the service can be reached via the emergency service number 911.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<responseCivic <response xmlns="urn:ietf:params:xml:ns:lost1">
timeToLive="10000" <result status="200" message="OK" xml:lang="en" timeToLive="10000">
xmlns="urn:ietf:params:xml:ns:lost1" <displayName xml:lang="en">
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" New York City Police Department
xmlns:p2="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"> </displayName>
<service>unknown</service>
<displayName>New York City Police Department</displayName> <serviceBoundary>
<region> <civicLocation>
<p2:country>US</p2:country> <country>US</country>
<p2:A1>New York</p2:A1> <A1>New York</A1>
<p2:A3>New York</p2:A3> <A3>New York</A3>
</region> </civicLocation>
<validated>country A1 A3 A6 PC</validated> </serviceBoundary>
<uri>sip:nypd@example.com</uri> <uri>sip:nypd@example.com</uri>
<uri>xmpp:nypd@example.com</uri> <uri>xmpp:nypd@example.com</uri>
<dialstring>911</dialstring> <service-number>911</service-number>
</result>
</response>
</responseCivic> Mapping Response
9. Deployment Methods 12. Deployment Methods
Because services for emergency contact resolution may differ Because services for emergency contact resolution may differ
depending on local or service needs, this document only specifies the depending on local or service needs, this document only specifies the
"wire format" for LoST services and explicitly leaves open the "wire format" for LoST services and explicitly leaves open the
possibility for many different types of deployment. possibility for many different types of deployment.
For instance: For instance:
During discovery, a client may be directed to issue all queries to During discovery, a client may be directed to issue all queries to
an LoST service completely authoritative for a given jursidiction. an LoST service completely authoritative for a given jurisdiction.
A client may be directed to issue queries to an LoST server that A client may be directed to issue queries to an LoST server that
acts as a reflector. In such a case, the LoST server analyzes the acts as a reflector. In such a case, the LoST server analyzes the
query to determine the best server to wich to refer the client. query to determine the best server to which to refer the client.
Or the client may be directed to a server that performs further Or the client may be directed to a server that performs further
resolution on behalf of the client. resolution on behalf of the client.
A LoST service may also be represented by multiple LoST servers, A LoST service may also be represented by multiple LoST servers,
either grouped together or at multiple network locations. Using either grouped together or at multiple network locations. Using
S-NAPTR [13], clients may be given a list of multiple servers to S-NAPTR [24], clients may be given a list of multiple servers to
which queries can be sent for a single service. which queries can be sent for a single service.
For instance, the service at emergency.example.com may advertise LoST For instance, the service at emergency.example.com may advertise LoST
service at local1.emergency.example.com, service at local1.emergency.example.com,
local2.emergency.example.com, and master.emergency.example.com. Each local2.emergency.example.com, and master.emergency.example.com. Each
server may given a different preference. In this case, 'local-1' and server may given a different preference. In this case, 'local-1' and
'local-2' may be given a lower preference (more preferred) than 'local-2' may be given a lower preference (more preferred) than
'master', which might be a busier server or located further away. 'master', which might be a busier server or located further away.
+-----------+ pref 10 +-----------+ +-----------+ pref 10 +-----------+
skipping to change at page 19, line 5 skipping to change at page 28, line 5
\ --------->| local-2 | \ --------->| local-2 |
\ | | \ | |
\ +-----------+ \ +-----------+
\ \
\ +-----------+ \ +-----------+
\ pref 20 | | \ pref 20 | |
------------------------->| master | ------------------------->| master |
| | | |
+-----------+ +-----------+
10. XML Schema 13. Relax NG Schema
This section provides the XML schema used by LoST. This section provides the Relax NG schema used by LoST protocol in
the compact form. The verbose form is included in Appendix A.
<?xml version="1.0" encoding="UTF-8"?> default namespace = "urn:ietf:params:xml:ns:lost1"
<schema xmlns="http://www.w3.org/2001/XMLSchema" namespace a = "http://relaxng.org/ns/compatibility/annotations/1.0"
targetNamespace="urn:ietf:params:xml:ns:lost1" namespace ns1 = "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:lost="urn:ietf:params:xml:ns:lost1" namespace ns2 = "http://www.opengis.net/gml"
xmlns:civilLoc="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
xmlns:gml="http://www.opengis.net/gml"
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<annotation> ##
<documentation> ## Location-to-Service Translation Protocol (LoST)
A schema for a Location to Service Translation Protocol ##
</documentation> ## A LoST XML instance has three "root" types:
</annotation> ## the findServiceByLocation query, the listServices query,
## and the response to these queries.
##
start = findServiceByLocation | listServices | response
<!-- --> ##
<!-- Query types --> ## The queries.
<!-- --> ##
div {
findServiceByLocation =
element findServiceByLocation {
query,
attribute validate { xsd:boolean >> a:defaultValue [ "false" ] }?
}
listServices = element listServices { query }
}
<!-- Abstract Query --> ##
## The response.
##
div {
response =
element response {
<complexType name="queryType"/> ##
<element name="query" type="lost:queryType" abstract="true"/> ## 2xx responses.
##
(result
| element serviceList {
list { xsd:anyURI* },
status
})?,
##
## 3xx, 4xx, and 4xx responses.
##
((error | redirect | failure)?),
extensionPoint
}
}
<!-- findLoSTByCivic --> ##
## Query pattern.
##
div {
query =
element locationInfo { anyElement* },
element service { xsd:anyURI },
extensionPoint,
[ a:defaultValue [ "recursive" ] ] attribute operation { text }?
}
<element name="findLoSTByCivic" type="lost:findLoSTByCivicType" ##
substitutionGroup="lost:query"/> ## A result.
##
div {
<complexType name="findLoSTByCivicType"> ##
<complexContent> ## 2xx response.
<extension base="lost:queryType"> ##
<sequence> result =
<element name="civilAddress" element result {
type="civilLoc:civilAddress" element displayName {
minOccurs="0" maxOccurs="1"/> xsd:string,
<element name="service" type="anyURI" attribute xml:lang { xsd:language }
minOccurs="1" maxOccurs="1"/> }?,
</sequence> element service { xsd:anyURI },
<attribute name="validate" element serviceBoundary {
type="boolean" default="false"/> (civicLocation, polygon?) | (civicLocation?, polygon)
</extension> }?,
</complexContent> element uri { xsd:anyURI }+,
</complexType> element serviceNumber {
xsd:string { pattern = "[0-9]+" }
}?,
element validation {
list { xsd:QName* }
}?,
extensionPoint,
attribute timeToLive { xsd:positiveInteger },
status
}
}
<!-- findLoSTByGeo --> ##
## Non-result responses.
##
div {
<element name="findLoSTByGeo" type="lost:findLoSTByGeoType" ##
substitutionGroup="lost:query"/> ## 5xx response.
##
error = element error { status, extensionPoint }
<complexType name="findLoSTByGeoType"> ##
<complexContent> ## 3xx response.
<extension base="lost:queryType"> ##
<sequence> redirect =
<element ref="gml:location" element redirect {
minOccurs="0" maxOccurs="1"/> status,
<element name="service" type="anyURI" attribute redirect { xsd:anyURI },
minOccurs="1" maxOccurs="1"/> extensionPoint
</sequence> }
<attribute name="validate"
type="boolean" default="false"/>
</extension>
</complexContent>
</complexType>
<!-- listServices --> ##
## 4xx response.
##
failure =
element failure {
status,
element cause {
attribute name { xsd:QName },
attribute message { xsd:string },
attribute xml:lang { xsd:language }
}*,
extensionPoint
}
}
<element name="listServices" type="lost:listServicesType" ##
substitutionGroup="lost:query"/> ## Status pattern.
##
div {
status =
attribute status { xsd:positiveInteger },
attribute extendedStatus { xsd:positiveInteger }?,
(attribute message { xsd:string },
attribute xml:lang { xsd:language })?
}
##
## Patterns for inclusion of elements from schemas in
## other namespaces.
##
div {
<complexType name="listServicesType"> ##
<complexContent> ## A wildcard pattern for including any element
<extension base="lost:queryType"> ## from any other namespace.
<sequence> ##
<element name="service" type="anyURI" anyElement =
minOccurs="1" maxOccurs="1"/> element * {
</sequence> (attribute * { text }
</extension> | text
</complexContent> | anyElement)*
</complexType> }
<!-- --> ##
<!-- Responses --> ## A point where future extensions
<!-- --> ## (elements from other namesapces)
## can be added.
##
extensionPoint = anyElement*
<!-- Abstract Response --> ##
<element name="result" type="lost:resultType" abstract="true"/> ## A pattern to include the GEOPRIV civil location elements.
##
civicAddress =
element ns1:* {
(attribute * { text }
| text
| anyElement)*
}
<complexType name="resultType"> ##
<attribute name="timeToLive" type="positiveInteger" ## A definition of civic location from GEOPRIV.
use="required" /> ##
</complexType> civicLocation = element civicLocation { civicAddress*, anyElement* }
<!-- emergencyContact Response --> ##
## A pattern to include GML elements.
##
GML =
element ns2:* {
(attribute * { text }
| text
| anyElement)*
}
polygon =
element ns2:Polygon {
attribute * { text }*,
GML
}
}
<element name="responseCivic" type="lost:responseCivicType" 14. Internationalization Considerations
substitutionGroup="lost:result"/>
<complexType name="responseCivicType"> This mechanism is largely for passing protocol information from one
<complexContent> subsystem to another; as such, most of its elements are tokens not
<extension base="lost:resultType"> meant for direct human consumption. If these tokens are presented to
<sequence> the end user, some localization may need to occur. The content of
<element name="displayName" the <displayName> element may be displayed to the end user, and it is
type="normalizedString" thus a complex type designed for this purpose.
minOccurs="0" maxOccurs="1"/>
<element name="civilAddress"
type="civilLoc:civilAddress"
minOccurs="0" maxOccurs="1" />
<element name="uri" type="anyURI"
minOccurs="0"
maxOccurs="unbounded" />
<element name="dialstring"
type="normalizedString"
minOccurs="0" maxOccurs="1" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="responseGeo" type="lost:responseGeoType" 15. IANA Considerations
substitutionGroup="lost:result"/>
<complexType name="responseGeoType"> 15.1. Content-type registration for 'application/lost+xml'
<complexContent>
<extension base="lost:resultType">
<sequence>
<element name="displayName"
type="normalizedString"
minOccurs="0" maxOccurs="1"/>
<element ref="gml:Polygon"
minOccurs="0" maxOccurs="1"/>
<element name="uri" type="anyURI"
minOccurs="0"
maxOccurs="unbounded"/>
<element name="dialstring"
type="normalizedString"
minOccurs="0" maxOccurs="1" />
</sequence>
</extension>
</complexContent>
</complexType>
<element name="returnServices" type="lost:returnServicesType" This specification requests the registration of a new MIME type
substitutionGroup="lost:result"/> according to the procedures of RFC 4288 [13] and guidelines in RFC
3023 [12].
<complexType name="returnServicesType"> MIME media type name: application
<complexContent>
<extension base="lost:resultType">
<sequence>
<element name="service" type="anyURI"
minOccurs="1" maxOccurs="unbounded"/>
</sequence>
</extension>
</complexContent>
</complexType>
<!-- --> MIME subtype name: lost+xml
<!-- Error responses -->
<!-- -->
<element name="genericCode" type="lost:codeType" Mandatory parameters: none
abstract="true"/>
<element name="invalidCivicData" type="lost:codeType" Optional parameters: charset
substitutionGroup="lost:genericCode"/>
<element name="invalidGeoData" type="lost:codeType" Indicates the character encoding of enclosed XML.
substitutionGroup="lost:genericCode"/>
<element name="invalidService" type="lost:codeType" Encoding considerations:
substitutionGroup="lost:genericCode"/>
<complexType name="codeType"> Uses XML, which can employ 8-bit characters, depending on the
<sequence minOccurs="0" maxOccurs="unbounded"> character encoding used. See RFC 3023 [12], Section 3.2.
<element name="explanation">
<complexType>
<simpleContent>
<extension base="string">
<attribute name="language"
type="language"
use="required"/>
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>
</schema>
11. Internationalization Considerations Security considerations:
This mechanism is largely for passing protocol information from one This content type is designed to carry LoST protocol payloads.
subsystem to another; as such, most of its elements are tokens not
meant for direct human consumption. If these tokens are presented to
the end user, some localization may need to occur. The content of
the displayName element may be displayed to the end user, and it is
thus a complex type designed for this purpose.
12. IANA Considerations Interoperability considerations: None
TBD, such as namespace registrations. Published specification: RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please
replace XXXX with the RFC number of this specification.] this
document
13. Security Considerations Applications which use this media type:
Emergency and Location-based Systems
Additional information:
Magic Number: None
File Extension: .lostxml
Macintosh file type code: 'TEXT'
Personal and email address for further information: Hannes
Tschofenig, Hannes.Tschofenig@siemens.com
Intended usage: LIMITED USE
Author:
This specification is a work item of the IETF ECRIT working group,
with mailing list address <ecrit@ietf.org>.
Change controller:
The IESG <iesg@ietf.org>
15.2. LoST Relax NG Schema Registration
URI: urn:ietf:params:xml:ns:lost
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
Relax NG Schema: The Relax NG schema to be registered is contained
in Section 13. Its first line is
default namespace = "urn:ietf:params:xml:ns:lost1"
and its last line is
}
15.3. LoST Namespace Registration
URI: urn:ietf:params:xml:ns:lost
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>LoST Namespace</title>
</head>
<body>
<h1>Namespace for LoST</h1>
<h2>urn:ietf:params:xml:ns:lost</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
15.4. Registration Template
This registration template is in accordance with [8].
URL scheme name:
lost
URL scheme syntax:
See Section 10
Character encoding considerations:
See Section 10
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 16
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. Security Considerations
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, LoST To avoid that an attacker can modify the query or its result, the
RECOMMENDS the use of channel security, such as TLS. authors RECOMMEND the use of channel security, such as TLS, with
LoST.
A more detailed description of threats and security requirements are A more detailed description of threats and security requirements are
provided in [4]. provided in [4].
[Editor's Note: A future version of this document will describe the 17. Acknowledgments
countermeasures based on the security requirements outlined in[4].]
14. Open Issues [Editor's Note: Names need to be added here. Forgot it...Sorry.]
18. 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/
15. References 19. References
15.1. Normative References 19.1. Normative References
[1] World Wide Web Consortium, "XML Schema Part 2: Datatypes", [1] World Wide Web Consortium, "XML Schema Part 2: Datatypes",
W3C XML Schema, October 2000, W3C XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>. <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
[2] World Wide Web Consortium, "XML Schema Part 1: Structures", [2] World Wide Web Consortium, "XML Schema Part 1: Structures",
W3C XML Schema, October 2000, W3C XML Schema, October 2000,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>. <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Taylor, T., "Security Threats and Requirements for Emergency [4] Taylor, T., "Security Threats and Requirements for Emergency
Call Marking and Mapping", draft-ietf-ecrit-security-threats-01 Call Marking and Mapping", draft-ietf-ecrit-security-threats-03
(work in progress), April 2006. (work in progress), July 2006.
[5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency [5] Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", Context Resolution with Internet Technologies",
draft-ietf-ecrit-requirements-10 (work in progress), June 2006. draft-ietf-ecrit-requirements-12 (work in progress),
August 2006.
[6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services", [6] Schulzrinne, H., "A Uniform Resource Name (URN) for Services",
draft-ietf-ecrit-service-urn-03 (work in progress), May 2006. draft-ietf-ecrit-service-urn-05 (work in progress),
August 2006.
[7] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 [7] Mealling, M., "The IETF XML Registry",
and DHCPv6) Option for Civic Addresses Configuration draft-mealling-iana-xmlns-registry-05 (work in progress),
Information", draft-ietf-geopriv-dhcp-civil-09 (work in June 2003.
progress), January 2006.
[8] Mealling, M., "The IETF XML Registry", [8] Petke, R. and I. King, "Registration Procedures for URL Scheme
draft-mealling-iana-xmlns-registry-03 (work in progress), Names", BCP 35, RFC 2717, November 1999.
November 2001.
[9] OpenGIS, "Open Geography Markup Language (GML) Implementation [9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[10] OpenGIS, "Open Geography Markup Language (GML) Implementation
Specification", OGC OGC 02-023r4, January 2003. Specification", OGC OGC 02-023r4, January 2003.
[10] Peterson, J., "A Presence-based GEOPRIV Location Object [11] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005. Format", RFC 4119, December 2005.
15.2. Informative References [12] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[11] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, [13] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[14] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[15] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[16] Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-02 (work in
progress), April 2006.
[17] Daigle, L., "Domain-based Application Service Location Using
URIs and the Dynamic Delegation Discovery Service (DDDS)",
draft-daigle-unaptr-00 (work in progress), June 2006.
19.2. Informative References
[18] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004. December 2004.
[12] Schulzrinne, H., "Location-to-URL Mapping Architecture and [19] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4
Framework", draft-schulzrinne-ecrit-mapping-arch-00 (work in and DHCPv6) Option for Civic Addresses Configuration
progress), October 2005. Information", draft-ietf-geopriv-dhcp-civil-09 (work in
progress), January 2006.
[13] Daigle, L. and A. Newton, "Domain-Based Application Service [20] Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", draft-ietf-ecrit-mapping-arch-00 (work in
progress), August 2006.
[21] Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling",
draft-rosen-sos-phonebcp-01 (work in progress), June 2006.
[22] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-10 (work in
progress), August 2006.
[24] Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005. Service (DDDS)", RFC 3958, January 2005.
Appendix A. Non-Normative RELAX NG Schema in XML Syntax
<?xml version="1.0" encoding="UTF-8"?>
<grammar ns="urn:ietf:params:xml:ns:lost1"
xmlns="http://relaxng.org/ns/structure/1.0"
xmlns:a="http://relaxng.org/ns/compatibility/annotations/1.0"
datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
<start>
<a:documentation>
Location-to-Service Translation Protocol (LoST)
A LoST XML instance has three "root" types:
the findServiceByLocation query, the listServices query,
and the response to these queries.
</a:documentation>
<choice>
<ref name="findServiceByLocation" />
<ref name="listServices" />
<ref name="response" />
</choice>
</start>
<div>
<a:documentation>
The queries.
</a:documentation>
<define name="findServiceByLocation">
<element name="findServiceByLocation">
<ref name="query" />
<optional>
<attribute name="validate">
<data type="boolean" />
<a:defaultValue>false</a:defaultValue>
</attribute>
</optional>
</element>
</define>
<define name="listServices">
<element name="listServices">
<ref name="query" />
</element>
</define>
</div>
<div>
<a:documentation>
The response.
</a:documentation>
<define name="response">
<element name="response">
<optional>
<choice>
<a:documentation>
2xx responses.
</a:documentation>
<ref name="result" />
<element name="serviceList">
<list>
<zeroOrMore>
<data type="anyURI" />
</zeroOrMore>
</list>
<ref name="status" />
</element>
</choice>
</optional>
<optional>
<a:documentation>
3xx, 4xx, and 4xx responses.
</a:documentation>
<choice>
<ref name="error" />
<ref name="redirect" />
<ref name="failure" />
</choice>
</optional>
<ref name="extensionPoint" />
</element>
</define>
</div>
<div>
<a:documentation>
Query pattern.
</a:documentation>
<define name="query">
<element name="locationInfo">
<zeroOrMore>
<ref name="anyElement"/>
</zeroOrMore>
</element>
<element name="service">
<data type="anyURI"/>
</element>
<ref name="extensionPoint" />
<optional>
<attribute name="operation">
<a:defaultValue>recursive</a:defaultValue>
</attribute>
</optional>
</define>
</div>
<div>
<a:documentation>
A result.
</a:documentation>
<define name="result">
<a:documentation>
2xx response.
</a:documentation>
<element name="result">
<optional>
<element name="displayName">
<data type="string"/>
<attribute name="xml:lang">
<data type="language" />
</attribute>
</element>
</optional>
<element name="service">
<data type="anyURI"/>
</element>
<optional>
<element name="serviceBoundary">
<choice>
<group>
<ref name="civicLocation" />
<optional>
<ref name="polygon" />
</optional>
</group>
<group>
<optional>
<ref name="civicLocation" />
</optional>
<ref name="polygon" />
</group>
</choice>
</element>
</optional>
<oneOrMore>
<element name="uri">
<data type="anyURI"/>
</element>
</oneOrMore>
<optional>
<element name="serviceNumber">
<data type="string">
<param name="pattern">[0-9]+</param>
</data>
</element>
</optional>
<optional>
<element name="validation">
<list>
<zeroOrMore>
<data type="QName"/>
</zeroOrMore>
</list>
</element>
</optional>
<ref name="extensionPoint" />
<attribute name="timeToLive">
<data type="positiveInteger"/>
</attribute>
<ref name="status" />
</element>
</define>
</div>
<div>
<a:documentation>
Non-result responses.
</a:documentation>
<define name="error">
<a:documentation>
5xx response.
</a:documentation>
<element name="error">
<ref name="status"/>
<ref name="extensionPoint" />
</element>
</define>
<define name="redirect">
<a:documentation>
3xx response.
</a:documentation>
<element name="redirect">
<ref name="status"/>
<attribute name="redirect">
<data type="anyURI"/>
</attribute>
<ref name="extensionPoint" />
</element>
</define>
<define name="failure">
<a:documentation>
4xx response.
</a:documentation>
<element name="failure">
<ref name="status"/>
<zeroOrMore>
<element name="cause">
<attribute name="name">
<data type="QName"/>
</attribute>
<attribute name="message">
<data type="string"/>
</attribute>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</element>
</zeroOrMore>
<ref name="extensionPoint" />
</element>
</define>
</div>
<div>
<a:documentation>
Status pattern.
</a:documentation>
<define name="status">
<attribute name="status">
<data type="positiveInteger"/>
</attribute>
<optional>
<attribute name="extendedStatus">
<data type="positiveInteger"/>
</attribute>
</optional>
<optional>
<group>
<attribute name="message">
<data type="string"/>
</attribute>
<attribute name="xml:lang">
<data type="language"/>
</attribute>
</group>
</optional>
</define>
</div>
<div>
<a:documentation>
Patterns for inclusion of elements from schemas in
other namespaces.
</a:documentation>
<define name="anyElement">
<a:documentation>
A wildcard pattern for including any
element from any other namespace.
</a:documentation>
<element>
<anyName/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="anyElement"/>
</choice>
</zeroOrMore>
</element>
</define>
<define name="extensionPoint">
<a:documentation>
A point where future extensions
(elements from other namespaces)
can be added.
</a:documentation>
<zeroOrMore>
<ref name="anyElement" />
</zeroOrMore>
</define>
<define name="civicAddress">
<a:documentation>
A pattern to include the GEOPRIV civil location elements.
</a:documentation>
<element>
<nsName ns="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="anyElement"/>
</choice>
</zeroOrMore>
</element>
</define>
<define name="civicLocation">
<a:documentation>
A definition of civic location from GEOPRIV.
</a:documentation>
<element name="civicLocation">
<zeroOrMore>
<ref name="civicAddress"/>
</zeroOrMore>
<zeroOrMore>
<ref name="anyElement" />
</zeroOrMore>
</element>
</define>
<define name="GML">
<a:documentation>
A pattern to include GML elements.
</a:documentation>
<element>
<nsName ns="http://www.opengis.net/gml" />
<zeroOrMore>
<choice>
<attribute>
<anyName/>
</attribute>
<text/>
<ref name="anyElement" />
</choice>
</zeroOrMore>
</element>
</define>
<define name="polygon">
<element name="Polygon" ns="http://www.opengis.net/gml">
<zeroOrMore>
<attribute>
<anyName/>
</attribute>
</zeroOrMore>
<ref name="GML"/>
</element>
</define>
</div>
</grammar>
Authors' Addresses Authors' Addresses
Ted Hardie Ted Hardie
Qualcomm, Inc. Qualcomm, Inc.
Email: hardie@qualcomm.com Email: hardie@qualcomm.com
Andrew Newton Andrew Newton
SunRocket SunRocket
8045 Leesburg Pike, Suite 300 8045 Leesburg Pike, Suite 300
skipping to change at page 31, line 5 skipping to change at page 52, line 5
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Phone: +49 89 636 40390 Phone: +49 89 636 40390
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com URI: http://www.tschofenig.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 31, line 29 skipping to change at page 52, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 147 change blocks. 
473 lines changed or deleted 1332 lines changed or added

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