Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 6915 Nominet UK
Updates: 6155 April 2013
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Bellis
Request for Comments: 6915 Nominet UK
Updates: 6155 April 2013
Category: Standards Track
ISSN: 2070-1721
Flow Identity Extension for HTTP-Enabled Location Delivery (HELD)
支持HTTP的位置传递的流标识扩展（保留）
Abstract
摘要
RFC 6155 specifies an extension for the HTTP-Enabled Location Delivery (HELD) protocol, allowing the use of an IP address and port number to request a Device location based on an individual packet flow.
RFC 6155指定HTTP启用位置传递（HOLD）协议的扩展，允许使用IP地址和端口号根据单个数据包流请求设备位置。
However, certain kinds of NAT require that identifiers for both ends of the packet flow must be specified in order to unambiguously satisfy the location request.
然而，某些类型的NAT要求必须指定包流两端的标识符，以便明确地满足位置请求。
This document specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension for HELD to support this requirement.
本文档为HOLD的流标识扩展指定XML模式和URN子命名空间，以支持此需求。
This document updates RFC 6155 by deprecating the port number elements specified therein.
本文档通过弃用其中指定的端口号元素来更新RFC 6155。
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/rfc6915.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6915.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:flow . . . . . . . . . 6
5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 7
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:flow . . . . . . . . . 6
5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 7
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . . 8
Work at the Emergency Location Task Group of NICC Standards Limited (the UK's telecoms industry standards body) prompted the addition of port number identifiers in HELD Identity [RFC6155] to allow HELD [RFC5985] requests for Devices that are behind NAT devices.
NICC标准有限公司（英国电信行业标准机构）紧急位置任务组的工作促使在保持身份[RFC6155]中添加端口号标识符，以允许NAT设备后面的设备的保持[RFC5985]请求。
Subsequent analysis has determined that in the presence of particular types of NAT devices, and in particular Carrier Grade NATs, it is necessary to know the complete tuple of (Layer 3 protocol, Layer 4 protocol, source address, source port, destination address, destination port) in order to unambiguously identify a flow, and subsequently the true Device.
随后的分析已经确定，在存在特定类型的NAT设备和特定载波级NAT的情况下，有必要知道（第3层协议、第4层协议、源地址、源端口、目的地址、目的端口）的完整元组，以便明确地识别流，然后才是真正的设备。
This document specifies an XML Schema and a URN Sub-Namespace for a Flow Identity Extension to support this requirement and provides a more generally applicable means of identifying a Device based on the parameters of a network flow of which it is an endpoint.
本文档为流标识扩展指定了XML模式和URN子命名空间，以支持此要求，并提供了一种更普遍适用的方法，用于根据作为端点的网络流的参数识别设备。
Since the Location Recipient may not know in advance whether the Device is behind a NAT device, the port number elements from Section 3.3 of [RFC6155] are deprecated and MUST NOT be used in new client implementations. Note that server implementations of this specification may still encounter requests formed by clients that have implemented only [RFC6155], and those requests might contain the deprecated port element.
由于位置接收者可能事先不知道设备是否在NAT设备后面，因此[RFC6155]第3.3节中的端口号元素已被弃用，并且不得在新的客户端实现中使用。请注意，此规范的服务器实现可能仍会遇到仅实现了[RFC6155]的客户端形成的请求，这些请求可能包含不推荐使用的端口元素。
For implementation details not specified in this document, please refer to [RFC6155] and [RFC5985].
有关本文件中未规定的实施细节，请参考[RFC6155]和[RFC5985]。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
The terms "Device" and "Target" are used as defined in [RFC6280].
术语“设备”和“目标”的使用与[RFC6280]中的定义相同。
An example HELD request is shown below:
持有请求的示例如下所示：
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType exact="true">geodetic</locationType>
<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
layer4="tcp" layer3="ipv4">
<src>
<address>192.0.2.25</address>
<port>1024</port>
</src>
<dst>
<address>198.51.100.238</address>
<port>80</port>
</dst>
</flow>
</locationRequest>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
responseTime="8">
<locationType exact="true">geodetic</locationType>
<flow xmlns="urn:ietf:params:xml:ns:geopriv:held:flow"
layer4="tcp" layer3="ipv4">
<src>
<address>192.0.2.25</address>
<port>1024</port>
</src>
<dst>
<address>198.51.100.238</address>
<port>80</port>
</dst>
</flow>
</locationRequest>
The <flow> element MUST contain:
<flow>元素必须包含：
o a "layer3" attribute with a value of "ipv4" or "ipv6".
o 值为“ipv4”或“ipv6”的“layer3”属性。
o a "layer4" attribute with a value of "udp" [RFC0768], "tcp" [RFC0793], "sctp" [RFC4960], "dccp" [RFC4340], or a decimal integer representing any applicable protocol from the IANA Assigned Internet Protocol Numbers Registry.
o “layer4”属性，其值为“udp”[RFC0768]、“tcp”[RFC0793]、“sctp”[RFC4960]、“dccp”[RFC4340]，或表示IANA分配的Internet协议号注册表中任何适用协议的十进制整数。
o an <src> element and a <dst> element whose child elements contain the Layer 3 address (which MUST conform to the relevant "IPv4address" or "IPv6address" grammar as defined in [RFC3986]) and the Layer 4 port number of each end of the flow.
o 一个<src>元素和一个<dst>元素，其子元素包含第3层地址（必须符合[RFC3986]中定义的相关“IPv4address”或“IPv6address”语法）和流每一端的第4层端口号。
and MAY optionally contain:
并且可以选择性地包含：
o a "target" attribute with a value of "src" (default) or "dst" to indicate which end of the flow corresponds to the Target of the <locationRequest> with respect to the HELD protocol.
o 值为“src”（默认值）或“dst”的“target”属性，用于指示流的哪一端与保持协议的<locationRequest>目标相对应。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:geopriv:held:flow"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:flow="urn:ietf:params:xml:ns:geopriv:held:flow"
elementFormDefault="qualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:geopriv:held:flow"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:flow="urn:ietf:params:xml:ns:geopriv:held:flow"
elementFormDefault="qualified">
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:flow">
HELD Flow Identity</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc6915.txt">
This document defines Flow Identity elements for HELD.
</xs:documentation>
</xs:annotation>
<xs:annotation>
<xs:appinfo
source="urn:ietf:params:xml:schema:geopriv:held:flow">
HELD Flow Identity</xs:appinfo>
<xs:documentation
source="http://www.rfc-editor.org/rfc/rfc6915.txt">
This document defines Flow Identity elements for HELD.
</xs:documentation>
</xs:annotation>
<xs:element name="flow" type="flow:flowIdentity"/>
<xs:element name="flow" type="flow:flowIdentity"/>
<xs:complexType name="flowIdentity">
<xs:sequence>
<xs:element name="src" type="flow:flowEndpoint"/>
<xs:element name="dst" type="flow:flowEndpoint"/>
</xs:sequence>
<xs:attribute name="target" default="src">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="(src|dst)"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="layer3" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="(ipv4|ipv6)"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="layer4" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="(udp|tcp|sctp|dccp|\d+)"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="flowIdentity">
<xs:sequence>
<xs:element name="src" type="flow:flowEndpoint"/>
<xs:element name="dst" type="flow:flowEndpoint"/>
</xs:sequence>
<xs:attribute name="target" default="src">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="(src|dst)"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="layer3" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="(ipv4|ipv6)"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name="layer4" use="required">
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:pattern value="(udp|tcp|sctp|dccp|\d+)"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
<xs:complexType name="flowEndpoint">
<xs:all>
<xs:element name="address">
<xs:simpleType>
<xs:restriction base="xs:token"/>
</xs:simpleType>
</xs:element>
<xs:element name="port">
<xs:simpleType>
<xs:restriction base="xs:unsignedShort">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:schema>
<xs:complexType name="flowEndpoint">
<xs:all>
<xs:element name="address">
<xs:simpleType>
<xs:restriction base="xs:token"/>
</xs:simpleType>
</xs:element>
<xs:element name="port">
<xs:simpleType>
<xs:restriction base="xs:unsignedShort">
<xs:minInclusive value="1"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:all>
</xs:complexType>
</xs:schema>
5.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:flow
5.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:geopriv:held:flow
This section registers a new XML namespace, "urn:ietf:params:xml:ns:geopriv:held:flow", as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册了一个新的XML名称空间“urn:ietf:params:XML:ns:geopriv:hold:flow”。
URI: urn:ietf:params:xml:ns:geopriv:held:flow
URI: urn:ietf:params:xml:ns:geopriv:held:flow
Registrant Contact: IETF GEOPRIV Working Group (geopriv@ietf.org), Ray Bellis (ray.bellis@nominet.org.uk)
注册人联系人：IETF GEOPRIV工作组(geopriv@ietf.org)，雷·贝利斯（雷。bellis@nominet.org.uk)
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Flow Identity Parameters</title>
</head>
<body>
<h1>Namespace for HELD Flow Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:flow</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6915.txt">
RFC 6915</a>.</p>
</body>
</html>
END
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Flow Identity Parameters</title>
</head>
<body>
<h1>Namespace for HELD Flow Identity Parameters</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:flow</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc6915.txt">
RFC 6915</a>.</p>
</body>
</html>
END
This section registers an XML Schema as per the guidelines in [RFC3688].
本节根据[RFC3688]中的指南注册XML模式。
URI: urn:ietf:params:xml:ns:geopriv:held:flow
URI: urn:ietf:params:xml:ns:geopriv:held:flow
Registrant Contact: IETF GEOPRIV Working Group (geopriv@ietf.org), Ray Bellis (ray.bellis@nominet.org.uk)
注册人联系人：IETF GEOPRIV工作组(geopriv@ietf.org)，雷·贝利斯（雷。bellis@nominet.org.uk)
Schema: The XML for this schema can be found as the entirety of Section 4 of this document.
模式：此模式的XML可作为本文档第4节的全部内容找到。
All of the considerations in [RFC6155] apply to the use of the mechanism defined in this document. Like [RFC6155], this specification assumes that the Location Server being queried already has access to the internal state of the network near one end of the flow being queried (for instance, access to the bindings in a NAT in the path of the flow). Clients making queries using this specification in environments where that assumption may not be true should be aware that the request provides information about that client's communications that the Location Server would not otherwise be able to discern and may represent additional privacy exposure for that client.
[RFC6155]中的所有注意事项适用于本文件中定义的机制的使用。与[RFC6155]类似，本规范假设被查询的位置服务器已经可以访问被查询流一端附近的网络内部状态（例如，访问流路径中NAT中的绑定）。在该假设可能不成立的环境中使用本规范进行查询的客户应意识到，该请求提供了有关该客户通信的信息，位置服务器无法识别这些信息，并且可能代表该客户的额外隐私暴露。
This document introduces no new security considerations beyond those in [RFC6155].
除[RFC6155]中的安全注意事项外，本文档未引入任何新的安全注意事项。
The author wishes to thank the members of the NICC Emergency Location Task Group, the IETF GeoPriv Working Group, and the authors of [RFC6155], from which the text for the URN and XML Schema Registrations were derived.
作者希望感谢NICC紧急位置任务组、IETF GeoPriv工作组的成员以及[RFC6155]的作者，URN和XML模式注册的文本就是从这些文件中衍生出来的。
[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月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985]Barnes，M.，“支持HTTP的位置传递（保留）”，RFC 59852010年9月。
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011.
[RFC6155]Winterbottom，J.，Thomson，M.，Tschofenig，H.，和R.Barnes，“在支持HTTP的位置交付中使用设备标识（保留）”，RFC 61552011年3月。
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC0768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]Postel，J.，“传输控制协议”，标准7，RFC 793，1981年9月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]Kohler，E.，Handley，M.和S.Floyd，“数据报拥塞控制协议（DCCP）”，RFC 43402006年3月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年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月。
Author's Address
作者地址
Ray Bellis Nominet UK Edmund Halley Road Oxford OX4 4DQ United Kingdom
Ray Bellis Nominet UK Edmund Halley Road OX4 4DQ英国牛津大学
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/
Phone: +44 1865 332211
EMail: ray.bellis@nominet.org.uk
URI: http://www.nominet.org.uk/