Location Source Parameter for the SIP Geolocation Header Field
RFC 8787

Document Type RFC - Proposed Standard (May 2020; No errata)
Updates RFC 6442
Authors James Winterbottom  , Roland Jesske  , Bruno Chatras  , Andrew Hutton 
Last updated 2020-05-31
Replaces draft-winterbottom-sipcore-locparam
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Jean Mahoney
Shepherd write-up Show (last changed 2019-10-20)
IESG IESG state RFC 8787 (Proposed Standard)
Consensus Boilerplate Yes
Telechat date
Responsible AD Adam Roach
Send notices to Jean Mahoney <mahoney@nostrum.com>
IANA IANA review state IANA OK - Actions Needed


Internet Engineering Task Force (IETF)                   J. Winterbottom
Request for Comments: 8787                   Winterb Consulting Services
Updates: 6442                                                  R. Jesske
Category: Standards Track                               Deutsche Telekom
ISSN: 2070-1721                                               B. Chatras
                                                             Orange Labs
                                                               A. Hutton
                                                                    Atos
                                                                May 2020

     Location Source Parameter for the SIP Geolocation Header Field

Abstract

   There are some circumstances where a Geolocation header field may
   contain more than one locationValue.  Knowing the identity of the
   node adding the locationValue allows the recipient more freedom in
   selecting the value to look at first rather than relying solely on
   the order of the locationValues.  This document defines the "loc-src"
   parameter so that the entity adding the locationValue to the
   Geolocation header field can identify itself using its hostname.
   This document updates RFC 6442.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8787.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  Rationale
   4.  Mechanism
   5.  Example
   6.  Privacy Considerations
   7.  Security Considerations
   8.  IANA Considerations
     8.1.  Registration of "loc-src" Parameter for Geolocation Header
           Field
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgements
   Authors' Addresses

1.  Introduction

   The SIP Geolocation specification [RFC6442] describes the
   "Geolocation" SIP header field, which is used to indicate that the
   SIP message is conveying location information.  [RFC6442] specifies
   that SIP intermediaries should not add locationValues to a SIP
   request that already contains a locationValue.  [RFC6442] also states
   that if a SIP intermediary adds location, it is fully responsible for
   addressing the concerns of any 424 (Bad Location Information) SIP
   response it receives.  However, some communications architectures,
   such as 3GPP [TS23-167] and ETSI [M493], prefer to use information
   provided by edge proxies or acquired through the use of core-network
   nodes before using information provided solely by user equipment
   (UE).  These solutions don't preclude the use of UE-provided location
   but require a means of being able to distinguish the identity of the
   node adding the locationValue to the SIP message from that provided
   by the UE.

   [RFC6442] stipulates that the order of locationValues in the
   Geolocation header field is the same as the order in which they were
   added to the header field.  Whilst this order provides guidance to
   the recipient as to which values were added to the message earlier in
   the communication chain, it does not identify which node added the
   locationValue.  Knowing the identity of the entity that added the
   location to the message allows the recipient to choose which location
   to consider first rather than relying solely on the order of the
   locationValues in the Geolocation header field.

   This document extends the Geolocation header field of [RFC6442] by
   allowing an entity adding the locationValue to identify itself using
   a hostname.  This is done by defining a new geoloc-param header field
   parameter, "loc-src".  How the entity adding the locationValue to the
   header field obtains the location information is out of scope of this
   document.  Please note that the "loc-src" parameter field does not
Show full document text