| Internet-Draft | retransmission-allowed errata | July 2025 |
| Rosen & Martin | Expires 24 January 2026 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 24 January 2026.¶
Copyright (c) 2025 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
[RFC4119] 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'.¶
There are six RFCs with text or examples that incorrectly use values 'yes' and 'no' for <retransmission-allowed>: [RFC4119], [RFC5606], [RFC5774], [RFC6442], [RFC7378] and [RFC8262]. This document updates these RFCs to replace all use of 'yes' with 'true', and all use of 'no' with 'false'.¶
[RFC4119] 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>¶
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". ...¶
[RFC5774] Section A.5 "Example" shows:¶
<gp:retransmission-allowed>yes</gp:retransmission-allowed>¶
It should show:¶
<gp:retransmission-allowed>true</gp:retransmission-allowed>¶
[RFC6442] section 4.4 page 18 says:¶
This location error is specific to having the PIDF-LO [RFC4119] <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 [RFC4119] <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 "true", it MUST choose another logical path (if one exists) for this SIP request.¶
Errata id 4236 incorrectly says¶
Section 5.1, 5.2 says:¶
<gbp:retransmission-allowed>false
</gbp:retransmission-allowed>¶
It should say:¶
<gbp:retransmission-allowed>no
</gbp:retransmission-allowed>¶
The above errata id 4236 is not correct. Sections 5.1 and 5.2 are correct without any need for this errata id 4236.¶
[RFC7378] 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.¶
The changes in this document does not require additional security considerations beyond those already noted in the individual RFCs affected by this RFC.¶
None¶