16. Internationalization Considerations
The LoST protocol is mostly meant for machine-to-machine
communications; 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 and the 'message' attributes may be displayed
to the end user, and they are thus complex types designed for this
LoST exchanges information using XML. All XML processors are
required to understand UTF-8 and UTF-16 encodings, and therefore all
LoST clients and servers MUST understand UTF-8 and UTF-16 encoded
XML. Additionally, LoST servers and clients MUST NOT encode XML with
encodings other than UTF-8 or UTF-16.
17. IANA Considerations
17.1. U-NAPTR Registrations
This document registers the following U-NAPTR application service
Application Service Tag: LoST
Defining Publication: The specification contained within this
This document registers the following U-NAPTR application protocol
o Application Protocol Tag: http
Defining Publication: RFC 2616 
o Application Protocol Tag: https
Defining Publication: RFC 2818 
17.2. Content-Type Registration for 'application/lost+xml'
This specification requests the registration of a new MIME type
according to the procedures of RFC 4288  and guidelines in RFC
MIME media type name: application
MIME subtype name: lost+xml
Mandatory parameters: none
Optional parameters: charset
Indicates the character encoding of enclosed XML.
Encoding considerations: Uses XML, which can employ 8-bit
characters, depending on the character encoding used. See RFC
3023 , Section 3.2.
Security considerations: This content type is designed to carry LoST
Interoperability considerations: None
Published specification: RFC 5222
Applications that use this media type: Emergency and location-based
Magic Number: None
File Extension: .lostxml
Macintosh file type code: 'TEXT'
Personal and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@nsn.com
Intended usage: LIMITED USE
This specification is a work item of the IETF ECRIT working group,
with mailing list address <firstname.lastname@example.org>.
The IESG <email@example.com>
17.3. LoST Relax NG Schema Registration
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
Relax NG Schema: The Relax NG schema to be registered is contained
in Section 15. Its first line is
default namespace = "urn:ietf:params:xml:ns:lost1"
and its last line is
17.4. LoST Namespace Registration
Registrant Contact: IETF ECRIT Working Group, Hannes Tschofenig
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
<h1>Namespace for LoST</h1>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5222.txt">
17.5. LoST Location Profile Registry
This document creates a registry of location profile names for the
LoST protocol. Profile names are XML tokens. This registry will
operate in accordance with RFC 5226 , Standards Action.
Defined in Section 12.2.
Defined in Section 12.3.
18. Security Considerations
There are several threats to the overall system of which service
mapping forms a part. An attacker that can obtain service contact
URIs can use those URIs to attempt to disrupt those services. An
attacker that can prevent the lookup of contact URIs can impair the
reachability of such services. An attacker that can eavesdrop on the
communication requesting this lookup can surmise the existence of an
emergency and possibly its nature, and may be able to use this to
launch a physical attack on the caller.
To avoid an attacker modifying the query or its result, Transport
Layer Security (TLS) MUST be implemented and SHOULD be used. Use is
RECOMMENDED both for clients' queries to servers and for queries
among servers; this latter recommendation is to help avoid LoST cache
poisoning attacks by replacing answers given to caching LoST servers.
The use of server identity checks with TLS, as described in Section
3.1 of , is also RECOMMENDED. Omitting the server identity check
allows an attacker to masquerade as a LoST server, so this approach
should be used only when getting any answer, even from a potentially
malicious LoST server, is preferred over closing the connection (and
thus not getting any answer at all). The host name compared against
the server certificate is the host name in the URI, not the DNS name
used as input to NAPTR resolution.
Note that the security considerations in  recommend comparing the
input of NAPTR resolution to the certificate, not the output (host
name in the URI). This approach was not chosen because in emergency
service use cases, it is likely that deployments will see a large
number of inputs to the U-NAPTR algorithm resolving to a single
server, typically run by a local emergency services authority. In
this case, checking the input to the NAPTR resolution against the
certificates provided by the LoST server would be impractical, as the
list of organizations using it would be large, subject to rapid
change, and unknown to the LoST server operator.
The use of server identity does leave open the possibility of DNS-
based attacks, as the NAPTR records may be altered by an attacker.
The attacks include, for example, interception of DNS packets between
the client and the recursive name server, DNS cache poisoning, and
intentional modifications by the recursive name server; see  for
more comprehensive discussion.
DNS Security (DNSSEC)  can be used to protect against these
threats. While DNSSEC is incompletely deployed, users should be
aware of the risk, particularly when they are requesting NAPTR
records in environments where the local recursive name server, or the
network between the client and the local recursive name server, is
not considered trustworthy.
LoST deployments that are unable to use DNSSEC and unwilling to trust
DNS resolution without DNSSEC cannot use the NATPR-based discovery of
LoST servers as is. When suitable configuration mechanisms are
available, one possibility is to configure the LoST server URIs
(instead of the domain name to be used for NAPTR resolution)
directly. Future specifications for applying LoST in non-emergency
services may also specify additional discovery mechanisms and name
Generally, LoST servers will not need to authenticate or authorize
clients presenting mapping queries. If they do, an authentication 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 is
provided in . The threats and security requirements in non-
emergency service uses of LoST may be considerably different from
those described here. For example, an attacker might seek monetary
benefit by returning service mapping information that directed users
to specific service providers. Before deploying LoST in new
contexts, a thorough analysis of the threats and requirements
specific to that context should be undertaken and decisions made on
the appropriate mitigations.
We would like to the thank the following working group members for
the detailed review of previous LoST document versions:
o Martin Thomson (Review July 2006)
o Jonathan Rosenberg (Review July 2006)
o Leslie Daigle (Review September 2006)
o Shida Schubert (Review November 2006)
o Martin Thomson (Review December 2006)
o Barbara Stark (Review January 2007)
o Patrik Faltstrom (Review January 2007)
o Shida Schubert (Review January 2007 as a designated expert
o Jonathan Rosenberg (Review February 2007)
o Tom Taylor (Review February 2007)
o Theresa Reese (Review February 2007)
o Shida Schubert (Review February 2007)
o James Winterbottom (Review July 2007)
o Karl Heinz Wolf (Review May and June 2007)
We would also like to thank the following working group members for
their input to selected design aspects of the LoST protocol:
o Leslie Daigle and Martin Thomson (DNS-based LoST discovery
o John Schnizlein (authoritive LoST answers)
o Rohan Mahy (display names)
o James Polk (error handling)
o Ron Watro and Richard Barnes (expiry of cached data)
o Stephen Edge, Keith Drage, Tom Taylor, Martin Thomson, and James
Winterbottom (indication of PSAP confidence level)
o Martin Thomson (service boundary references)
o Martin Thomson (service URN in LoST response message)
o Clive D.W. Feather, Martin Thomson (validation functionality)
o Roger Marshall (PSAP preference in LoST response)
o James Winterbottom, Marc Linsner, Keith Drage, Tom Taylor, Martin
Thomson, John Schnizlein, Shida Schubert, Clive D.W. Feather,
Richard Stastny, John Hearty, Roger Marshall, Jean-Francois Mule,
Pierre Desjardins (location profiles)
o Michael Hammer, Patrik Faltstrom, Richard Stastny, Martin Thomson,
Roger Marshall, Tom Taylor, Spencer Dawkins, Keith Drage (list
o Martin Thomson, Michael Hammer (mapping of services)
o Shida Schubert, James Winterbottom, Keith Drage (default service
o Otmar Lendl (LoST aggregation)
o Tom Taylor (terminology)
Klaus Darilion and Marc Linsner provided miscellaneous input to the
design of the protocol. Finally, we would like to thank Brian Rosen,
who participated in almost every discussion thread.
Early implementation efforts led to good feedback by two open source
implementation groups. We would like to thank the implementers for
their work and for helping us to improve the quality of the
o Wonsang Song
o Jong-Yul Kim
o Anna Makarowska
o Krzysztof Rzecki
o Blaszczyk Piotr
We would like to thank Jon Peterson, Dan Romascanu, Lisa Dusseault,
and Tim Polk for their IESG review comments. Blocking IESG comments
were also received from Pasi Eronen (succeeding Sam Hartman's review)
and Cullen Jennings. Adjustments have been made to several pieces of
text to satisfy these requests for changes, most notably in the
Security Considerations and in the discussion of redirection in the
presence of overlapping coverage areas.
20.1. Normative References
 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
 Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
 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.
 Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
 Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
 Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
 Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
 Daigle, L., "Domain-Based Application Service Location Using
URIs and the Dynamic Delegation Discovery Service (DDDS)",
RFC 4848, April 2007.
 Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency
and Other Well-Known Services", RFC 5031, January 2008.
 Thomson, M. and J. Winterbottom, "Revised Civic Location Format
for Presence Information Data Format Location Object
(PIDF-LO)", RFC 5139, February 2008.
 Cox, S., Daisey, P., Lake, R., Portele, C., and A. Whiteside,
"Geographic information - Geography Markup Language (GML)", OGC
Standard OpenGIS 03-105r1, April 2004.
 Reed, C. and M. Thomson, "GML 3.1.1 PIDF-LO Shape Application
Schema for use by the Internet Engineering Task Force (IETF)",
Candidate OpenGIS Implementation Specification , December 2006.
20.2. Informative References
 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
PIDF-LO Usage Clarification, Considerations and
Recommendations", Work in Progress, February 2008.
 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.
 Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC 3921,
 Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
 Taylor, T., Tschofenig, H., Schulzrinne, H., and M. Shanmugam,
"Security Threats and Requirements for Emergency Call Marking
and Mapping", RFC 5069, January 2008.
 Schulzrinne, H. and R. Marshall, "Requirements for Emergency
Context Resolution with Internet Technologies", RFC 5012,
 Schulzrinne, H., "Location-to-URL Mapping Architecture and
Framework", Work in Progress, September 2007.
 Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
"DNS Security Introduction and Requirements", RFC 4033,
 Rosen, B. and J. Polk, "Best Current Practice for
Communications Services in support of Emergency Calling", Work
in Progress, February 2008.
 Daigle, L. and A. Newton, "Domain-Based Application Service
Location Using SRV RRs and the Dynamic Delegation Discovery
Service (DDDS)", RFC 3958, January 2005.
 Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
System (DNS)", RFC 3833, August 2004.
A wildcard pattern for including any element
from any other namespace.
A point where future extensions
(elements from other namespaces)
can be added.
Figure 21Appendix B. Examples Online
The XML examples and Relax NG schemas may be found online .
American Registry for Internet Numbers
3635 Concorde Parkway, Suite 200
Chantilly, VA 20151
Phone: +1 703 227 9894
Department of Computer Science
450 Computer Science Building
New York, NY 10027
Phone: +1 212 939 7004
Nokia Siemens Networks
Phone: +358 (50) 4871445
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at