]> Unaffiliated

Mars PA United States of America br@brianrosen.net

Comtech TCS

2401 Elliott Avenue Seattle WA 98121 United States of America jeff.martin@comtech.com

ART sipcore This document fixes use of the 'retransmission-allowed' element of PIDF-LO in six published RFCs. All text and examples should show 'true' or 'false' to match the XML schema definitions, but some RFCs incorrectly use 'yes' or 'no'. This document updates RFC4119, RFC5606, RFC5774, RFC6442, RFC7378, RFC8262.

Introduction defines the <retransmission-allowed> element as part of PIDF-LO. Section 2.2.5 "Schema Definitions" defines this element as a boolean data type as described in W3C's "XML Schema Part 2: Datatypes (Second Edition)". As a boolean data type, <retransmission-allowed> can have the following values: 'true', 'false', '0', or '1'. Unfortunately the examples in the text of RFC 4119 used values 'yes' and 'no', which are not allowed per section 2.2.5 "Schema Definitions". This problem was reported in errata id 1535 in 2008, and verified in 2010. Since RFC 4119, there are another 13 RFCs with <retransmission-allowed> example text. Despite the RFC 4119 errata, 5 of these RFCs incorrectly repeated the mistaken use of 'yes' and 'no' in their examples of <retransmission-allowed>: , , , , and . The other 8 RFCs correctly use 'true' and 'false' in their examples: , , , , , , , and . Rather than submitting individual errata against the incorrect examples in those 5 RFCs, this document updates them all to replace all use of 'yes' with 'true', and all use of 'no' with 'false'. The original RFC 4119 is also included here for completeness, to further reinforce the existing errata id 1535 for RFC 4119.

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Additional Copyright Notice This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Changes to Documents

RFC 4119 - A Presence-based GEOPRIV Location Object Format (PIDF-LO) section 2.2.2 page 8 says:

• 'retransmission-allowed': When the value of this element is 'no', the Recipient of this Location Object is not permitted to share the enclosed Location Information, or the object as a whole, with other parties. When the value of this element is 'yes', distributing this Location is permitted (barring an existing out-of-band agreement or obligation to the contrary). By default, the value MUST be assumed to be 'no'. Implementations MUST include this field, with a value of 'no', if the Rule Maker specifies no preference.

It should say:

• 'retransmission-allowed': When the value of this element is 'false', the Recipient of this Location Object is not permitted to share the enclosed Location Information, or the object as a whole, with other parties. When the value of this element is 'true', distributing this Location is permitted (barring an existing out-of-band agreement or obligation to the contrary). By default, the value MUST be assumed to be 'false'. Implementations MUST include this field, with a value of 'false', if the Rule Maker specifies no preference.

Section 2.3 "Example Location Objects" shows the following in two places:

• <gp:retransmission-allowed>no</gp:retransmission-allowed>

Both places should show:

• <gp:retransmission-allowed>false</gp:retransmission-allowed>

RFC 5606 - Implications of 'retransmission-allowed' for SIP Location Conveyance Section 2 says:

• These questions and concerns are particularly problematic when <retransmission-allowed> is set to "no" (the default case). This core concern might be put as "to whom does <retransmission-allowed> apply in location-based routing?" More specifically: Is any entity that reads LI bound by <retransmission-allowed>? If so, does that mean a proxy that performs location-based routing is unable to forward a request and complete a SIP call if \retransmission-allowed> is "no"? Alternatively, must they strip the location body from the message in order to complete the call? If the proxy does not understand RFC 4119, it may forward a SIP message containing a policy statement <retransmission-allowed> set to "no". Is any proxy that does understand RFC 4119 required to parse the LI for this statement, even if it would not do so in order to route the message?

It should say:

• These questions and concerns are particularly problematic when <retransmission-allowed> is set to "false" (the default case). This core concern might be put as "to whom does <retransmission-allowed> apply in location-based routing?" More specifically: Is any entity that reads LI bound by <retransmission-allowed>? If so, does that mean a proxy that performs location-based routing is unable to forward a request and complete a SIP call if \retransmission-allowed> is "false"? Alternatively, must they strip the location body from the message in order to complete the call? If the proxy does not understand RFC 4119, it may forward a SIP message containing a policy statement <retransmission-allowed> set to "false". Is any proxy that does understand RFC 4119 required to parse the LI for this statement, even if it would not do so in order to route the message?

Section 3.1 says:

• After extensive discussion in both GEOPRIV and SIP contexts, there seems to be consensus that a solution for this problem must enable location-based routing to work even when the <retransmission-allowed> flag is set to "no". A solution should also give the Rule Maker the ability to allow or forbid the use of LI for location-based routing and the ability to allow or forbid the use of LI for the consumption of the endpoint.

