Network Working Group J. Peterson
Request for Comments: 5606 NeuStar, Inc.
Category: Informational T. Hardie
Qualcomm
J. Morris
CDT
August 2009
Network Working Group J. Peterson
Request for Comments: 5606 NeuStar, Inc.
Category: Informational T. Hardie
Qualcomm
J. Morris
CDT
August 2009
Implications of 'retransmission-allowed' for SIP Location Conveyance
“允许重传”对SIP位置传输的影响
Abstract
摘要
This document explores an ambiguity in the interpretation of the <retransmission-allowed> 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.
本文档探讨了在会话发起协议（SIP）传输PIDF-LO的情况下，位置对象的存在信息数据格式（PIDF-LO）的<retransmission allowed>元素的解释中存在的歧义。它为SIP位置传输机制如何适应这种模糊性提供了建议。
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.
标准化SIP位置传输机制的文件将是根据常规SIP流程处理的标准跟踪文件。本文件的主要目的是向SIP工作组提供GEOPRIV工作组就该主题达成共识的声明。第二，它为一般读者提供关于问题空间的教程信息。
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人可能没有授予IETF信托允许的权利
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.
在IETF标准过程之外修改此类材料。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Problem Statement ...............................................3
3. Recommendation ..................................................5
3.1. Goals ......................................................5
3.2. Core Semantics .............................................5
3.3. Limiting Access ............................................6
3.3.1. Limiting Access Using Public Key Encryption .........6
3.3.2. Limiting Access Using Location-by-Reference .........7
3.3.3. Refraining from Including Location Information ......8
3.4. Choosing among the Available Mechanisms ....................8
3.5. Indicating Permission to Use Location-Based Routing
in SIP .....................................................8
3.6. Behavior of Back-to-Back User Agents ......................10
4. Security Considerations ........................................10
5. Acknowledgements ...............................................10
6. Informative References .........................................11
1. Introduction ....................................................2
2. Problem Statement ...............................................3
3. Recommendation ..................................................5
3.1. Goals ......................................................5
3.2. Core Semantics .............................................5
3.3. Limiting Access ............................................6
3.3.1. Limiting Access Using Public Key Encryption .........6
3.3.2. Limiting Access Using Location-by-Reference .........7
3.3.3. Refraining from Including Location Information ......8
3.4. Choosing among the Available Mechanisms ....................8
3.5. Indicating Permission to Use Location-Based Routing
in SIP .....................................................8
3.6. Behavior of Back-to-Back User Agents ......................10
4. Security Considerations ........................................10
5. Acknowledgements ...............................................10
6. Informative References .........................................11
The Presence Information Data Format for Location Objects (PIDF-LO [RFC4119]) carries both location information (LI) and policy information set by the Rule Maker, as is stipulated in [RFC3693]. The policy carried along with LI allows the Rule Maker to restrict, among other things, the duration for which LI will be retained by recipients and the redistribution of LI by recipients.
位置对象的状态信息数据格式（PIDF-LO[RFC4119]）包含规则制定者设置的位置信息（LI）和策略信息，如[RFC3693]所规定。与LI一起实施的政策允许规则制定者除其他事项外，限制收件人保留LI的期限以及收件人对LI的重新分配。
The Session Initiation Protocol [RFC3261] is one proposed Using Protocol for PIDF-LO. The conveyance of PIDF-LO within SIP is specified in [LOC-CONVEY]. The common motivation for providing LI in SIP is to allow location to be considered in routing the SIP message. One example use case would be emergency services, in which the location will be used by dispatchers to direct the response. Another use case might be providing location to be used by services associated with the SIP session; a location associated with a call to a taxi service, for example, might be used to route to a local franchisee of a national service and also to route the taxi to pick up the caller.
会话启动协议[RFC3261]是使用PIDF-LO协议提出的协议。SIP内PIDF-LO的传输在[LOC-TRANSFER]中有规定。在SIP中提供LI的常见动机是允许在路由SIP消息时考虑位置。一个示例用例是紧急服务，调度员将使用该位置来指示响应。另一个用例可能是提供与SIP会话相关联的服务使用的位置；例如，与呼叫出租车服务相关联的位置可用于路由到当地国家服务特许经营商，也可用于路由出租车以接来电者。
Some ambiguities have arisen in the interpretation of Rule Maker policy when PIDF-LO is conveyed by SIP. The following sections explore the problem and provide a recommendation.
当SIP传达PIDF-LO时，规则制定者政策的解释出现了一些歧义。以下各节将探讨该问题并提供建议。
The <retransmission-allowed> element of RFC 4119 was designed for use in an environment like that of Section 4 of RFC 3693, in which Location Information (LI) propagates from a Location Generator through a Location Server (LS) to a Location Recipient (LR). In this architecture, it is the responsibility of the Location Server to act on the rules (policy) governing access control to LI, which are in turn set by the Rule Maker. The most important of these responsibilities is delivering LI to authorized Location Recipients and denying it to others. Internal to [RFC4119]-compliant location objects (LOs) are additional privacy rules which are intended to constrain Location Recipients. These include the <retransmission-allowed> element. This element is intended to prevent a compromise of privacy when an authorized recipient of LI shares that LI with third-party entities, principally those who are not authorized by the Rule Maker to receive LI. For example, a user might be willing to share their LI with a pizza shop, but they might not want that pizza shop to sell their LI to a targeted advertising company that will contact the user with coupons for a nearby hair salon.
RFC 4119的<retransmission allowed>元素设计用于类似RFC 3693第4节的环境，其中位置信息（LI）从位置生成器通过位置服务器（LS）传播到位置接收者（LR）。在此体系结构中，位置服务器负责按照规则制定者设置的规则（策略）对LI进行访问控制。这些责任中最重要的是将LI交付给授权地点接收者，并拒绝将其提供给其他人。[RFC4119]兼容位置对象（LO）的内部是附加的隐私规则，用于约束位置接收者。其中包括<retransmission allowed>元素。此要素旨在防止当LI的授权接收人与第三方实体（主要是未经规则制定者授权接收LI的实体）共享LI时，隐私受到损害。例如，用户可能愿意与比萨店分享他们的LI，但他们可能不希望比萨店将他们的LI出售给目标广告公司，该公司将向用户提供附近发廊的优惠券。
Bear in mind, however, that <retransmission-allowed> is not intended to provide any protocol-level mechanism to prevent unauthorized parties from learning location through means like eavesdropping. It is merely a way to express the preferences of the Rule Maker to the LR. If the LR were, for example, legally bound to follow the privacy preferences expressed by Rule Makers, then they might incur liability if they ignored the <retransmission-allowed> parameter. No further privacy protection is assumed to be provided by <retransmission-allowed>.
但是，请记住，<retransmission allowed>并不是为了提供任何协议级机制，以防止未经授权的方通过窃听等方式学习位置。这只是表达规则制定者对LR偏好的一种方式。例如，如果LR在法律上有义务遵循规则制定者表达的隐私偏好，那么如果他们忽略<retransmission allowed>参数，他们可能会承担责任。<retransmission allowed>假定不提供进一步的隐私保护。
There is a use case for LI that involves embedding it in a SIP request that will potentially traverse multiple SIP intermediaries before arriving at a user agent server (UAS). In this use case, one or more intermediaries might inspect the LI in order to make a SIP routing decision; we will hereafter refer to this as location-based routing. Common examples could include emergency services and other more mundane cases where the originator of a SIP request wants to reach a service in proximity to a particular geographic location, such as contacting a nearby pizza shop. In both such cases, the UAC may intend for selected intermediaries and the UAS to have access to the LI. In the pizza case, for instance, the user agent client (UAC)
LI的一个用例涉及将其嵌入SIP请求中，该请求在到达用户代理服务器（UAS）之前可能会遍历多个SIP中介。在这个用例中，一个或多个中介可以检查LI以做出SIP路由决定；我们将在下文中称之为基于位置的路由。常见的例子可能包括紧急服务和其他更普通的情况，其中SIP请求的发起人希望到达靠近特定地理位置的服务，例如联系附近的比萨饼店。在这两种情况下，UAC可能希望选定的中介机构和UAS能够访问LI。例如，在pizza案例中，用户代理客户端（UAC）
shares an address both for location-based routing and additionally so that the pizza shop reached by that routing has the address to which a pizza should be sent.
共享一个地址，用于基于位置的路由，另外，通过该路由到达的比萨饼店具有比萨饼应发送到的地址。
This location-based routing use case for LI has a number of important disconnects from the RFC 3693 model. Unlike the RFC 3693 model, there is no LS designating to which specific entities LI will be sent. There may be multiple intermediaries between the UAC and UAS, some of which will need or want to inspect LI (which would seem to qualify them as LRs) and some of them will not. While SIP proxy servers generally are not [RFC4119]-aware and do not need to inspect SIP request bodies in order to perform their function, nothing precludes proxy servers inspecting or logging any SIP message bodies, including LI. Furthermore, it is very difficult for the UAC to anticipate which intermediaries and which eventual UAS a SIP request might reach.
LI基于位置的路由用例与RFC3693模型有许多重要的断开。与RFC 3693模型不同，没有指定LI将发送到哪些特定实体的LS。UAC和UAS之间可能有多个中介机构，其中一些中介机构需要或想要检查LI（这似乎使他们有资格成为LRs），而另一些中介机构则不会。虽然SIP代理服务器通常没有[RFC4119]意识，并且不需要检查SIP请求主体以执行其功能，但没有任何东西阻止代理服务器检查或记录任何SIP消息主体，包括LI。此外，UAC很难预测SIP请求可能到达哪些中介机构以及最终到达哪些UAS。
This architecture is further complicated by the possibility of sending location information by-reference, that is, placing a URL where LI can be retrieved in SIP requests instead of using a PIDF-LO body (commonly called including the PIDF-LO by value). Depending on the qualities of a reference, further authorization checks may be performed before LI is retrieved, LI may be customized depending on who is asking, and so forth. As will be discussed in greater detail below, the conveyance of a reference may have very different privacy properties than conveying a PIDF-LO body by-value in a SIP request.
通过引用发送位置信息的可能性使该架构更加复杂，也就是说，将URL放置在SIP请求中可以检索LI的位置，而不是使用PIDF-LO主体（通常称为包含PIDF-LO值）。根据引用的质量，可以在检索LI之前执行进一步的授权检查，可以根据询问者定制LI，等等。如下文将更详细地讨论的，参考的传送可能具有与在SIP请求中按值传送PIDF-LO主体非常不同的隐私属性。
In this architecture, the question of who is an "authorized recipient" from the point of view of the Rule Maker has been muddy.
在这种体系结构中，从规则制定者的角度来看，谁是“授权接收者”的问题一直很模糊。
The SIP elements along the path are authorized to receive and forward the SIP message; does that make them automatically authorized recipients of the LI it contains? The final target of the SIP message will receive the LI along with other information, but it may be different than the initial target in a variety of scenarios; is it authorized to read the LI?
沿着路径的SIP元素被授权接收和转发SIP消息；这是否会使他们自动授权接收它包含的LI？SIP消息的最终目标将接收LI以及其他信息，但在各种场景中它可能不同于初始目标；它有权阅读李吗？
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:
当<retransmission allowed>设置为“no”（默认情况）时，这些问题和关注点尤其有问题。这一核心问题可能被称为“在基于位置的路由中，<允许重传>适用于谁？”更具体地说：
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?
读取LI的任何实体是否受<允许重传>约束？如果是，这是否意味着执行基于位置的路由的代理无法转发请求并在<允许重传>为“否”时完成SIP呼叫？或者，他们必须从消息中删除位置正文才能完成呼叫？
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?
如果代理不理解RFC 4119，则它可以转发包含策略语句<retransmission allowed>设置为“no”的SIP消息。是否需要任何理解RFC 4119的代理来解析此语句的LI，即使它不会这样做以路由消息？
Is there a need for SIP-level indications regarding retransmission for the benefit of entities that do not understand RFC 4119?
为了不了解RFC 4119的实体的利益，是否需要关于重传的SIP级指示？
Since the UAC cannot anticipate who may receive a SIP request, how do we understand who the intended LR is in the location-based routing case? Can a UAC have intended for there to be multiple serial LRs in a transmission? If so, if one LR is authorized to retransmit to another LR, how will it know it is not also authorized to transmit LI to other third parties (i.e., how will the serial LRs know to whom they are authorized to retransmit)? How could all of this be designated?
由于UAC无法预测谁会收到SIP请求，我们如何理解在基于位置的路由情况下预期的LR是谁？UAC是否打算在一个传输中存在多个串行LR？如果是这样，如果一个LR被授权向另一个LR重新传输，它如何知道它没有被授权向其他第三方传输LI（即，串行LR如何知道他们被授权向谁重新传输）？这一切怎么可能被指定？
The following sections provide a recommendation for how the <retransmission-allowed> flag should be understood in a SIP environment. The core semantics of this recommendation represent the consensus of the GEOPRIV working group. While Section 3.5 proposes a syntax that might be adopted by the SIP WG to implement these semantics in its protocol, the actual syntax of SIP is the responsibility of the SIP WG.
以下各节提供了在SIP环境中应如何理解<retransmission allowed>标志的建议。本建议的核心语义代表了GEOPRIV工作组的共识。虽然第3.5节提出了SIP工作组可能采用的语法，以在其协议中实现这些语义，但SIP工作组负责SIP的实际语法。
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.
在GEOPRIV和SIP上下文中进行了广泛讨论之后，似乎达成了共识，即即使<retransmission allowed>标志设置为“no”，该问题的解决方案也必须使基于位置的路由能够工作。解决方案还应使规则制定者能够允许或禁止在基于位置的路由中使用LI，以及允许或禁止在使用端点时使用LI。
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
已经达成共识，通过SIP的正常路由程序的操作或由于基于位置的路由而接收包含LI的SIP消息的任何SIP实体都应被视为该LI的授权接收者。由于这一假设，一个SIP元素可以将LI传递给另一个，即使它包含的LO已<retransmission allowed>设置为“no”；这将SIP消息的传递视为传递给授权收件人的一部分，而不是重传。SIP实体仍然是
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.
如果<retransmission allowed>设置为“no”，则禁止在正常路由之外将这些消息传递给外部实体，因为<retransmission allowed>的目的是控制传递给第三方。
This architecture is considerably different from the presumptions of RFC 3963, in that authorized recipients pass the LO on to other authorized recipients, but it seems to be the most sensible mechanism given SIP's operation.
该体系结构与RFC 3963的假设有很大不同，授权接收者将LO传递给其他授权接收者，但鉴于SIP的操作，它似乎是最合理的机制。
To maintain the Rule Maker's ability to affect the consumption of this information, two different mechanisms may be used to limit the distribution of LI and one may used to limit the sphere in which it may be used; these are discussed below.
为了保持规则制定者影响信息消耗的能力，可以使用两种不同的机制来限制LI的分布，一种机制用于限制LI的使用范围；下文将讨论这些问题。
One way of limiting access to LI is to encrypt the PIDF-LO object in a SIP request. If the originator knows which specific entity on the path needs to inspect the LI, and knows a public key for that entity, this is a straightforward matter. It is even possible to encrypt multiple instance of PIDF-LO, containing different policies or levels of location granularity, in the same SIP request if multiple entities along the path need to inspect the location.
限制对LI访问的一种方法是在SIP请求中加密PIDF-LO对象。如果发起人知道路径上的哪个特定实体需要检查LI，并且知道该实体的公钥，那么这是一个简单的问题。如果路径上的多个实体需要检查位置，甚至可以在同一SIP请求中加密包含不同策略或位置粒度级别的多个PIDF-LO实例。
This is most likely to be effective in cases where the originator does not wish the LI to be inspected by intermediate entities and has the public key for the target of the SIP message, as it is very difficult for the originator to anticipate the intermediaries through which a SIP message will pass. It may also be useful in limited environments where the originator has a trust relationship with a specific SIP element (e.g., a "home" or first-hop proxy) and it wants to reveal that LI only to that element.
这在发起人不希望中间实体检查LI并且具有SIP消息目标的公钥的情况下最可能有效，因为发起人很难预测SIP消息将通过的中介。在发端人与特定SIP元素（例如，“主”或第一跳代理）具有信任关系且仅向该元素透露LI的有限环境中，它也可能有用。
Note that even in the case where the originator intends to encrypt LI for the benefit only of the target of the message, it may be quite difficult to anticipate the eventual endpoint of the message. These encrypted LIs will not be useful in any case where the anticipation of the originators is not met.
请注意，即使在发起人打算仅为了消息目标的利益而加密LI的情况下，也可能很难预测消息的最终端点。在未满足发起人预期的任何情况下，这些加密的LIs都不会有用。
An additional problem posed by this approach is that it requires some sort of public key discovery system, which compounds the operational complexity significantly. While this method is included for completeness, it is the consensus of the working group that the deployment scenarios in which this is appropriate will be relatively few; we do not believe it is an appropriate baseline approach.
这种方法带来的另一个问题是，它需要某种公钥发现系统，这大大增加了操作的复杂性。虽然纳入该方法是为了完整性，但工作组的共识是，适用该方法的部署场景相对较少；我们认为这不是一种适当的基线方法。
Another, more feasible approach is leveraging location by reference. When a SIP request conveys a reference, it cannot be properly said to be conveying location; location is conveyed upon dereferencing the URI in the question, and the meaning of <retransmission-allowed> must be understood in the context of that conveyance, not the forwarding of the SIP request.
另一个更可行的方法是利用参考位置。当SIP请求传递引用时，不能正确地说它是传递位置；位置在问题中解除对URI的引用时被传递，并且必须在该传递的上下文中理解<retransmission allowed>的含义，而不是SIP请求的转发。
The properties of references, especially the security properties, vary significantly depending on the nature and disposition of the resource indicated. Clearly, if the referenced PIDF-LO is available, in the same form, to any entity along the SIP signaling path that requests it, then inserting a reference has no advantages over inserting LI by value (and introduces wasteful complexity). However, if the Rule Maker influences the results of the dereferencing process, including determining who can receive LI at what degree of granularity and what policies are bound with the LI, the security properties are different.
引用的属性，特别是安全属性，根据所示资源的性质和配置而有很大的不同。显然，如果引用的PIDF-LO以相同的形式可用于请求它的SIP信令路径上的任何实体，那么插入引用与按值插入LI相比没有任何优势（并且引入了浪费的复杂性）。但是，如果规则制定者影响解除引用过程的结果，包括确定谁可以以何种粒度接收LI以及哪些策略与LI绑定，则安全属性是不同的。
It might superficially appear that this suffers from the same problems as the encryption approach, since the Rule Maker must anticipate a set of entities who are authorized to receive location information. The difference is that this set does not need to be communicated in the SIP request in order for authorization decisions to be made. There is a world of difference between managing a whitelist of a thousand parties that might ask for LI and sending a SIP request containing a thousand differently encrypted adumbrations on LI -- the former is commonplace and the latter is impossible. Additionally, some Rule Maker policies might not even require the establishment of an exhaustive whitelist. For example, it may be that there exists a finite set of commercial requestors that the Rule Maker would like to block, in a manner similar to the way ad-blockers operate in modern web browsers.
从表面上看，这可能会遇到与加密方法相同的问题，因为规则制定者必须预测一组被授权接收位置信息的实体。不同之处在于，为了做出授权决策，不需要在SIP请求中传递该集合。管理一个包含一千个可能请求LI的参与方的白名单和发送一个包含一千个不同加密的LI提示的SIP请求之间有着天壤之别——前者是司空见惯的，后者是不可能的。此外，一些规则制定者政策甚至可能不需要建立详尽的白名单。例如，规则制定者可能希望阻止有限的商业请求者，其方式类似于现代网络浏览器中广告拦截器的操作方式。
In any system where one makes an authorization decision, a certain cost in authentication must be paid -- the greater the assurance the greater the cost. The precise cost will of course depend on the URI scheme of the reference. For SIP, Digest has a low computational cost but requires pre-established keys, which limits applicability. RFC 4474 Identity does not require any pre-association, but it does make signaling more heavyweight and requires the deployment of additional features in the network, including a web-like public key infrastructure (PKI).
在任何做出授权决策的系统中，必须支付一定的认证成本——保证越高，成本越高。确切的成本当然取决于引用的URI方案。对于SIP，摘要具有较低的计算成本，但需要预先建立的密钥，这限制了适用性。RFC 4474标识不需要任何预关联，但它确实使信令更重，并且需要在网络中部署其他功能，包括类似web的公钥基础设施（PKI）。
But even if no authentication takes place, in the Location-by-Reference (LbyR) case the meaning of <retransmission-allowed> is unambiguous -- each entity to which LI is conveyed in the dereference
但是，即使没有进行身份验证，在引用位置（LbyR）的情况下，<retransmission allowed>的含义是明确的——在解引用中LI被传递到的每个实体
process is bound by the retransmission policy. The cost of the reference itself is of course the server that maintains the resource. While not every SIP client has access to an appropriate server for this purpose, the fact that PIDF-LO builds on the typical SIP presence service makes this less implausible than it might be. Moreover, the LbyR approach casts the conveyance architecture in a manner familiar from RFC 3693, with a Location Server receiving requests from Location Recipients, which may be accepted or denied. This allows the preservation of the original semantics of <retransmission-allowed>.
进程受重传策略的约束。引用本身的成本当然是维护资源的服务器。虽然并非每个SIP客户机都可以为此访问适当的服务器，但PIDF-LO构建在典型SIP状态服务的基础上这一事实使其不那么令人难以置信。此外，LbyR方法以RFC3693中熟悉的方式强制转换传输架构，其中位置服务器接收来自位置接收者的请求，这些请求可以被接受或拒绝。这允许保留<retransmission allowed>的原始语义。
The most fundamental mechanism for limiting access to location information is simply not including it. While location-based routing might conceivably occur in almost any SIP message in the future, there is no requirement that location be included in the general case to support it. If it is not included and is required, an appropriate error indicating the lack may be returned and the choice made to continue communication with the information included. This challenge and response will slow the establishment of communication when it is required, but it is the most basic way to ensure that location distribution is limited to the times when it is required for communication to proceed.
限制位置信息访问的最基本机制就是不包括它。虽然基于位置的路由可能会在未来的几乎任何SIP消息中出现，但不要求在一般情况下包括位置以支持它。如果未包含并且是必需的，则可能会返回指示缺少的适当错误，并选择继续与包含的信息通信。这种挑战和响应将在需要时减缓通信的建立，但这是确保位置分配仅限于通信需要进行时的最基本方式。
Refraining from including location is the most appropriate choice for systems that do not wish to reveal location to any party in the SIP path.
对于不希望向SIP路径中的任何一方透露位置的系统，避免包含位置是最合适的选择。
Location-by-Reference is generally recommended as the most deployable mechanism for limiting access to LI which is passed via a SIP message. It is significantly easier to deploy than public key discovery systems, allows for both whitelists and blacklists, and can scale in ways that the inclusion of multiple encrypted bodies cannot. Encryption may be used in a limited set of circumstance where location-by-value must be used.
通过引用定位通常被推荐为最可部署的机制，用于限制通过SIP消息传递的对LI的访问。它比公钥发现系统更易于部署，允许白名单和黑名单，并且可以以包含多个加密实体所不能的方式进行扩展。在必须使用按值定位的有限情况下，可以使用加密。
The discussion in Section 3.3.2 describes 3 mechanisms for limiting the distribution of LI to specific entities. There remains the problem of limiting the use to which LI included by value or by reference may be put. In order to meet the need to limit that use, this document recommends the creation of a syntactical element in SIP to carry this information. As an exemplary concrete proposal, we recommend a "Location-Routing-Allowed" header as described below.
第3.3.2节中的讨论描述了限制向特定实体分配LI的3种机制。还有一个问题是限制LI的使用，通过值或引用包含LI。为了满足限制这种使用的需要，本文档建议在SIP中创建一个语法元素来携带此信息。作为一个示例性的具体方案，我们建议如下所述的“允许位置路由”标题。
When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is indicating permission to use the included LI for location-based routing. When "Location-Routing-Allowed" is set to "No", the originator is indicating that this use is not permitted. "Location-Routing-Allowed" being set to "No" has no protocol-level mechanism for enforcement of this behavior; like the PIDF-LO <retransmission-allowed> being set to "no", it is a way for the Rule Maker to express a preference to the SIP elements, which are LI recipients. It may, however, present a significant optimization. Where a location-by-reference is included with "Location-Routing-Allowed" set to "No", the SIP elements along the path know that they do not need to attempt to dereference the location information; this is significantly faster than attempting the dereference and being denied at the authentication stage.
当“允许位置路由”设置为“是”时，规则制定者表示允许将包含的LI用于基于位置的路由。当“允许位置路由”设置为“否”时，发起者表示不允许此使用。设置为“否”的“允许位置路由”没有用于强制执行此行为的协议级机制；与PIDF-LO<retransmission allowed>设置为“否”一样，这是规则制定者表达对SIP元素偏好的一种方式，SIP元素是LI接收者。然而，这可能是一个重要的优化。在“允许位置路由”设置为“否”的情况下包括通过引用的位置的情况下，路径上的SIP元素知道它们不需要尝试去引用位置信息；这比在身份验证阶段尝试取消引用和被拒绝要快得多。
We recommend that "Location-Routing-Allowed" be made mandatory-to-implement for elements complying with [LOC-CONVEY].
我们建议对符合[LOC-1]的元件强制实施“允许位置布线”。
We recommend that it appear in any SIP message that contains a location, whether by reference or by value.
我们建议它出现在任何包含位置的SIP消息中，无论是通过引用还是通过值。
We recommend that any SIP message containing a location but no "Location-Routing-Allowed" header should be treated as containing a "Location-Routing-Allowed" header set to "no".
我们建议，任何包含位置但没有“允许位置路由”标头的SIP消息都应被视为包含设置为“否”的“允许位置路由”标头。
We recommend that a UA be allowed to insert a "Location-Routing-Allowed" header even when it has not included a location, in order to set the policy for any locations inserted by other SIP elements.
我们建议允许UA插入“Location Routing allowed”（允许位置路由）头，即使它没有包含位置，以便为其他SIP元素插入的任何位置设置策略。
This allows the UA to assert that it is a Rule Maker for locations, even when the network architecture in which the UA is present inserts the location into SIP messages after the UA has originated the SIP exchange.
这允许UA断言它是位置的规则制定者，即使UA所在的网络体系结构在UA发起SIP交换后将位置插入SIP消息中。
We recommend that any SIP element inserting a location, whether by reference or by value, insert a "Location-Routing-Allowed" header if one is not already present. If one is present, it should not be overridden by the SIP element inserting the location.
我们建议任何插入位置的SIP元素（无论是通过引用还是通过值）插入“允许位置路由”标头（如果尚未存在）。如果存在，则不应被插入位置的SIP元素覆盖。
We recommend that any SIP element not the originator of a message and not inserting a location be enjoined from inserting a "Location-Routing-Allowed" header.
我们建议禁止任何不是消息发起人且未插入位置的SIP元素插入“允许位置路由”标头。
Back-to-back user agent (B2BUA) behavior is often difficult to proscribe. There are many uses of B2BUAs, and the rules that apply to location would depend on the actual use case. This section suggests what any SIP mechanism arising from this document might wish to consider with regard to B2BUA behavior.
背靠背用户代理（B2BUA）行为通常很难禁止。B2BUA有很多用途，适用于位置的规则将取决于实际用例。本节建议从该文档产生的任何SIP机制可能希望考虑B2BUA行为。
In most uses of B2BUAs, they act as a simple intermediary between the nominal originating and nominal terminating UAs, that is, a proxy that does something proxies aren't allowed to do. In such cases, the B2BUA must conform to any new routing-allowed mechanism if it chooses an outgoing route. As this document advises proxies, <retransmission-allowed> does not apply to the B2BUA in this case, and the B2BUA must copy the LI, the new routing-allowed, and existing <retransmission-allowed> values.
在B2BUA的大多数使用中，它们充当名义发起和名义终止UAs之间的简单中介，也就是说，代理做代理不允许做的事情。在这种情况下，如果B2BUA选择传出路由，它必须符合任何新的路由允许机制。正如本文件所建议的，在这种情况下，<retransmission allowed>不适用于B2BUA，B2BUA必须复制LI、允许的新路由和现有的<retransmission allowed>值。
Where the B2BUA in fact does act as an endpoint (terminating the session and originating a different session), <retransmission-allowed> applies to it, and it must not copy location if <retransmission-allowed> is "no". If it chooses a route for the outgoing leg, any new routing-allowed mechanism applies to it.
如果B2BUA实际上充当端点（终止会话并发起不同会话），<retransmission allowed>适用于B2BUA，并且如果<retransmission allowed>为“否”，则B2BUA不得复制位置。如果它为传出分支选择路由，则任何新的允许路由机制都将应用于它。
Encryption lets the originator control who, including B2BUAs, is allowed to see location. On the other hand, using encryption with LI, which is needed for routing, is problematic, in that it is often difficult to know in advance which elements do location-based routing. Similarly, using Location-by-Reference instead of location-by-value provides additional control to the originator over B2BUA behavior by controlling who can dereference. See Section 3.4 for more guidance on this trade off.
加密允许发起者控制允许查看位置的人，包括B2BUAs。另一方面，使用路由所需的LI加密是有问题的，因为通常很难提前知道哪些元素执行基于位置的路由。类似地，使用引用位置而不是值位置，通过控制谁可以取消引用，为发起人提供了对B2BUA行为的额外控制。有关此权衡的更多指导，请参见第3.4节。
The privacy and security implications of distributing location information are the fundamental subject of this document.
分发位置信息的隐私和安全影响是本文档的基本主题。
James Polk provided a series of questions regarding the specifics of the Location-Routing-Allowed mechanism, and this resulted in the recommendations in Section 3.4. Thanks to Brian Rosen for the text on B2BUAs.
James Polk提出了一系列关于位置路由允许机制的具体问题，这导致了第3.4节中的建议。感谢Brian Rosen提供关于B2BUAs的文本。
[LOC-CONVEY] Polk, J. and B. Rosen, "Location Conveyance for the Session Initiation Protocol", Work in Progress, March 2009.
[LOC-Transfer]Polk，J.和B.Rosen，“会话启动协议的位置传输”，正在进行的工作，2009年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693]Cuellar，J.，Morris，J.，Mulligan，D.，Peterson，J.，和J.Polk，“地质驱动要求”，RFC 3693，2004年2月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]Peterson，J.，“一种基于状态的GEOPRIV定位对象格式”，RFC41192005年12月。
Authors' Addresses
作者地址
Jon Peterson NeuStar, Inc.
乔恩·彼得森纽斯达公司。
EMail: jon.peterson@neustar.biz
EMail: jon.peterson@neustar.biz
Ted Hardie Qualcomm
泰德·哈迪高通公司
EMail: hardie@qualcomm.com
EMail: hardie@qualcomm.com
John Morris Center for Democracy & Technology
约翰·莫里斯民主与技术中心
EMail: jmorris@cdt.org
EMail: jmorris@cdt.org