GEOPRIV H. Schulzrinne Internet-Draft Columbia U. Intended status: Standards Track H. Tschofenig Expires: June 13, 2007 Siemens Networks GmbH & Co KG J. Morris CDT J. Cuellar Siemens J. Polk Cisco December 10, 2006 Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information draft-ietf-geopriv-policy-09.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on June 13, 2007. Copyright Notice Copyright (C) The IETF Trust (2006). Schulzrinne, et al. Expires June 13, 2007 [Page 1] Internet-Draft Geolocation Policy December 2006 Abstract This document defines an authorization policy language for controling access to location information. It extends the Common Policy authorization framework to provide location-specific access control. More specifically, this document defines condition elements specific to location information that allow to restrict access based on the current location of the Target. Furthermore, it offers location- specific transformation elements to reduce the granularity of the returned location information. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Basic Data Model and Processing . . . . . . . . . . . . . 7 3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 7 4. Location-specific Conditions . . . . . . . . . . . . . . . . . 8 4.1. Civic Location Condition . . . . . . . . . . . . . . . . . 8 4.2. Geospatial Location Condition . . . . . . . . . . . . . . 8 4.2.1. Polygon . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.2. Altitude . . . . . . . . . . . . . . . . . . . . . . . 9 5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Transformations . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. Set Retransmission-Allowed . . . . . . . . . . . . . . . . 11 6.2. Set Retention-Expires . . . . . . . . . . . . . . . . . . 11 6.3. Keep Ruleset Reference . . . . . . . . . . . . . . . . . . 11 6.4. Provide Location Information . . . . . . . . . . . . . . . 12 6.4.1. Provide Civic Location Information . . . . . . . . . . 12 6.4.2. Provide Geospatial Location Information . . . . . . . 13 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Rule Example with Civic Location Condition . . . . . . . . 15 7.2. Rule Example with Civic Transformations . . . . . . . . . 16 7.3. Rule Example with Geospatial Location Information . . . . 17 8. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 29 Schulzrinne, et al. Expires June 13, 2007 [Page 2] Internet-Draft Geolocation Policy December 2006 1. Introduction Location information needs to be protected against unauthorized access to preserve the privacy of the subject of the location information. In RFC 3693 [1], a protocol-independent model for access to geographic information is defined. The model includes a Location Generator (LG) that determines location information, a Location Server (LS) that authorizes access to location information, a Location Recipient (LR) that requests and receives information, and a Rulemaker (RM) that provides authorization policy rules. An authorization policy is a set of rules that regulates an entity's activities with respect to privacy-sensitive information such as location information. The data object containing location information is referred to as a Location Object (LO). The basic rule set defined in the Presence Information Data Format Location Object (PIDF-LO) [2] can restrict how long the Location Recipient is allowed to retain the information, and it can prohibit further distribution. It also contains a reference to an enhanced rule set and a human readable privacy policy. It does not allow to customize information to specific Location Recipients, for example. This document describes an enhanced rule set that provides richer constraints on the distribution of LOs. The rule set allows the entity that uses the rules defined in this document to restrict the retention and to enforce access restrictions on location data, including prohibiting any dissemination to particular individuals, during particular times or when the Target is located in a specific region. The RM can also stipulate that only certain parts of the Location Object are to be distributed to recipients or that the resolution of parts of the Location Object is limited. The sequence of operations is as follows. The Location Server receives a query for location information for a particular Target, via the using protocol [1]. The using protocol provides the identity of the requestor, either at the time of the query or when subscribing to the location information. The authenticated identity of the Location Recipient, together with other information provided by the using protocol or generally available to the server, is then used for searching through the rule set. If more than one rule matches the condition element, then the combined permission is evaluated according to the description in Section 10 of [3]. The combined permission is applied to the location information, yielding a possibly modified Location Object that is delivered to the Location Recipient. This document does not describe or mandate Schulzrinne, et al. Expires June 13, 2007 [Page 3] Internet-Draft Geolocation Policy December 2006 o the protocol used to convey location information from the Location Server to the Location Recipient (i.e., the using protocol; see RFC 3693 [1]), o the protocol to update authorization policies defined in this document, o the protocol used between the Location Generator and the Location Server to deliver location information. This document extends the Common Policy framework defined in [3]. That document provides an abstract framework for expressing authorization policy rules. As specified there, each such rule consists of conditions, actions and transformations. Conditions determine under which circumstances the entity executing the rules, for example a Location Server, is permitted to apply actions and transformations. Transformations regulate how a Location Server handles Location Objects; it might limit when and how data and policy can be distributed and may modify the information elements that are returned to the requestor, e.g., reducing the granularity of location information). The XML schema defined in Section 8 extends the Common Policy schema by introducing new child elements to the condition and transformation elements. This document does not define child elements for the action part of a rule. Schulzrinne, et al. Expires June 13, 2007 [Page 4] Internet-Draft Geolocation Policy December 2006 2. Terminology 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 [4]. This document reuses the terminology of RFC 3693 [1], such as Location Server (LS), Location Recipient (LR), Rule Maker (RM), Target, Location Generator (LG) and Location Object (LO). This document and the common policy document [3] share the following terminology: Presentity or Target: RFC 3693 [1] uses the term Target to identify the object or person of which location information is required. The presence model described in RFC 2778 [7] uses the term presentity to describe the entity that provides presence information to a presence service. In a presence system, the Target is the presentity. Watcher or Location Recipient: The receiver of location information is the Location Recipient (LR) in the terminology of RFC 3693 [1]. A watcher, i.e., an entity that requests presence information about a presentity, is a Location Recipient in presence systems. Authorization policy: An authorization policy is given by a rule set. A rule set contains an unordered list of rules. A rule has a conditions, an actions and a transformations part. Permission: The term permission indicates the action and transformation components of a rule. The terms 'authorization policy', 'policy' and 'rule set' are used interchangeable. The terms 'authorization policy rule', 'policy rule' and 'rule' are used interchangeable. The term 'using protocol' is defined in [1] and refers to the protocol that is used to request access to and to return privacy sensitive data items. Schulzrinne, et al. Expires June 13, 2007 [Page 5] Internet-Draft Geolocation Policy December 2006 Note that this document often points to Location Servers as the entities that evaluate the authorization policies described in this document. The Geopriv location privacy architecture is, as motivated in RFC 4079 [8], aligned with the presence architecture and hence one might see a Presence Server as an entity that distributes location information along many other XML data elements. Schulzrinne, et al. Expires June 13, 2007 [Page 6] Internet-Draft Geolocation Policy December 2006 3. Generic Processing 3.1. Basic Data Model and Processing Since this document is an extension of the Common Policy framework defined in [3], it inherits its basic data model and processing. 3.2. Rule Transport There are two ways how the authorization rules described in this document may be conveyed between different parties: o RFC 4119 [2] allows enhanced authorization policies to be referenced via a Uniform Resource Locator (URL) in the 'ruleset- reference' element. The ruleset-reference' element is part of the basic rules that always travel with the Location Object. o Authorization policies might, for example, also be stored at a Location Server or at a Presence Server. The Rule Maker therefore needs to use a protocol to create, modify and delete the authorization policies defined in this document. Such a protocol is available with the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [9]. Schulzrinne, et al. Expires June 13, 2007 [Page 7] Internet-Draft Geolocation Policy December 2006 4. Location-specific Conditions This section describes the location-specific conditions in a rule, namely the civic and geospatial location conditions. The elements and are child elements of the element. The evaluates to TRUE if any of its child elements is TRUE, i.e., a logical OR. The XML elements and attributes shown below are defined by the XML schema in Section 8. 4.1. Civic Location Condition The element matches if the current location of the Target matches all the values specified in the child elements of this element. The is of the 'civicAddress' complex type defined in [5]. All child elements of element MUST evaluate to TRUE (i.e., logical AND) in order for the element to evaluate to TRUE. If the civic location of the Target is not known, then the child elements of element will evaluate to FALSE and the civic location condition evaluates to FALSE. This case may occur, for example, if location information has been removed by earlier transmitters of location information or if only the geospatial location is known. 4.2. Geospatial Location Condition The geospatial location condition allows to make authorization decisions based on the current geospatial location of the Target. The geospatial location condition matches if the current location of the Target is contained in either the identified polygon (see Section 4.2.1) or between a range of altitude values (see Section 4.2.2). If the geospatial location of the Target is not known, the geospatial location condition evaluates to FALSE. 4.2.1. Polygon The condition matches if the longitude and latitude values of the polygon, interpreted as x and y coordinates on a plane, enclose the current location of the target. There are a number of algorithms for determining whether a point is inside a polygon. A common algorithm draws a ray from the test point to the right. The test point is inside if and only if the ray intersects the line segments making up the polygon an odd number of times. The listed points, which constitute the polygon, MUST be listed as Schulzrinne, et al. Expires June 13, 2007 [Page 8] Internet-Draft Geolocation Policy December 2006 they appear in a clockwise direction all the way around the perimeter of the single plane shape. This is the defined concept of a "Ring" within GML [10]. The final point MUST be a repeat of the first point listed to enclose the polygon. 4.2.2. Altitude The altitude condition matches if the Target altitude is defined and falls between the low and high altitude stated in the rule, measured in meters above the WGS84 sphere. If either element is omitted, the altitude range is an open range. Schulzrinne, et al. Expires June 13, 2007 [Page 9] Internet-Draft Geolocation Policy December 2006 5. Actions This document does not define location-specific actions. Schulzrinne, et al. Expires June 13, 2007 [Page 10] Internet-Draft Geolocation Policy December 2006 6. Transformations This document defines several elements that allow Rule Makers to specify transformations to limit the accuracy of the Location Object passed to the Location Recipient. 6.1. Set Retransmission-Allowed This element ask the LS to change the value of the 'retransmission- allowed' element in the PIDF-LO. The data type of the element is Boolean. If the value of the element is set to TRUE then the 'retransmission-allowed' element in the PIDF-LO has be set to TRUE. If the value of the element is set to FALSE, then the 'retransmission-allowed' element in the PIDF-LO has to be set to FALSE. If the element is absent, then the value of the 'retransmission-allowed' element in the PIDF-LO is kept unchanged or, if the PIDF-LO is created for the first time, then the value is set to FALSE. 6.2. Set Retention-Expires This transformation asks the LS to change the value of the 'retention-expires' element in the PIDF-LO. The data type of the element is Integer. The value provided with the element indicates seconds and these seconds are added to the current date. If the element is absent, then the value of the 'retention-expires' element in the PIDF-LO is kept unchanged or, if the PIDF-LO is created for the first time, then the value is set to 0, i.e., immediate expiry. 6.3. Keep Ruleset Reference This transformation allows to influence whether the 'ruleset- reference' element in the PIDF-LO carries the extended authorization rules defined in [3]. The data type of the element is Integer. If the value of the element is set to TRUE, then the the 'ruleset-reference' element in the PIDF-LO is set to TRUE. If the value of the element is set to FALSE, then the 'ruleset-reference' element in the PIDF-LO MUST NOT Schulzrinne, et al. Expires June 13, 2007 [Page 11] Internet-Draft Geolocation Policy December 2006 contain a reference. The reference to the ruleset is removed and no rules are carried as MIME bodies (in case of CID URIs). If the element is absent, then the value of the 'ruleset-reference' element in the PIDF-LO is kept unchanged or, if the PIDF-LO is created for the first time, then the 'ruleset- reference' element MUST NOT contain a reference. 6.4. Provide Location Information The element contains the and the child elements that control the granularity of location information being made available. If the element is provided without child elements then civic as well as geospatial location information is provided without reducing its granularity, subject to availability. 6.4.1. Provide Civic Location Information The civic location transformation can be specified by means of the element to restrict the level of civic location information the LS is permitted to provide. The symbols of these levels are: 'country', 'region', 'city', 'building', 'full'. Each level is given by a set of civic location data items such as and , ..., , as defined in [5]. Each level includes all elements included by the lower levels. The 'country' level includes only the element; the 'region' level adds the element; the 'city' level adds the and elements; the 'building' level and the 'full' level add further civic location data as shown below: Schulzrinne, et al. Expires June 13, 2007 [Page 12] Internet-Draft Geolocation Policy December 2006 full {, , , , , , , , , , , , , , , , , ,,,, , , , , , , , } | | building {, , , , , , , , , , , , , , , , , , } | | city {, , } | | region {, } | | country {} | | { } If the element is absent, then civic location information MUST NOT be disclosed. 6.4.2. Provide Geospatial Location Information The geospatial location transformation can be specified by means of the element to restrict the resolution of the geospatial location information to the value provided in the , and child elements of the element. The resolution is specified as a positive, non-zero number r. If n is the nominal coordinate value (longitude or latitude), the rounded value is computed as floor(n/r + 0.5) * r. For example, if the latitude is n=38.89868 and r=0.01, the latitude value rendered to the recipient of the Location Object is 38.90. If the longitude is n=77.03723 and r=0.01, the longitude is rendered as 77.04. This computation also works for r that are not integer powers of 10 or r > 1. For example, to round longitude to timezone Schulzrinne, et al. Expires June 13, 2007 [Page 13] Internet-Draft Geolocation Policy December 2006 accuracy, one would use r=15 and obtain a value of 75 in this example. If the element is absent, then geospatial location information MUST NOT be disclosed. Schulzrinne, et al. Expires June 13, 2007 [Page 14] Internet-Draft Geolocation Policy December 2006 7. Examples This section provides three examples for authorization policy rules using the extensions defined in this document. 7.1. Rule Example with Civic Location Condition This example illustrates a single rule that employs the civic location condition which matches if the current location of the Target is inside the area specified by the child elements of the element. In this example, requests match only if the Target is at a civic location with country set to 'Germany', state (A1) set to 'Bavaria', city (A3) set to 'Munich', city division (A4) set to 'Perlach', street name (A6) set to 'Otto-Hahn-Ring' and house number (HNO) set to '6'. The rule is valid for one year as specified by the element. No actions and transformation child elements are provided in this rule example. In a real-world example, the actions and transformation could include presence specific information when the Geolocation Policy framework is applied to the Presence Policy framework (see [11]). Schulzrinne, et al. Expires June 13, 2007 [Page 15] Internet-Draft Geolocation Policy December 2006 2004-11-01T00:00:00+01:00 2005-11-01T00:00:00+01:00 DE Bavaria Munich Perlach Otto-Hahn-Ring 6 7.2. Rule Example with Civic Transformations This example contains a rule with an identity, a validity and a sphere condition. Location specific transformations set elements in the basic rules of the PIDF-LO, regarding retransmission, retention and the ruleset reference. The element indicates that the available civic location information is reduced to building level granularity. Schulzrinne, et al. Expires June 13, 2007 [Page 16] Internet-Draft Geolocation Policy December 2006 2003-12-24T17:00:00+01:00 2003-12-24T19:00:00+01:00 false 86400 false building 7.3. Rule Example with Geospatial Location Information This example illustrates a rule that employs the geospatial location condition. The rule matches if the current location of the Target is inside the area specified by the child elements of the element. The individual points of the polygon have to be interpreted as points of the WGS-84 coordinate reference system, as specified by the value of the 'crsName' attribute of the element. This coordinate reference systems is also used by GPS. The given four points specify a quadrangle on the surface of the rotational ellipoid being part of the WGS-84 system, corresponding to a certain area in Washington, DC, USA. The transformation part of the example rule allows the Location Server to distribute Location Objects with the ruleset reference removed. The Location Server is permitted to retain the Location Objects related to the Target for at most one day. They are allowed to provide civic location information about the Target at building level of precision, and geospatial location information at roughly Schulzrinne, et al. Expires June 13, 2007 [Page 17] Internet-Draft Geolocation Policy December 2006 the first decimal of precision. 2004-11-01T00:00:00+01:00 2005-11-01T00:00:00+01:00 38.8986 -77.03724 38.8986 -77.03722 38.8987 -77.03722 38.8987 -77.03724 true 86400 Schulzrinne, et al. Expires June 13, 2007 [Page 18] Internet-Draft Geolocation Policy December 2006 false building 0.3 0.2 The next ruleset indicates that the Target has to be at an altitude between 1500 and 4000 meters in order for this rule to match. 1500.0 4000.0 Schulzrinne, et al. Expires June 13, 2007 [Page 19] Internet-Draft Geolocation Policy December 2006 8. XML Schema This section presents the XML schema that defines the Geolocation Policy schema described in the previous sections. The Geolocation Policy schema extends the Common Policy schema (see [3]) by introducing new members of the 'condition' and 'transformation' substitution groups whose heads (namely the elements and ). To express civic location conditions, it imports the 'civicAddress' complex type as defined in [5]. Schulzrinne, et al. Expires June 13, 2007 [Page 20] Internet-Draft Geolocation Policy December 2006 Schulzrinne, et al. Expires June 13, 2007 [Page 21] Internet-Draft Geolocation Policy December 2006 Schulzrinne, et al. Expires June 13, 2007 [Page 22] Internet-Draft Geolocation Policy December 2006 9. Security Considerations This document aims to make it simple for users to prevent the unintended disclosure of private information to third parties. Security threats are described in [6] and are applicable to this draft as well. Security requirements are addressed in [1]. Aspects of combining permissions in cases of multiple occurrence are treated in [3]). How the behavior of Location Servers can be regulated in terms of Location Object handling in a privacy-safe fashion is specified in Section 6. Schulzrinne, et al. Expires June 13, 2007 [Page 23] Internet-Draft Geolocation Policy December 2006 10. References 10.1. Normative References [1] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004. [2] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [3] Schulzrinne, H., "Common Policy: A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-11 (work in progress), August 2006. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. [5] Thomson, M. and J. Winterbottom, "Revised Civic Location Format for PIDF-LO", draft-ietf-geopriv-revised-civic-lo-04 (work in progress), September 2006. [6] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004. 10.2. Informative References [7] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000. [8] Peterson, J., "A Presence Architecture for the Distribution of GEOPRIV Location Objects", RFC 4079, July 2005. [9] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-12 (work in progress), October 2006. [10] OpenGIS, "OpenGIS Geography Markup Language (GML) Implementation Specification, Version 3.00, OGC 02 023r4", http://www.opengeospatial.org/docs/02-023r4.pdf, January 2003. [11] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-08 (work in progress), October 2006. [12] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004. Schulzrinne, et al. Expires June 13, 2007 [Page 24] Internet-Draft Geolocation Policy December 2006 Appendix A. Contributors We would like to thank Christian Guenther for his help with an earlier version of this document. Schulzrinne, et al. Expires June 13, 2007 [Page 25] Internet-Draft Geolocation Policy December 2006 Appendix B. Acknowledgments This document is informed by the discussions within the IETF GEOPRIV working group, including discussions at the GEOPRIV interim meeting in Washington, D.C., in 2003. We particularly want to thank Allison Mankin , Randall Gellens , Andrew Newton , Ted Hardie , Jon Peterson for their help in improving the quality of this document. We would like to thank Johnny Vrancken for his review and the suggestions he provided in September 2006. James Winterbottom provided a review in November 2006. Schulzrinne, et al. Expires June 13, 2007 [Page 26] Internet-Draft Geolocation Policy December 2006 Authors' Addresses Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA Phone: +1 212 939 7042 Email: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA Email: jmorris@cdt.org URI: http://www.cdt.org Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Jorge.Cuellar@siemens.com Schulzrinne, et al. Expires June 13, 2007 [Page 27] Internet-Draft Geolocation Policy December 2006 James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA Email: jmpolk@cisco.com Schulzrinne, et al. Expires June 13, 2007 [Page 28] Internet-Draft Geolocation Policy December 2006 Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Schulzrinne, et al. Expires June 13, 2007 [Page 29]