It should say:

• After extensive discussion in both GEOPRIV and SIP contexts, there seems to be consensus that a solution for this problem must enable location-based routing to work even when the <retransmission-allowed> flag is set to "false". A solution should also give the Rule Maker the ability to allow or forbid the use of LI for location-based routing and the ability to allow or forbid the use of LI for the consumption of the endpoint.

Section 3.2 says:

• Consensus has emerged that any SIP entity that receives a SIP message containing LI through the operation of SIP's normal routing procedures or as a result of location-based routing should be considered an authorized recipient of that LI. Because of this presumption, one SIP element may pass the LI to another even if the LO it contains has <retransmission-allowed> set to "no"; this sees the passing of the SIP message as part of the delivery to authorized recipients, rather than as retransmission. SIP entities are still enjoined from passing these messages outside the normal routing to external entities if <retransmission-allowed> is set to "no", as it is the passing to third parties that <retransmission-allowed> is meant to control.

It should say:

• Consensus has emerged that any SIP entity that receives a SIP message containing LI through the operation of SIP's normal routing procedures or as a result of location-based routing should be considered an authorized recipient of that LI. Because of this presumption, one SIP element may pass the LI to another even if the LO it contains has <retransmission-allowed> set to "false"; this sees the passing of the SIP message as part of the delivery to authorized recipients, rather than as retransmission. SIP entities are still enjoined from passing these messages outside the normal routing to external entities if <retransmission-allowed> is set to "false", as it is the passing to third parties that <retransmission-allowed> is meant to control.

Section 3.5 says:

• ... like the PIDF-LO <retransmission-allowed> being set to "no", it is a ...

It should say:

• ... like the PIDF-LO <retransmission-allowed> being set to "false", it is a ...

Section 3.6 says:

• ... it must not copy location if <retransmission-allowed> is "no". ...

It should say:

• ... it must not copy location if <retransmission-allowed> is "false". ...

RFC 5774 - Considerations for Civic Addresses in PIDF-LO: Guidelines and IANA Registry Definition Section A.5 "Example" shows:

• <gp:retransmission-allowed>yes</gp:retransmission-allowed>

It should show:

• <gp:retransmission-allowed>true</gp:retransmission-allowed>

RFC 6442 - Location Conveyance for SIP section 4.4 page 18 says:

