A Comprehensive Errata for 'retransmission-allowed' XML Element

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 "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.

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>