doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc6915.txt b/doc/rfc/rfc6915.txt
new file mode 100644
index 0000000..0db1520
--- /dev/null
+++ b/doc/rfc/rfc6915.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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)
+
+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.
+
+   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.
+
+   This document specifies an XML Schema and a URN Sub-Namespace for a
+   Flow Identity Extension for HELD to support this requirement.
+
+   This document updates RFC 6155 by deprecating the port number
+   elements specified therein.
+
+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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 1]
+
+RFC 6915                 Flow Identity for HELD               April 2013
+
+
+Copyright Notice
+
+   Copyright (c) 2013 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (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.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 2]
+
+RFC 6915                 Flow Identity for HELD               April 2013
+
+
+1.  Introduction
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   For implementation details not specified in this document, please
+   refer to [RFC6155] and [RFC5985].
+
+2.  Conventions Used in This Document
+
+   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].
+
+   The terms "Device" and "Target" are used as defined in [RFC6280].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 3]
+
+RFC 6915                 Flow Identity for HELD               April 2013
+
+
+3.  Usage
+
+   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>
+
+   The <flow> element MUST contain:
+
+   o  a "layer3" attribute with a value of "ipv4" or "ipv6".
+
+   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  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.
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 4]
+
+RFC 6915                 Flow Identity for HELD               April 2013
+
+
+4.  XML Schema
+
+   <?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: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>
+
+
+
+
+Bellis                       Standards Track                    [Page 5]
+
+RFC 6915                 Flow Identity for HELD               April 2013
+
+
+     <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.  IANA Considerations
+
+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].
+
+   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)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 6]
+
+RFC 6915                 Flow Identity for HELD               April 2013
+
+
+   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
+
+5.2.  XML Schema Registration
+
+   This section registers an XML Schema as per the guidelines in
+   [RFC3688].
+
+   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)
+
+   Schema: The XML for this schema can be found as the entirety of
+   Section 4 of this document.
+
+6.  Privacy Considerations
+
+   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.
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 7]
+
+RFC 6915                 Flow Identity for HELD               April 2013
+
+
+7.  Security Considerations
+
+   This document introduces no new security considerations beyond those
+   in [RFC6155].
+
+8.  Acknowledgements
+
+   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.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              January 2004.
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005.
+
+   [RFC5985]  Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC
+              5985, September 2010.
+
+   [RFC6155]  Winterbottom, J., Thomson, M., Tschofenig, H., and R.
+              Barnes, "Use of Device Identity in HTTP-Enabled Location
+              Delivery (HELD)", RFC 6155, March 2011.
+
+9.2.  Informative References
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              August 1980.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7, RFC
+              793, September 1981.
+
+   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
+
+   [RFC4960]  Stewart, R., "Stream Control Transmission Protocol", RFC
+              4960, September 2007.
+
+
+
+
+
+Bellis                       Standards Track                    [Page 8]
+
+RFC 6915                 Flow Identity for HELD               April 2013
+
+
+   [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.
+
+Author's Address
+
+   Ray Bellis
+   Nominet UK
+   Edmund Halley Road
+   Oxford  OX4 4DQ
+   United Kingdom
+
+   Phone: +44 1865 332211
+   EMail: ray.bellis@nominet.org.uk
+   URI:   http://www.nominet.org.uk/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Bellis                       Standards Track                    [Page 9]
+