• This location error is specific to having the PIDF-LO <retransmission-allowed> element set to "no". This location error is stating it requires permission (i.e., PIDF-LO <retransmission-allowed> element set to "yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not change this permission in a new request. If the LS wants this message processed with the <retransmission-allowed> element set to "yes", it MUST choose another logical path (if one exists) for this SIP request.

It should say:

• This location error is specific to having the PIDF-LO <retransmission-allowed> element set to "false". This location error is stating it requires permission (i.e., PIDF-LO <retransmission-allowed> element set to "true") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not change this permission in a new request. If the LS wants this message processed with the <retransmission-allowed> element set to "false", it MUST choose another logical path (if one exists) for this SIP request.

Errata id 4236 incorrectly includes the following text

• Section 5.1, 5.2 says:
  • <gbp:retransmission-allowed>false
    </gbp:retransmission-allowed>
  It should say:
  • <gbp:retransmission-allowed>no
    </gbp:retransmission-allowed>

Sections 5.1 and 5.2 of RFC6442 are correct without any need for this errata id 4236. This errata should be ignored.

RFC 7378 - Trustworthy Location section 6 page 25 says:

• as noted in RFC5606, Section 3.2:
  • ... Because of this presumption, one SIP element may pass the LI to another even if the LO it contains has <retransmission-allowed> set to "no"; this sees the passing of the SIP message as part of the delivery to authorized recipients, rather than as retransmission. SIP entities are still enjoined from passing these messages outside the normal routing to external entities if <retransmission-allowed> is set to "no", as it is the passing to third parties that <retransmission-allowed> is meant to control.

It should say:

• as noted in RFC5606, Section 3.2:
  • ... Because of this presumption, one SIP element may pass the LI to another even if the LO it contains has <retransmission-allowed> set to "false"; this sees the passing of the SIP message as part of the delivery to authorized recipients, rather than as retransmission. SIP entities are still enjoined from passing these messages outside the normal routing to external entities if <retransmission-allowed> is set to "false", as it is the passing to third parties that <retransmission-allowed> is meant to control.

RFC 8262 - Content-ID Header Field in SIP section 1.4.1 "Example 1" shows:

• <gbp:retransmission-allowed>no
  </gbp:retransmission-allowed>

It should show:

• <gbp:retransmission-allowed>false
  </gbp:retransmission-allowed>

Security Considerations The changes in this document does not require additional security considerations beyond those already noted in the individual RFCs affected by this RFC.

IANA Considerations None

References Normative References This document describes an object format for carrying geographical information on the Internet. This location object extends the Presence Information Data Format (PIDF), which was designed for communicating privacy-sensitive presence information and which has similar properties. [STANDARDS-TRACK] This document explores an ambiguity in the interpretation of the element of the Presence Information Data Format for Location Objects (PIDF-LO) in cases where PIDF-LO is conveyed by the Session Initiation Protocol (SIP). It provides recommendations for how the SIP location conveyance mechanism should adapt to this ambiguity. Documents standardizing the SIP location conveyance mechanisms will be Standards-Track documents processed according to the usual SIP process. This document is intended primarily to provide the SIP working group with a statement of the consensus of the GEOPRIV working group on this topic. It secondarily provides tutorial information on the problem space for the general reader. This memo provides information for the Internet community. This document provides a guideline for creating civic address considerations documents for individual countries, as required by RFC 4776. Furthermore, this document also creates an IANA Registry referring to such address considerations documents and registers such address considerations for Austria. This memo documents an Internet Best Current Practice. This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. [STANDARDS-TRACK] The trustworthiness of location information is critically important for some location-based applications, such as emergency calling or roadside assistance. This document describes threats to conveying location, particularly for emergency calls, and describes techniques that improve the reliability and security of location information. It also provides guidelines for assessing the trustworthiness of location information. This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). This document also updates RFC 5621, which only allows a Content-ID URL to reference a body part that is part of a multipart message-body. This update enables a Content-ID URL to reference a complete message-body and metadata provided by some additional SIP header fields. This document updates RFC 5368 and RFC 6442 by clarifying their usage of the SIP Content-ID header field. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter. The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK] This document defines a Layer 7 Location Configuration Protocol (L7 LCP) and describes the use of HTTP and HTTP/TLS as transports for the L7 LCP. The L7 LCP is used for retrieving location information from a server within an access network. It includes options for retrieving location information in two forms: by value and by reference. The protocol is an extensible application-layer protocol that is independent of the session layer. [STANDARDS-TRACK] This document updates the Multi-threaded Routing Toolkit (MRT) export format for Border Gateway Protocol (BGP) routing information by extending it to include optional terrestrial coordinates of a BGP collector and its BGP peers. [STANDARDS-TRACK] This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target. [STANDARDS-TRACK] This document defines an authorization policy language for controlling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information in order to restrict access to data based on the current location of the Target. Furthermore, this document defines two algorithms for reducing the granularity of returned location information. The first algorithm is defined for usage with civic location information, whereas the other one applies to geodetic location information. Both algorithms come with limitations. There are circumstances where the amount of location obfuscation provided is less than what is desired. These algorithms might not be appropriate for all application domains. [STANDARDS-TRACK] Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI so that the host can view or set these rules. When an emergency call is sent to a Public Safety Answering Point (PSAP), the originating device, the access network provider to which the device is connected, and all service providers in the path of the call have information about the call, the caller, or the location, which is helpful for the PSAP to have in handling the emergency. This document describes data structures and mechanisms to convey such data to the PSAP. The intent is that every emergency call carry as much of the information described here as possible using the mechanisms described here. The mechanisms permit the data to be conveyed by reference (as an external resource) or by value (within the body of a SIP message or a location object). This follows the tradition of prior emergency services standardization work where data can be conveyed by value within the call signaling (i.e., in the body of the SIP message) or by reference. Use of the Internet for emergency calling is described in RFC 6443, 'Framework for Emergency Calling Using Internet Multimedia'. In some cases of emergency calls, the transmission of application data is all that is needed, and no interactive media channel is established: a situation referred to as 'non-interactive emergency calls', where, unlike most emergency calls, there is no two-way interactive media such as voice or video or text. This document describes use of a SIP MESSAGE transaction that includes a container for the data based on the Common Alerting Protocol (CAP). That type of emergency request does not establish a session, distinguishing it from SIP INVITE, which does. Any device that needs to initiate a request for emergency services without an interactive media channel would use the mechanisms in this document.

Contributors Comtech TCS

2401 Elliott Avenue Seattle WA 98121 United States of America skip.hines@comtech.com

Comtech TCS

2401 Elliott Avenue Seattle WA 98121 United States of America roger.marshall@comtech.com

Comtech TCS

2401 Elliott Avenue Seattle WA 98121 United States of America victor.burton@comtech.com