draft-ietf-sipcore-locparam-01.txt   draft-ietf-sipcore-locparam-02.txt 
SIPCORE J. Winterbottom SIPCORE J. Winterbottom
Internet-Draft Winterb Consulting Services Internet-Draft Winterb Consulting Services
Updates: RFC6442 (if approved) R. Jesske Updates: RFC6442 (if approved) R. Jesske
Intended status: Standards Track Deutsche Telekom Intended status: Standards Track Deutsche Telekom
Expires: July 6, 2019 B. Chatras Expires: January 23, 2020 B. Chatras
Orange Labs Orange Labs
A. Hutton A. Hutton
Unify Atos
January 2, 2019 July 22, 2019
Location Source Parameter for the SIP Geolocation Header Field Location Source Parameter for the SIP Geolocation Header Field
draft-ietf-sipcore-locparam-01.txt draft-ietf-sipcore-locparam-02.txt
Abstract Abstract
There are some circumstances where a geolocation header field may There are some circumstances where a geolocation header field may
contain more than one location value. Knowing the identity of the contain more than one location value. Knowing the identity of the
node adding the location value allows the recipient more freedom in node adding the location value allows the recipient more freedom in
selecting the value to look at first rather than relying solely on selecting the value to look at first rather than relying solely on
the order of the location values. the order of the location values.
Status of This Memo Status of This Memo
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on July 6, 2019. This Internet-Draft will expire on January 23, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 6, line 18 skipping to change at page 6, line 18
insert a host name indicating the that they added the specific insert a host name indicating the that they added the specific
location value to the geolocation header field. The intent is for location value to the geolocation header field. The intent is for
this field to be used by the location recipient in the event that the this field to be used by the location recipient in the event that the
SIP message contains multiple location values. As a consequence this SIP message contains multiple location values. As a consequence this
parameter should only be used by the location recipient in a trusted parameter should only be used by the location recipient in a trusted
network. network.
As already stated in [RFC6442] securing the location hop- by-hop, As already stated in [RFC6442] securing the location hop- by-hop,
using TLS, protects the message from eavesdropping and modification using TLS, protects the message from eavesdropping and modification
in transit, but exposes the information to all proxies on the path as in transit, but exposes the information to all proxies on the path as
well as the endpoint. The service provider has to take care is well as the endpoint. The loc-src parameter is applicable within a
scenarios when location information is leaving it's own network that single private administrative domain or between different
the receiving network is trustworthy to handle the information administrative domains where there is a trust relationship between
properly. If such trustworthines is not given it is strongly the domains. If such trust domain is not given it is strongly
recommended to delete the location information. recommended to delete the location information.
The use of this parameter is not restricted to a specific The use of this parameter is not restricted to a specific
architecture but using multiples locations and loc-src may end in architecture but using multiples locations and loc-src may end in
compatibility issues. [RFC6442] already addresses the issue of compatibility issues. [RFC6442] already addresses the issue of
multiples locations. To avoid problems of wrong interpretation of multiples locations. To avoid problems of wrong interpretation of
loc-src the value may be discarded when passed to an other domain. loc-src the value may be discarded when passed to an other domain.
8. IANA Considerations 8. IANA Considerations
skipping to change at page 8, line 39 skipping to change at page 8, line 39
Bruno Chatras Bruno Chatras
Orange Labs Orange Labs
38-40 rue du General Leclerc 38-40 rue du General Leclerc
Issy Moulineaux Cedex 9 F-92794 Issy Moulineaux Cedex 9 F-92794
France France
Email: bruno.chatras@orange.com Email: bruno.chatras@orange.com
Andrew Hutton Andrew Hutton
Unify Atos
Technology Drive Mid City Place
Nottingham NG9 1LA London WC1V 6EA
UK UK
Email: andrew.hutton@unify.com Email: andrew.hutton@atos.net
 End of changes. 7 change blocks. 
12 lines changed or deleted 12 lines changed or added

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