RFC 6444: Location Hiding: Problem Statement and Requirements
In plain English — editorial summary, not part of the RFC
The emergency services architecture developed in the IETF Emergency Context Resolution with Internet Technology (ECRIT) working group describes an architecture where location information is provided by access networks to endpoints or Voice over IP (VoIP) service providers in order to determine the correct dial string and information to route the call to a Public Safety Answering Point (PSAP). To determine the PSAP Uniform Resource Identifier (URI), the usage of the Location-to-Service Translation (LoST) protocol is envisioned. This document provides a problem statement and lists requirements for situations where the Internet Access Provider (IAP) and/or the Internet Service Provider (ISP) are only willing to disclose limited or no location information. This document is not an Internet Standards Track specification; it is published for informational purposes.
Document record
- Document ID
- RFC6444
- Published
- January 2012
- Authors
- H. Schulzrinne; L. Liess; H. Tschofenig; B. Stark; A. Kuett
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- art
- Pages
- 9
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 7844Anonymity Profiles for DHCP ClientsCurrent
May 2016
- RFC 6881Best Current Practice for Communications Services in Support of Emergency CallingUpdated
March 2013
- RFC 7090Public Safety Answering Point (PSAP) CallbackCurrent
April 2014
- RFC 7293The Require-Recipient-Valid-Since Header Field and SMTP Service ExtensionCurrent
July 2014
- RFC 8147Next-Generation Pan-European eCallCurrent
May 2017
- RFC 8148Next-Generation Vehicle-Initiated Emergency CallsCurrent
May 2017
- RFC 6235IP Flow Anonymization SupportCurrent
May 2011
- RFC 6071IP Security (IPsec) and Internet Key Exchange (IKE) Document RoadmapCurrent
February 2011
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?