Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 6447 Individual
Category: Standards Track B. Rosen
ISSN: 2070-1721 NeuStar
H. Tschofenig
Nokia Siemens Networks
January 2012
Internet Engineering Task Force (IETF) R. Mahy
Request for Comments: 6447 Individual
Category: Standards Track B. Rosen
ISSN: 2070-1721 NeuStar
H. Tschofenig
Nokia Siemens Networks
January 2012
Filtering Location Notifications in the Session Initiation Protocol (SIP)
过滤会话启动协议（SIP）中的位置通知
Abstract
摘要
This document describes filters that limit asynchronous location notifications to compelling events. These filters are designed as an extension to RFC 4661, an XML-based format for event notification filtering, and based on RFC 3856, the SIP presence event package. The resulting location information is conveyed in existing location formats wrapped in the Presence Information Data Format Location Object (PIDF-LO).
本文档介绍将异步位置通知限制为强制事件的筛选器。这些过滤器被设计为RFC4661（一种用于事件通知过滤的基于XML的格式）的扩展，并基于RFC3856（SIP状态事件包）。结果位置信息以存在信息数据格式位置对象（PIDF-LO）中包装的现有位置格式传送。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6447.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6447.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 5
3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 8
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16
6.2. Schema Registration for location-filter . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Filter Definitions . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Speed Changes . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Element Value Changes . . . . . . . . . . . . . . . . . . 5
3.4. Entering or Exiting a Region . . . . . . . . . . . . . . . 8
3.5. Location Type . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Rate Control . . . . . . . . . . . . . . . . . . . . . . . 12
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter . . . . . . . . . . 16
6.2. Schema Registration for location-filter . . . . . . . . . 16
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Conveying location information encapsulated with a Presence Information Data Format Location Object (PIDF-LO) [RFC4119] document within SIP is described in [SIP-LOC]. An alternative signaling approach to location conveyance, which uses asynchronous communication, is available with the SIP event notification mechanisms (see RFC 3265 [RFC3265]). This approach conveys location information in PIDF-LO format using the presence event package [RFC3856]. This document focuses on the event notification paradigm.
在SIP中传送用存在信息数据格式位置对象（PIDF-LO）[RFC4119]文档封装的位置信息在[SIP-LOC]中描述。SIP事件通知机制提供了位置传输的替代信令方法，该方法使用异步通信（请参阅RFC 3265[RFC3265]）。这种方法使用存在事件包[RFC3856]以PIDF-LO格式传递位置信息。本文档重点介绍事件通知范例。
Determining when to send event notifications with location information is technically more challenging than deciding when to send other categories of notifications, since location may be measured as a continuous gradient. Unlike notifications using discrete-valued quantities, it is difficult to know when a change in location is sufficiently large to warrant a notification. Event notifications [RFC3265] can be used with filters (see RFC 4661 [RFC4661]) that allow the number of notifications to be reduced. The mechanism described in this document defines an extension to RFC 4661 [RFC4661], which limits location notification to events that are of relevance to the subscriber. These filters persist until they are replaced with a newer filter or until the subscription itself is terminated.
确定何时发送带有位置信息的事件通知在技术上比决定何时发送其他类别的通知更具挑战性，因为位置可以作为一个连续梯度来衡量。与使用离散值量的通知不同，很难知道位置的变化何时足够大，足以保证发出通知。事件通知[RFC3265]可与允许减少通知数量的过滤器（请参阅RFC 4661[RFC4661]）一起使用。本文档中描述的机制定义了RFC 4661[RFC4661]的扩展，该扩展将位置通知限制为与订阅者相关的事件。这些筛选器将一直存在，直到它们被新的筛选器替换，或者直到订阅本身终止。
The frequency of notifications necessary for various geographic location applications varies dramatically. The subscriber should be able to get asynchronous notifications with appropriate frequency and granularity, without being flooded with a large number of notifications that are not important to the application.
各种地理位置应用程序所需的通知频率差别很大。订阅者应该能够获得具有适当频率和粒度的异步通知，而不会被大量对应用程序不重要的通知淹没。
This document defines new event filters and describes others using existing mechanisms that may be relevant to a subscriber in the context of location filtering. Based on the functionality defined in this document, notifications can be provided in the following cases:
本文档定义了新的事件筛选器，并描述了使用现有机制的其他筛选器，这些机制可能与位置筛选上下文中的订阅者相关。根据本文档中定义的功能，可以在以下情况下提供通知：
1. the Target moves more than a specified distance since the last notification (see Section 3.1).
1. 自上次通知以来，目标移动超过指定距离（见第3.1节）。
2. the Target exceeds a specified speed (see Section 3.2).
2. 目标速度超过规定速度（见第3.2节）。
3. the Target enters or exits a 2-dimensional region, described by a circle or a polygon (see Section 3.4).
3. 目标进入或退出由圆或多边形描述的二维区域（见第3.4节）。
4. one or more of the values of the specified civic location have changed for the location of the Target (see Section 3.3). For example, the value of the civic address '<A1>' element has changed from 'California' to 'Nevada'.
4. 指定位置的一个或多个值因目标位置而改变（见第3.3节）。例如，civic address“<A1>”元素的值已从“California”更改为“Nevada”。
5. the type of location information requested (see Section 3.5) changes, for example, from civic to geodetic location or vice versa.
5. 请求的位置信息类型（见第3.5节）会发生变化，例如，从城市位置到大地测量位置，反之亦然。
6. a certain amount of time passes (see Section 3.6).
6. 经过一定时间（见第3.6节）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
This document reuses terminology from [RFC6280].
本文件重复使用[RFC6280]中的术语。
This specification builds on a number of other specifications, as noted in Section 1. In order to reduce the number of options (and thereby decrease the chance of interoperability problems), the functionality described in the following sub-sections of [RFC4661] MUST be implemented: the <ns-bindings> element (see Section 3.3 of [RFC4661]); the <filter> element (Section 3.4 of [RFC4661]); and the <trigger> element (Section 3.6 of [RFC4661]), except for the <added> and <removed> sub-elements.
本规范以许多其他规范为基础，如第1节所述。为了减少选项数量（从而降低互操作性问题的可能性），必须实现[RFC4661]以下小节中描述的功能：<ns bindings>元素（参见[RFC4661]第3.3节）；<filter>元件（RFC4661第3.4节）；以及<trigger>元素（RFC4661第3.6节），但<added>和<removed>子元素除外。
The <moved> element MUST contain a value in meters indicating the minimum distance that the resource must have moved from the location of the resource since the last notification was sent in order to trigger this event. The distance MUST be measured in meters absolutely from the point of the last notification, and must include vertical movement. The <moved> element MUST NOT appear more than once as a child element of the <filter> element.
<moved>元素必须包含一个以米为单位的值，该值指示自上次发送通知以来资源必须从资源位置移动的最小距离，以便触发此事件。距离必须以米为单位测量，绝对距离上次通知的点，并且必须包括垂直移动。<moved>元素不能作为<filter>元素的子元素出现多次。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:moved>300</lf:moved>
</trigger>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:moved>300</lf:moved>
</trigger>
</filter>
</filter-set>
Figure 1: Movement Filter Example
图1：移动过滤器示例
Speed changes can be filtered by combining functionality from RFC 4661 with the PIDF-LO extensions for spatial orientation, speed, heading, and acceleration defined in [RFC5962]. The value of the <speed> element from [RFC5962] MUST be defined in meters per second. Note that the condition could be met by a change in any axis, including altitude.
通过将RFC 4661的功能与[RFC5962]中定义的空间方向、速度、航向和加速度的PIDF-LO扩展相结合，可以过滤速度变化。[RFC5962]中<speed>元素的值必须以米/秒为单位定义。请注意，任何轴（包括高度）的变化都可以满足该条件。
Figure 2 shows an example for a trigger that fires when the speed of the Target changes by 3 meters per second.
图2显示了当目标速度每秒改变3米时触发的触发器示例。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="dyn"
urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed by="3">
//dyn:speed
</changed>
</trigger>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="dyn"
urn="urn:ietf:params:xml:schema:pidf:dynamic"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed by="3">
//dyn:speed
</changed>
</trigger>
</filter>
</filter-set>
Figure 2: Speed Change Example
图2：速度变化示例
An implementation MUST support <ns-bindings> to replace the namespace prefix. The XPath expression MUST start with a '//' followed by a single element. No other form of XPath expression is supported. The <changed> element comes with a few attributes but only the 'by' attribute MUST be implemented by this specification.
实现必须支持<ns bindings>以替换名称空间前缀。XPath表达式必须以“/”开头，后跟单个元素。不支持其他形式的XPath表达式。<changed>元素有几个属性，但只有“by”属性必须由该规范实现。
Changes in values, for example related to civic location information, is provided by the base functionality offered with RFC 4661 utilizing the <changed> element.
RFC 4661使用<changed>元素提供的基本功能提供了值的变化，例如与城市位置信息相关的值的变化。
The following example illustrates a filter that triggers when the Target's location changes from 'FR' (France) to some other country.
以下示例说明了当目标位置从“FR”（法国）更改为其他国家/地区时触发的筛选器。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed from="FR">//ca:country</changed>
</trigger>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed from="FR">//ca:country</changed>
</trigger>
</filter>
</filter-set>
Figure 3: Element Value Change Example (Country Change)
图3：元素值更改示例（国家/地区更改）
At times when it is desirable to know if any one element of a list of CAtypes changes, then they have to be put into separate <changes> filters to ensure the subscriber is notified when any of the element values change. Figure 4 shows such an example that illustrates the difference.
当需要知道CATYPE列表中的任何一个元素是否更改时，必须将它们放入单独的<changes>过滤器中，以确保在任何元素值更改时通知订阅者。图4显示了这样一个示例，说明了差异。
(A change in value of ANY of the five tokens triggers an event.)
（五个标记中任何一个的值发生变化都会触发事件。）
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:country</changed>
</trigger>
<trigger>
<changed>//ca:A1</changed>
</trigger>
<trigger>
<changed>//ca:A2</changed>
</trigger>
<trigger>
<changed>//ca:A3</changed>
</trigger>
<trigger>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:country</changed>
</trigger>
<trigger>
<changed>//ca:A1</changed>
</trigger>
<trigger>
<changed>//ca:A2</changed>
</trigger>
<trigger>
<changed>//ca:A3</changed>
</trigger>
<trigger>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
Figure 4: Element Value Change Example
图4：元素值更改示例
Finally, Figure 5 shows an example where a notification is sent when the civic address tokens A3 and PC change (BOTH elements must change in order to let the <trigger> element evaluate to TRUE).
最后，图5显示了一个示例，其中当civic address令牌A3和PC更改时发送通知（两个元素都必须更改，以使<trigger>元素的计算结果为TRUE）。
(Only a change in BOTH tokens triggers an event.)
（只有两个令牌的更改才会触发事件。）
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set xmlns="urn:ietf:params:xml:ns:simple-filter">
<ns-bindings>
<ns-binding prefix="ca"
urn="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"/>
</ns-bindings>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<changed>//ca:A3</changed>
<changed>//ca:PC</changed>
</trigger>
</filter>
</filter-set>
Figure 5: Element Value Change Example
图5：元素值更改示例
Note: The civic address tokens country, A1, A2, ..., A6 are hierarchical. It is likely that a change in one civic address token therefore leads to changes of tokens lower in the hierarchy, e.g., a change in A3 ('city or town') may cause a change in A4, A5, and A6.
注意：公民地址令牌国家、A1、A2、…、A6是分级的。因此，一个公民地址令牌的更改可能导致层次结构中较低令牌的更改，例如，A3（“城市或城镇”）的更改可能导致A4、A5和A6的更改。
An implementation MUST support <ns-bindings> to replace the namespace prefix. The XPath expression MUST start with a '//' followed by a single element. No other form of XPath expression is supported. No other variant is supported. The <changed> element comes with a few attributes and the 'by', 'to', and 'from' attribute MUST be implemented to support this specification.
实现必须支持<ns bindings>以替换名称空间前缀。XPath表达式必须以“/”开头，后跟单个元素。不支持其他形式的XPath表达式。不支持其他变体。<changed>元素带有一些属性，必须实现“by”、“to”和“from”属性以支持此规范。
The <enterOrExit> condition is satisfied when the Target enters or exits a 2-dimensional region described by a polygon (as defined in Section 5.2.2 of [RFC5491]) or a circle (as defined in Section 5.2.3 of [RFC5491]). The <enterOrExit> element MUST contain either a polygon or a circle as a child element. The <enterOrExit> element MUST NOT have more than one polygon and/or circle.
当目标进入或退出由多边形（定义见[RFC5491]第5.2.2节）或圆（定义见[RFC5491]第5.2.3节）描述的二维区域时，满足<entorexit>条件。元素必须包含多边形或圆作为子元素。<entorexit>元素不能有多个多边形和/或圆。
If the Target was previously outside the region, the notifier sends a notification when the Target's location is within the region with at least 50% confidence. Similarly, when a Target starts within the region, a notification is sent when the Target's location moves outside the region with at least 50% confidence.
如果目标先前位于该区域之外，则当目标位置位于该区域内时，通知程序将以至少50%的置信度发送通知。类似地，当目标在区域内启动时，当目标位置以至少50%的置信度移动到区域外时，将发送通知。
Note that having 50% confidence that the Target is inside the area does not correspond to 50% outside. The confidence that the location is within the region, plus the confidence that the location is
请注意，目标位于区域内的50%置信度与区域外的50%置信度并不对应。位置在区域内的置信度，加上位置在区域内的置信度
outside the region is limited to the confidence of the location. The total confidence depends on the confidence in the location, which is always less than 100% (95% is recommended in [RFC5491]). The benefit of this is that notifications are naturally limited: small movements (relative to the uncertainty of the location) at the borders of the region do not trigger notifications.
该区域以外的区域仅限于该位置的置信度。总置信度取决于位置的置信度，该置信度始终小于100%（在[RFC5491]中建议为95%）。这样做的好处是通知自然是有限的：区域边界的小规模移动（相对于位置的不确定性）不会触发通知。
Figure 6 shows filter examples whereby a notification is sent when the Target enters or exits an area described by a circle, and Figure 7 describes an area using a polygon.
图6显示了当目标进入或退出由圆描述的区域时发送通知的过滤器示例，图7描述了使用多边形的区域。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml"
xmlns:gs="http://www.opengis.net/pidflo/1.0">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gs:Circle
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius
uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gs:Circle
srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>42.5463 -73.2512</gml:pos>
<gs:radius
uom="urn:ogc:def:uom:EPSG::9001">
850.24
</gs:radius>
</gs:Circle>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
Figure 6: <enterOrExit> Circle Filter Example
Figure 6: <enterOrExit> Circle Filter Example
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml">
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter"
xmlns:gml="http://www.opengis.net/gml">
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
<gml:pos>43.111 -73.322</gml:pos>
<!--F-->
<gml:pos>43.111 -73.222</gml:pos>
<!--E-->
<gml:pos>43.311 -73.122</gml:pos>
<!--D-->
<gml:pos>43.411 -73.222</gml:pos>
<!--C-->
<gml:pos>43.411 -73.322</gml:pos>
<!--B-->
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
<filter id="123" uri="sip:presentity@example.com">
<trigger>
<lf:enterOrExit>
<gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
<gml:exterior>
<gml:LinearRing>
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
<gml:pos>43.111 -73.322</gml:pos>
<!--F-->
<gml:pos>43.111 -73.222</gml:pos>
<!--E-->
<gml:pos>43.311 -73.122</gml:pos>
<!--D-->
<gml:pos>43.411 -73.222</gml:pos>
<!--C-->
<gml:pos>43.411 -73.322</gml:pos>
<!--B-->
<gml:pos>43.311 -73.422</gml:pos>
<!--A-->
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</lf:enterOrExit>
</trigger>
</filter>
</filter-set>
Figure 7: <enterOrExit> Polygon Filter Example
Figure 7: <enterOrExit> Polygon Filter Example
The <locationType> element MAY be included as a child element of the <what> element. It contains a list of location information types that are requested by the subscriber. The following list describes the possible values:
<locationType>元素可以作为<what>元素的子元素包含。它包含订阅者请求的位置信息类型列表。以下列表描述了可能的值：
any: The Notifier SHOULD attempt to provide location information in all forms available to it.
任何：通知程序应尝试以其可用的所有形式提供位置信息。
geodetic: The Notifier SHOULD return a location by value in the form of a geodetic location.
大地测量：通知程序应以大地测量位置的形式按值返回位置。
civic: The Notifier SHOULD return a location by value in the form of a civic address.
思域：通知程序应以思域地址的形式按值返回位置。
The Notifier SHOULD return the requested location type or types. The location types the Notifier returns also depends on the setting of the optional 'exact' attribute. If the 'exact' attribute is set to "true", then the Notifier MUST return either the requested location type or no location information. The 'exact' attribute does not apply (is ignored) for a request for a location type of "any".
通知程序应返回请求的位置类型。通知程序返回的位置类型还取决于可选“精确”属性的设置。如果“精确”属性设置为“true”，则通知程序必须返回请求的位置类型或不返回位置信息。“精确”属性不适用于（忽略）位置类型为“任意”的请求。
In the case of a request for specific locationType(s) and the 'exact' attribute is "false", the Notifier MAY provide additional location types, or it MAY provide alternative types if the request cannot be satisfied for a requested location type.
如果请求特定位置类型且“精确”属性为“false”，则通知者可以提供其他位置类型，或者如果无法满足请求的位置类型，通知者可以提供替代类型。
If the <locationType> element is absent, a value of "any" MUST be assumed as the default.
如果缺少<locationType>元素，则必须假定值“any”为默认值。
The Notifier SHOULD provide civic and geodetic location information in the response in the same order in which they were included in the "locationType" element in the request, if both were explicitly requested. Indeed, the primary advantage of including specific location types in a request when the 'exact' attribute is set to "false" is to ensure that one receives the available locations in a specific order. For example, a subscription for "civic" (with the 'exact' attribute set to "false") could yield any of the following location types in the response:
通知者应在响应中提供公民和大地测量位置信息，其顺序与请求中“locationType”元素中包含公民和大地测量位置信息的顺序相同（如果两者均明确请求）。实际上，当“精确”属性设置为“false”时，在请求中包含特定位置类型的主要优点是确保以特定顺序接收可用位置。例如，订阅“civic”（将'exact'属性设置为“false”）可能会在响应中产生以下任何位置类型：
o civic
o 公民的
o civic, geodetic
o 大地测量学
o geodetic (only if civic is not available)
o 大地测量（仅当civic不可用时）
The default value of "false" for the 'exact' attribute allows the Notifier the option of returning something beyond what is specified, such as a set of location URIs when only a civic location was requested.
“精确”属性的默认值“false”允许通知程序选择返回超出指定范围的内容，例如仅请求civic位置时返回一组位置URI。
An example is shown in Figure 8 that utilizes the <locationType> element with the 'exact' attribute.
图8中显示了一个示例，它利用了带有'exact'属性的<locationType>元素。
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lf:locationType exact="true">
geodetic
</lf:locationType>
</what>
</filter>
</filter-set>
<?xml version="1.0" encoding="UTF-8"?>
<filter-set
xmlns="urn:ietf:params:xml:ns:simple-filter"
xmlns:lf="urn:ietf:params:xml:ns:location-filter">
<filter id="123" uri="sip:presentity@example.com">
<what>
<lf:locationType exact="true">
geodetic
</lf:locationType>
</what>
</filter>
</filter-set>
Figure 8: <locationType> Filter Example
Figure 8: <locationType> Filter Example
[RFC6446] extends the SIP events framework by defining three Event header field parameters that allow a subscriber to set a minimum, a maximum, and an adaptive minimum of event notifications generated by the notifier. This allows a subscriber to have overall control over the stream of notifications, for example to avoid being flooded. Two of the parameters, namely "min-rate" (which specifies a minimum notification rate per second) and "max-rate" (which specifies a maximum notification rate per second) are used by this document. Only the implementation of these two attributes is required from the attributes defined in [RFC6446]. Whenever the time since the most recent notification exceeds the interval corresponding to 1 / "min-rate", the current state would be sent in its entirety, just like after a subscription refresh.
[RFC6446]通过定义三个事件头字段参数来扩展SIP事件框架，这些参数允许订阅者设置由通知程序生成的事件通知的最小值、最大值和自适应最小值。这允许订阅者对通知流进行全面控制，例如避免被淹没。本文档使用其中两个参数，即“最小速率”（指定每秒的最小通知速率）和“最大速率”（指定每秒的最大通知速率）。[RFC6446]中定义的属性只需要实现这两个属性。每当最近一次通知后的时间超过1/“min rate”对应的时间间隔时，当前状态将全部发送，就像订阅刷新后一样。
A notifier is required to send a NOTIFY request immediately after creation of a subscription. If state is not available at that time, then the NOTIFY request may be sent with no content. A separate NOTIFY containing location is subsequently generated so that the rate of notification since the last NOTIFY falls between "min-rate" and "max-rate". An important use case for location-based applications focuses on the behavior of the initial NOTIFY message(s) and the information it returns, for example in case of emergency call routing. When an initial NOTIFY is transmitted, it might not include complete state.
创建订阅后，需要通知程序立即发送通知请求。如果此时状态不可用，则发送通知请求时可能没有内容。随后生成包含位置的单独通知，以便自上次通知以来的通知速率介于“最小速率”和“最大速率”之间。基于位置的应用程序的一个重要用例关注初始通知消息的行为及其返回的信息，例如在紧急呼叫路由的情况下。传输初始通知时，可能不包括完整状态。
Subscriber Notifier
|---SUBSCRIBE(1)--->| Create subscription (w/large value
|<-------200--------| for min-rate and max-rate)
|<-----NOTIFY(2)----| Return initial notify with no state
|--------200------->|
| ... |
|<-----NOTIFY(3)----| Return full state (between min-rate
|--------200------->| and max-rate)
|---SUBSCRIBE(4)--->| Update subscription (to update
|<-------200--------| min-rate and max-rate)
Subscriber Notifier
|---SUBSCRIBE(1)--->| Create subscription (w/large value
|<-------200--------| for min-rate and max-rate)
|<-----NOTIFY(2)----| Return initial notify with no state
|--------200------->|
| ... |
|<-----NOTIFY(3)----| Return full state (between min-rate
|--------200------->| and max-rate)
|---SUBSCRIBE(4)--->| Update subscription (to update
|<-------200--------| min-rate and max-rate)
Figure 9: SUBSCRIBE/NOTIFY with Rate Control
图9：使用速率控制的订阅/通知
Figure 9 shows a SUBSCRIBE/NOTIFY exchange. The initial SUBSCRIBE message (1) has filters attached and contains a "min-rate" rate control parameter. In certain situations, it is important to obtain some amount of location information within a relatively short and pre-defined period of time, even if the obtained location information contains a high amount of uncertainty and location information with less uncertainty could be available at a later point in time. An example is emergency call routing where an emergency services routing proxy may need to obtain location information suitable for routing rather quickly and subsequently a Public Safety Answering Point requests location information for dispatch.
图9显示了订阅/通知交换。初始订阅消息（1）已附加筛选器，并包含“最小速率”速率控制参数。在某些情况下，重要的是在相对较短的预定义时间内获得一定数量的位置信息，即使所获得的位置信息包含大量不确定性，并且不确定性较小的位置信息可能在稍后的时间点可用。一个例子是紧急呼叫路由，其中紧急服务路由代理可能需要相当快地获得适合路由的位置信息，并且随后公共安全应答点请求发送位置信息。
To obtain location information in a timely fashion using the SUBSCRIBE/NOTIFY mechanism, it is RECOMMENDED that the initial SUBSCRIBE contain a "min-rate" rate control parameter (with a large value, corresponding to a very short delay before the next notification) that is updated in a later message to a more sensible value. This provides equivalent functionality to the 'responseTime' attribute in Section 6.1 of [RFC5985]. The "min-rate" for this first request is therefore much larger (much more rapid) than the updated "min-rate" value. Depending on the value in the "min-rate" parameter, the Notifier may immediately send the initial NOTIFY message (see message 2) without a body if no location information is available at this point in time. The desired location information may then arrive in the subsequent NOTIFY message (see message 3). Updating the "min-rate" for the subscription can be performed in the 200 response (see message 3) to the NOTIFY that contains location state, or in a subsequent SUBSCRIBE request (as in message 4).
为了使用SUBSCRIBE/NOTIFY机制及时获取位置信息，建议初始SUBSCRIBE包含一个“min rate”速率控制参数（具有较大的值，对应于下一次通知之前的很短延迟），该参数在以后的消息中更新为更合理的值。这提供了与[RFC5985]第6.1节中“responseTime”属性等效的功能。因此，第一个请求的“最小速率”比更新的“最小速率”值大得多（快得多）。根据“min rate”（最小速率）参数中的值，如果此时没有可用的位置信息，通知程序可以立即发送初始通知消息（参见消息2），而不带正文。然后，所需的位置信息可能会出现在随后的通知消息中（参见消息3）。更新订阅的“最小速率”可以在包含位置状态的通知的200响应（见消息3）中执行，也可以在后续订阅请求（如消息4所示）中执行。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:location-filter"
xmlns:filter="urn:ietf:params:xml:ns:location-filter"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:location-filter"
xmlns:filter="urn:ietf:params:xml:ns:location-filter"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:gml="http://www.opengis.net/gml">
<xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>
<xs:element name="enterOrExit" type="gml:GeometryPropertyType"/>
<xs:element name="moved" type="filter:movedType"/>
<xs:element name="moved" type="filter:movedType"/>
<xs:complexType name="movedType">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="movedType">
<xs:simpleContent>
<xs:extension base="xs:double">
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="locationType" type="filter:locationTypeType"/>
<xs:element name="locationType" type="filter:locationTypeType"/>
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="filter:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="locationTypeBase">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="any"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="filter:locationTypeList">
<xs:minLength value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
<xs:simpleType name="locationTypeList">
<xs:list>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="civic"/>
<xs:enumeration value="geodetic"/>
</xs:restriction>
</xs:simpleType>
</xs:list>
</xs:simpleType>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="filter:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
<xs:complexType name="locationTypeType">
<xs:simpleContent>
<xs:extension base="filter:locationTypeBase">
<xs:attribute name="exact" type="xs:boolean"
use="optional" default="false"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
Figure 10: XML Schema
图10:XML模式
This document specifies one element, namely filters, utilized in larger systems. As such, this document builds on a number of specifications for the security of the complete solution, namely
本文件规定了一个在较大系统中使用的元素，即过滤器。因此，本文档基于一系列完整解决方案的安全性规范，即
o the SIP event notification mechanism, described in RFC 3265 [RFC3265], defining the SUBSCRIBE/NOTIFY messages.
o RFC 3265[RFC3265]中描述的SIP事件通知机制，定义订阅/通知消息。
o the presence event package, described in RFC 3856 [RFC3856], which is a concrete instantiation of the general event notification framework.
o RFC 3856[RFC3856]中描述的状态事件包是通用事件通知框架的具体实例。
o the filter framework, described in RFC 4661 [RFC4661], to offer the ability to reduce the amount of notifications being sent.
o RFC 4661[RFC4661]中描述的过滤器框架，用于提供减少发送的通知量的能力。
Finally, this document indirectly (via the SIP presence event package) relies on PIDF-LO, described in RFC 4119 [RFC4119], as the XML container that carries location information.
最后，本文档间接（通过SIP presence事件包）依赖于RFC 4119[RFC4119]中描述的PIDF-LO，作为携带位置信息的XML容器。
Each of the documents listed above comes with a Security Considerations section but the security and privacy aspects are best covered by the SIP presence event package; see Section 9 of [RFC3856], and with the GEOPRIV architectural description found in [RFC6280].
上面列出的每个文档都有一个安全注意事项部分，但SIP状态事件包最好涵盖安全和隐私方面；参见[RFC3856]第9节，以及[RFC6280]中的GEOPRIV架构描述。
The functionality offered by authorization policies to limit access to location information is provided by other protocols, such as Common Policy [RFC4745], Geolocation Policy [GEO-POLICY], or more recent work around HTTP-Enabled Location Delivery (HELD) context [HELD]. Although [GEO-POLICY] defines a standardized format for geolocation authorization policies, it does not define specific policies for controlling filters.
授权策略提供的限制对位置信息访问的功能由其他协议提供，例如公共策略[RFC4745]、地理位置策略[GEO-Policy]，或最近围绕启用HTTP的位置传递（HOLD）上下文[HOLD]开展的工作。尽管[GEO-POLICY]为地理位置授权策略定义了标准格式，但它没有定义控制过滤器的特定策略。
The functionality described in this document extends the filter framework with location-specific filters. Local policies might be
本文档中描述的功能使用特定于位置的过滤器扩展了过滤器框架。地方政策可能是
associated with the usage of certain filter constructs and with the amount of notifications that specific filter settings might cause. Uploading filters have a significant effect on the ways in which the request is handled at a server. As a result, it is especially important that messages containing this extension be authenticated and authorized. RFC 4661 [RFC4661] discusses this security threat and proposes authentication and authorization solutions applicable to this specification.
与某些筛选器构造的使用以及特定筛选器设置可能导致的通知量关联。上传过滤器对服务器处理请求的方式有很大影响。因此，对包含此扩展的消息进行身份验证和授权尤为重要。RFC 4661[RFC4661]讨论了这种安全威胁，并提出了适用于本规范的身份验证和授权解决方案。
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter
6.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:location-filter
This section registers a new XML namespace, as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册一个新的XML名称空间。
URI: urn:ietf:params:xml:ns:location-filter
URI: urn:ietf:params:xml:ns:location-filter
Registrant Contact: IETF, GEOPRIV working group, <geopriv@ietf.org>, as delegated by the IESG <iesg@ietf.org>.
注册人联系人：IETF、GEOPRIV工作组、<geopriv@ietf.org>，由IESG授权<iesg@ietf.org>.
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Location Filter Namespace</title>
</head>
<body>
<h1>Namespace for PIDF-LO Location Filters</h1>
<h2>urn:ietf:params:xml:ns:location-filter</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6447.txt">
RFC 6447</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Location Filter Namespace</title>
</head>
<body>
<h1>Namespace for PIDF-LO Location Filters</h1>
<h2>urn:ietf:params:xml:ns:location-filter</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6447.txt">
RFC 6447</a>.</p>
</body>
</html>
END
This specification registers a schema, as per the guidelines in [RFC3688].
本规范根据[RFC3688]中的指南注册模式。
URI: urn:ietf:params:xml:schema:location-filter
URI: urn:ietf:params:xml:schema:location-filter
Registrant Contact: IETF, GEOPRIV Working Group (geopriv@ietf.org), as delegated by the IESG (iesg@ietf.org).
注册人联系人：IETF、GEOPRIV工作组(geopriv@ietf.org)，由IESG授权(iesg@ietf.org).
XML: The XML can be found as the sole content of Section 4.
XML：XML是第4节的唯一内容。
We would like to thank Martin Thomson and James Polk for their contributions to this document.
我们要感谢Martin Thomson和James Polk对本文件的贡献。
Thanks to Richard Barnes, Alissa Cooper, Randall Gellens, Carl Reed, Ben Campbell, Adam Roach, Allan Thomson, and James Winterbottom for their comments.
感谢Richard Barnes、Alissa Cooper、Randall Gellens、Carl Reed、Ben Campbell、Adam Roach、Allan Thomson和James Winterbottom的评论。
Furthermore, we would like to thank Alexey Melnikov for his IESG review comments.
此外，我们还要感谢Alexey Melnikov对IESG审查的评论。
[GML] OpenGIS, "Open Geography Markup Language (GML) Implementation Specification", OpenGIS OGC 02-023r4, January 2003, <http://www.opengis.org/techno/implementation.htm>.
[GML]OpenGIS，“开放地理标记语言（GML）实现规范”，OpenGIS OGC 02-023r4，2003年1月<http://www.opengis.org/techno/implementation.htm>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC3856，2004年8月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119]Peterson，J.，“一种基于状态的GEOPRIV定位对象格式”，RFC41192005年12月。
[RFC4661] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, "An Extensible Markup Language (XML)- Based Format for Event Notification Filtering", RFC 4661, September 2006.
[RFC4661]Khartabil，H.，Leppanen，E.，Lonnfors，M.，和J.Costa Requena，“基于可扩展标记语言（XML）的事件通知过滤格式”，RFC 4661，2006年9月。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491]Winterbottom，J.，Thomson，M.，和H.Tschofenig，“GEOPRIV存在信息数据格式位置对象（PIDF-LO）使用说明、注意事项和建议”，RFC 54912009年3月。
[RFC5962] Schulzrinne, H., Singh, V., Tschofenig, H., and M. Thomson, "Dynamic Extensions to the Presence Information Data Format Location Object (PIDF-LO)", RFC 5962, September 2010.
[RFC5962]Schulzrinne，H.，Singh，V.，Tschofenig，H.，和M.Thomson，“状态信息数据格式位置对象（PIDF-LO）的动态扩展”，RFC 59622010年9月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280]Barnes，R.，Lepinski，M.，Cooper，A.，Morris，J.，Tschofenig，H.，和H.Schulzrinne，“互联网应用中的位置和位置隐私架构”，BCP 160，RFC 62802011年7月。
[RFC6446] Niemi, A., Kiss, K., and S. Loreto, "Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control", RFC 6446, January 2012.
[RFC6446]Niemi，A.，Kiss，K.，和S.Loreto，“用于通知速率控制的会话启动协议（SIP）事件通知扩展”，RFC 6446，2012年1月。
[GEO-POLICY] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, October 2011.
[GEO-POLICY]Schulzrinne，H.，Tschofenig，H.，Cuellar，J.，Polk，J.，Morris，J.，和M.Thomson，“地理位置政策：表达位置信息隐私偏好的文件格式”，正在进行的工作，2011年10月。
[HELD] Winterbottom, J., Tschofenig, H., and M. Thomson, "Location URI Contexts in HTTP-Enabled Location Delivery (HELD)", Work in Progress, October 2009.
[Hold]Winterbottom，J.，Tschofenig，H.和M.Thomson，“支持HTTP的位置交付中的位置URI上下文（Hold）”，正在进行的工作，2009年10月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[RFC4745]Schulzrinne，H.，Tschofenig，H.，Morris，J.，Cuellar，J.，Polk，J.，和J.Rosenberg，“共同政策：表达隐私偏好的文件格式”，RFC 47452007年2月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[SIP-LOC] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", Work in Progress, September 2011.
[SIP-LOC]Polk，J.，Rosen，B.，和J.Peterson，“会话启动协议的位置传输”，正在进行的工作，2011年9月。
Authors' Addresses
作者地址
Rohan Mahy Individual
Rohan Mahy个人
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Brian Rosen NeuStar 470 Conrad Dr. Mars, PA 16046 US
布莱恩·罗森·纽斯塔470康拉德·马尔斯博士，宾夕法尼亚州，美国16046
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Phone: +1 724 382 1051
EMail: br@brianrosen.net
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig诺基亚西门子网络公司芬兰Linnoitustie 6 Espoo 02600
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at