[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 RFC 6772

GEOPRIV                                                   H. Schulzrinne
Internet-Draft                                               Columbia U.
Expires: April 24, 2005                                        J. Morris
                                                                     CDT
                                                           H. Tschofenig
                                                              J. Cuellar
                                                                 Siemens
                                                                 J. Polk
                                                                   Cisco
                                                        October 24, 2004


   A Document Format for Expressing Privacy Preferences for Location
                              Information
                      draft-ietf-geopriv-policy-04

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  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 become aware will be disclosed, in accordance with
   RFC 3668.

   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 April 24, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract




Schulzrinne, et al.      Expires April 24, 2005                 [Page 1]

Internet-Draft               Geopriv Policy                 October 2004


   This document defines an authorization policy language for controling
   access to location information.  It extends the authorization
   framework of the common policy markup language towards
   location-specific access control needs.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Basic Data Model and Processing  . . . . . . . . . . . . . . .  6
   4.  Rule Transport . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1   HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.2   SIP Message Body . . . . . . . . . . . . . . . . . . . . .  7
   5.  Securing the Location Object . . . . . . . . . . . . . . . . .  9
   6.  Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.1   Civil Location Condition . . . . . . . . . . . . . . . . . 10
     6.2   Geospatial Location Condition  . . . . . . . . . . . . . . 10
   7.  Actions  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  Transformations  . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1   Distribution Transformation  . . . . . . . . . . . . . . . 15
     8.2   Retention Transformation . . . . . . . . . . . . . . . . . 15
     8.3   Keep Rules Transformation  . . . . . . . . . . . . . . . . 16
     8.4   Timezone Transformation  . . . . . . . . . . . . . . . . . 16
     8.5   Civil Location Transformation  . . . . . . . . . . . . . . 17
     8.6   Geospatial Location Transformation . . . . . . . . . . . . 18
   9.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     9.1   Rule Example with Civil Location Condition . . . . . . . . 20
     9.2   Rule Example with Geospatial Location Information  . . . . 21
   10.   XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . 24
   11.   Security Considerations  . . . . . . . . . . . . . . . . . . 27
   12.   Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . 28
   13.   References . . . . . . . . . . . . . . . . . . . . . . . . . 29
   13.1  Normative References . . . . . . . . . . . . . . . . . . . . 29
   13.2  Informative References . . . . . . . . . . . . . . . . . . . 29
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30
   A.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
   B.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 33
       Intellectual Property and Copyright Statements . . . . . . . . 34













Schulzrinne, et al.      Expires April 24, 2005                 [Page 2]

Internet-Draft               Geopriv Policy                 October 2004


1.  Introduction

   Location information needs to be protected against unauthorized
   access to preserve the privacy of the owner of the location
   information.  In [RFC3693], a protocol-independent model for access
   to geographic information was defined.  The model includes a Location
   Generator (LG) that produces Location Information (LI), a Location
   Server (LS) that authorizes access to LI, 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 regulate an entity's activities with respect to
   privacy-sensitive information such as location information.  The data
   object containing LI is referred to as Location Object (LO).

   Two namespaces have been defined by means of which authorization
   policies governing access to LI can be formulated: first, the basic
   rule set defined in [I-D.ietf-geopriv-pidf-lo] can restrict how long
   the receiver can retain the information and it can prohibit any
   further distribution of the information.  It does not allow to
   customize information to specific receivers, for example.  Second,
   this document describes an enhanced rule set that provides richer
   constraints on the distribution of LOs.

   We refer to any entity that uses the rules in this document to
   restrict the retention or distribution of information as a Rule
   Enforcer (RE).  The rule set allows the RE to enforce access
   restrictions on location data, including prohibiting any
   dissemination to particular individuals or during particular times.
   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 can be described as follows.  The LS
   receives a query for location information of a particular Target, via
   the using protocol.  The using protocol provides the identity of the
   requestor, either at the time of the query or subscription to the
   location information.  The authenticated identity of the LR, together
   with other information provided by the using protocol or generally
   available to the server, is then used for searching through the rule
   set.  All matching rules are combined according to a merging
   algorithm described in [I-D.ietf-geopriv-common-policy].  The
   resulting rule is applied to the location data, yielding a possibly
   modified location object that is delivered to the location recipient.

   The protocols used to query location information (between LS and LR),
   to update authorization policies at the LS and the protocol between
   LG and LS and from LS to LR do not have to be the same.  This
   document does not mandate a specific protocol for any of them.



Schulzrinne, et al.      Expires April 24, 2005                 [Page 3]

Internet-Draft               Geopriv Policy                 October 2004


   This document extends the framework defined in
   [I-D.ietf-geopriv-common-policy].  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 LS is permitted to perform 'actions' and 'transformations'.
   'Transformations' implement a mechanism to regulate LSs' handling of
   LOs in terms of data retention as well as data and policy
   distribution, and to modify information elements returned to the
   requestor (e.g., to reduce the granularity of location information).

   The XML schema in Section 10 extends the XML-based authorization
   framework (see [I-D.ietf-geopriv-common-policy]) by introducing new
   members of the 'condition' and 'transformation' substitution groups
   defined there.  The schema does not define new types of 'actions'.
   To express civil location information, it makes use of that schema in
   [I-D.ietf-geopriv-pidf-lo] that defines the 'civilAddress' complex
   type.

































Schulzrinne, et al.      Expires April 24, 2005                 [Page 4]

Internet-Draft               Geopriv Policy                 October 2004


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 [RFC2119].

   This document reuses the terminology of [RFC3693], e.g., the terms
   Location Server (LS) and Location Recipient (LR).  We subsequently
   refer to the terminology used in [RFC3693] as Geopriv.  This document
   and [I-D.ietf-geopriv-common-policy] share the following terminology:

   PT - Presentity / Target: Geopriv uses the term Target to identify
      the object or person of which location information is required.

   RM - Rule Maker: The entity RM corresponds to the Geopriv Rulemaker.

   PS - (Authorization) Policy Server: The PS corresponds to the
      Location Server (LS) in the Geopriv terminology.

   WR - Watcher / Recipient: The WR represents the Location Recipient
      (LR) in the Geopriv terminology.

   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 [RFC3693].  It refers to the
   protocol which is used to request access to and to return privacy
   sensitive data items.

   The Geopriv policy markup language refers to the authorization
   language defined in this document.  The Common policy markup language
   refers to the authorization language described in
   [I-D.ietf-geopriv-common-policy].







Schulzrinne, et al.      Expires April 24, 2005                 [Page 5]

Internet-Draft               Geopriv Policy                 October 2004


3.  Basic Data Model and Processing

   As the Geopriv policy markup language defined in Section 10 extends
   the Common policy markup language in
   [I-D.ietf-geopriv-common-policy], this document adopts the basic data
   model as introduced in Section 6 of [I-D.ietf-geopriv-common-policy].













































Schulzrinne, et al.      Expires April 24, 2005                 [Page 6]

Internet-Draft               Geopriv Policy                 October 2004


4.  Rule Transport

   The XML data format of the Geopriv LO is specified in
   [I-D.ietf-geopriv-pidf-lo].  The definition of the LO there allows
   the authorization policy associated to the LO to be carried in two
   different ways: by value or by reference.  To make use of the first
   possibility, an authorization policy as specified by this document
   can be integrated directly into the XML representation of the LO.
   For the second alternative, the LO data format definition in
   [I-D.ietf-geopriv-pidf-lo] provides the optional 'ruleset-reference'
   element which contains an URI that indicates where a rule set related
   to the LO can be found.

   One of the transformations of the rule set is the removal of the rule
   set described here before transmission.  Only the whole rule set can
   be removed and not individual elements (for example, some
   conditions).  Before transmitting the rules to the LR, unless
   explicitly permitted by the authorization policy, the rule set MUST
   be removed from the LO, since the rule set might disclose which
   entities the RM trusts (see Section 8).

   Transaction semantics for authorization policy rule updates are not
   required since 'permit only' and 'additive permissions' properties
   have to be used.  These properties also prevent inconsistency during
   concurrent query and update operations.

   We make no assumption as to how rules are conveyed to entities within
   the network.  Purely as examples, we below describe a few plausible
   options.  None of the rule elements depend on the properties of how
   rule sets are conveyed to an LS or LR.  Mechanisms may allow partial
   updates of rule sets.  A partial update is an update which modifies
   only parts of the rule set in contrast to a full update.  To simplify
   such partial updates, each rule is labelled with an identifier (see
   [I-D.ietf-geopriv-common-policy]).

4.1  HTTP

   A rule set could be uploaded to the LS via an HTTP POST operation or
   WEBDAV operation [RFC2518].  Each rule could be modeled as a single
   file, with the rule identifier as a file name.  One example of this
   approach is XCAP [I-D.ietf-simple-xcap], the XML Configuration Access
   Protocol.  Since multiple rules may have the same LR identity in the
   condition part of the rule, the LR identity cannot be used as file
   name.

4.2  SIP Message Body

   The rule set can be carried, as a separate MIME message body, in the



Schulzrinne, et al.      Expires April 24, 2005                 [Page 7]

Internet-Draft               Geopriv Policy                 October 2004


   SIP message that conveys location information from a LG (a SIP UAC)
   via an LS (a SIP proxy) to an LR (a SIP UAS).  The rule set would
   then govern the behavior expected of the LR.
















































Schulzrinne, et al.      Expires April 24, 2005                 [Page 8]

Internet-Draft               Geopriv Policy                 October 2004


5.  Securing the Location Object

   The Geopriv requirements document [RFC3693] addresses the minimal
   security protection required for the LO: Mutual end-point
   authentication, data object integrity, data object confidentiality
   and replay protection.  As proposed in [I-D.ietf-geopriv-pidf-lo],
   S/MIME SHOULD be used.  Protection for the LO also includes an
   attached rule set.

   Protection is likely to be necessary against adversaries who
   eavesdrop on the communication between the LS and the LR or the LG
   and the LS, who tamper with the LO or who replay previously recorded
   LOs.  Securing the communication between RM and LS depends on the
   protocol which is used to perform the desired actions (e.g., https).
   The communication between the LG and the LS can also be secured using
   channel security.

   If the LO is integrity and confidentiality-protected, then the
   receiving entity (LS or LR) has to be able to decrypt and to verify
   the LO.  Since the authorization policy rules described in this
   document allow the modification of the LO (via granularity reduction
   or by setting flags), it is not possible to forward the LO without
   reapplying the cryptographic protection.  This is particularly true
   for the LS as it is not the final consumer of the LO.

   When the LS protects the LO for transmission to the LR (after
   successful authorization), then the authenticated identity can be
   used to select a security association to apply proper protection of
   the location object.  Securing the LO for multiple LRs is not
   provided.

   Instead of encrypting the LO, the LG could digitally sign the LO,
   offering integrity, but no confidentiality.  However, if the LS needs
   to perform modifications on the LO, then it would have to break the
   digital signature and may apply its own digital signature.

   Since the LO is generally distributed to more than one LR, the LG
   lacks the necessary information about the recipient and thus cannot
   usually apply confidentially protection.

   By default, the LS re-signs LOs if the signed LO has been modified
   according to the rule set.  If the LS receives an LO that it cannot
   decrypt, it discards it if and only if the rule requires modification
   of the content.

   It remains for further study whether there should be an action that
   discards an LO that is signed or encrypted and needs to be modified
   according to the matching rule set.



Schulzrinne, et al.      Expires April 24, 2005                 [Page 9]

Internet-Draft               Geopriv Policy                 October 2004


6.  Conditions

   This section describes the location-specific conditions of a rule,
   namely the civil and geo-spatial location conditions.  The XML
   elements and attributes quoted subsequently are defined by the
   Geopriv policy markup languge whose corresponding XML schema can be
   found in Section 10.

6.1  Civil Location Condition

   The <civil-loc-condition> element matches if the current location of
   the target matches all the values specified in the child elements of
   this element.  The <civil-loc-condition> is of the 'civilAddress'
   complex type defined in [I-D.ietf-geopriv-pidf-lo].  It includes a
   number of fields, including the country (expressed as a two-letter
   ISO 3166 code), and the administrative units A1 through A6 of
   [I-D.ietf-geopriv-dhcp-civil].  This designation offers street-level
   precision.

   If the civil location of the target is not known, rules that contain
   a civil location condition never match.  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.

   If any of the elements <A1> through <A6> are specified, <country>
   MUST also be specified.  The schema does not enforce that the
   specification uniquely identifies a particular location.  For
   example, it would be possible to omit the region and match only on
   city name, so that any city sharing that name within a country would
   match.  This feature is primarily designed to deal with users that
   may not know the administrative divisions between country and city
   level.  For example, many users may not know the county for cities in
   the United States.

6.2  Geospatial Location Condition

   In addition to the civil location condition, this specification also
   introduces a geospatial location condition.  Intuitively spoken, a
   geospatial location condition determines a spatial area by means of
   points of a given coordinate reference system (CRS), and it matches
   if the current location of the Target is contained in that area.  For
   example, as depicted in Figure 1, the geospatial location condition
   can be used to specify a quadrangle on the surface of a rotational
   ellipsoid approximating the surface of the earth.  Then, such a
   condition matches if the projection of the current location of the
   target on the surface of the ellipsoid is contained in the polygon.
   The projection is along the normal to the ellipsoid that goes through



Schulzrinne, et al.      Expires April 24, 2005                [Page 10]

Internet-Draft               Geopriv Policy                 October 2004


   the Target's current position.


             point 4                 point 3
                +-----------------------+
               /                         \
              /                           \    x = point in 3-dim space
             /                             \
            /     x Target's location       \  + = points on the
           /      | in space,                \     surface of the
          /       |                           \    ellipsoid
         /        | projected on the surface   \
        /         | of the ellipsoid along      \
       /          + surface normal               \
      /                                           \
     +---------------------------------------------+
   point 1                                       point 2

       Figure 1: Polygon used by a Geospatial Location Condition

   In what follows, the intuitive description of the geospatial location
   condition shall be made explicit.

   The geopriv policy markup language defines the
   <geospatial-loc-condition> element to support conditions that are
   formulated by means of points of a given CRS.  As child elements of
   <geospatial-loc-condition>, the geopriv policy schema allows of any
   element outside its own namespace, but the schema also defines the
   <polygon> child element explicitly.  This can be used in conjunction
   with spatial ellipsoidal CRSs, as used, for instance, by the World
   Geodetic System 1984 (WGS-84) and hence by the Global Positioning
   System (GPS).

   This document will go into details exclusively for spatial
   ellipsoidal CRSs.  Geospatial location conditions using other CRSs
   may either reuse the <polygon> element if appropriate or replace the
   <any> child element of <geospatial-loc-condition> if the <polygon>
   element does not suit.  In either case, the CRS employed MUST be
   indicated by the immediate child element of
   <geospatial-loc-condition>.  For the <polygon> child element of
   <geospatial-loc-condition>, this is accomplished by the attribute
   'crsName' whose value is an URI specifying the CRS employed.  For the
   WGS-84 system, this URI MUST be

      urn:ietf:params:xml:ns:geopriv-policy:crs:wgs84

   Subsequently, geospatial location conditions will be specified that
   make use of the <polygon> element in conjunction with spatial



Schulzrinne, et al.      Expires April 24, 2005                [Page 11]

Internet-Draft               Geopriv Policy                 October 2004


   ellipsoidal CRSs.  Before, the meaning of the term 'height' (or
   'altitude') in such a system shall be illustrated, but also the
   meaning of 'longitude' and 'latitude', as a clear imagination of them
   is necessary to comprehend the way in which the <polygon> is to
   interpret.

   A spatial ellipsoidal CRS in the sense of this document features a
   rotational ellipsoid whose surface approximates the surface of the
   earth.  It possesses three coordinates called 'longitude', 'latitude'
   and 'height'.  Such a CRS is given by two values, namely, the length
   a of the so-called semimajor axis and the length b of the so-called
   semiminor axis.  Typically, the value of b is set to be slightly
   smaller than that of a in order to comply with the earth's
   oblateness.  Therefore, b is assumed to be smaller than a henceforth
   in this section.  In the WSG-84 model, the length a of the semimajor
   axis is set to be 6,378.137 km, while the semiminor axis is taken to
   be 6,356.7523142 km of length.  If e is the ellipse whose two
   diameters d1 and d2 have lengths 2a and 2b, respectively, then the
   rotational ellipsoid E is given by rotating e around the smaller
   diameter d2.  The intersection point O of d1 and d2 represents the
   earth's center of mass.  The point O is the origin of the model.

   The plane that contains O and that is mapped by that rotation onto
   itself is referred to as the equatorial plane of E.  It models the
   equatorial plane of the earth.  Each plane that is normal to the
   equatorial plane of E and that contains the semiminor axis is
   referred to as a meridian plane.  One of these meridians is taken to
   be the zero meridian plane.

   Let P be a point on the surface of E.  The normal to the surface S of
   E going through P is referred to as the surface normal of P.  The
   angle measured in the meridian plane containing P between the
   equatorial plane and the surface normal of P is called the latitude
   of P.  The angle measured in the equatorial plane between the zero
   meridian plane and the meridian plane containing P is called the
   longitude of P.

   More generally, consider the rotational ellipsoid E as embedded into
   the three-dimensional space, and let P be any point of this space.
   Let P' be the projection of P on the surface of E along the surface
   normal that goes through P.  Then, the latitude and longitude of P
   are taken to be those of P'.  Furthermore, the height of P is the
   minimal distance between P and the surface of E.  In other words, the
   height of P is the distance between P and the surface of the
   rotational ellipsoid E measured along the normal to the surface of E
   that goes through P.  In particular, this type of height does not
   always coincide with the height measured with respect to a given sea
   level.



Schulzrinne, et al.      Expires April 24, 2005                [Page 12]

Internet-Draft               Geopriv Policy                 October 2004


   After these illustrating remarks, the usage and interpretation of the
   <polygon> child element of the <geospatial-loc-condition> element
   with respect to a spatial ellipsoidal CRS shall be specified.  The
   <polygon> element consists of three or more <point> elements.  The
   XML schema defines the <point> element in such a way that its child
   elements <lat> and <lon> are mandatory while its child element <alt>
   is optional.  Additionally, this specification requires that either
   each <point> within a <polygon> element has an <alt> child element or
   none of them.

   If the sequence of <point> elements within a <polygon> element does
   not contain any <alt> element, the values of the <lat> and <lon>
   child elements of the single <point> elements are to be interpreted
   as follows: they define the latitude and longitude values of the
   vertices of a polygon on the surface S of the rotational ellipsoid E
   that belongs to the CRS specified by the 'crsName' attribute of the
   <polygon> element.  The edges of this polygon are given by the
   following paths in S: by that path in S that has the minimal length
   among all paths in S connecting the first and the second point, by
   that path that has the corresponding minimality property with respect
   to the second and third point in the sequence, and so on, ranging to
   that path in S that has the minimal length among all paths connecting
   the last point and the first one.  In this case (i.e., if no <alt>
   elements are provided), the geospatial location condition matches if
   and only if the projection P' of the current location P of the target
   on the surface of E along the surface normal through P is contained
   in the two-dimensional polygon as defined before.

   If, on the other hand, all <point> elements within a <polygon>
   element contain an <alt> element, then the number of <point> elements
   MUST be even.  These <point> elements are then to be interpreted as
   follows: The values of the <lat>, <lon> and <alt> child elements of
   the respective <point> elements define a sequence of points
   P_1=(lat_1,lon_1,alt_1), ..., P_n=(lat_n,lon_n,alt_n) of the
   three-dimensional space.  These points specify a polygon whose n/2
   many edges are the connections between P_1 and P_2, P_3 and P_4, ...,
   P_{n-1} and P_n, respectively.  The geospatial location condition
   matches if and only if the current location P of the target is
   contained in that polygon.  Implementors of this specification MUST
   ensure that the sequence of <point> elements actually defines a
   polygon in the three-dimensional space for which it is possible to
   decide whether a given location is contained in or outside that area.









Schulzrinne, et al.      Expires April 24, 2005                [Page 13]

Internet-Draft               Geopriv Policy                 October 2004


7.  Actions

   According to the common policy framework
   [I-D.ietf-geopriv-common-policy], actions and transformations
   included in a rule determine which operations the LS MUST execute
   after having received from a LR a location data access request that
   matches all conditions of this rule.  Transformations regulate the
   LS-side operations that directly influence the handling of location
   information.  Actions, on the other hand, specify all remaining types
   of operations the LS is obliged to execute, i.e., all operations that
   are not of transformation type.  This document does not define new,
   location-specific actions.







































Schulzrinne, et al.      Expires April 24, 2005                [Page 14]

Internet-Draft               Geopriv Policy                 October 2004


8.  Transformations

   The Geopriv policy markup language defines several elements by means
   of which Rulemakers can specify transformations.  For example, these
   transformations regulate the LS-side behavior in terms of how long a
   LS is permitted to store a given LO, whether the LO may be
   distributed or not, and at which level of accuracy the LS is allowed
   to pass location information on.

   All transformations defined in this section are privacy-safe in the
   sense that, if the evaluation of the authorization policy related to
   a given LO does not produce an explicit transformation instruction,
   the LS MUST execute the transformation in question at the highest
   level of privacy protection.

   Extensions to this document may define other transformations.

8.1  Distribution Transformation

   This transformation can be specified by means of the
   <distribution-transformation> element whose value is of boolean type.
   With respect to a given LO, a LS is allowed to distribute this LO, if
   and only if all of the following preconditions are satisfied:

   1) the authorization policy related to the LO contains a rule with a
      <distribution-transformation> element,

   2) at least one of the rules safisfying 1) matches, and

   3) the combined value of this permission is 'true' (see
      [I-D.ietf-geopriv-common-policy] for the term 'combined value').

   In all other cases, the LS MUST NOT distribute the LO in question.
   In particular, this also comprises the case of an authorization
   policy that does not contain a rule with a
   <distribution-transformation> element.

8.2  Retention Transformation

   This transformation can be specified by means of the
   <retention-transformation> element whose value is of integer type.
   With respect to a given LO, a LS is allowed to retain this LO for at
   most t>0 seconds after reception of the LO, if and only if all of the
   following preconditions are satisfied:







Schulzrinne, et al.      Expires April 24, 2005                [Page 15]

Internet-Draft               Geopriv Policy                 October 2004


   1) the authorization policy related to the LO contains a rule with a
      <retention-transformation> element,

   2) at least one of the rules satisfying 1) matches, and

   3) the combined value of this permission is t.

   In all other cases, the LS MUST delete the LO immediately upon the
   LS-side completion of the service that makes use of the LO.  In
   particular, this also comprises the case of an authorization policy
   that does not contain a rule with a <retention-transformation>
   element, and the case in which a matching rule contains this element
   but its combined value is less than or equal to 0.

8.3  Keep Rules Transformation

   This transformation can be specified by means of the
   <keep-rules-transformation> element whose value is of boolean type.
   With respect to a given LO, a LS is allowed to keep all authorization
   policy rules in the LO when passing this LO on, if and only if all of
   the following preconditions are satisfied:

   1) the authorization policy related to the LO contains a rule with a
      <keep-rules-transformation> element,

   2) at least one of the rules satisfying 1) matches, and

   3) the combined value of this permission is 'true'.

   In all other cases, the LS MUST remove all authorization policy rules
   from the LO.  In case of rules stated explicitly ('by value') inside
   the LO, this means to completely remove the rules from the LO; in
   case of a pointer to an authorization policy rule ('by reference')
   inside the LO, this means to remove the pointer from the LO.  See
   Section 4 for the different ways of attaching authorization policy
   rules to LOs.

8.4  Timezone Transformation

   This transformation can be specified by means of the
   <timezone-transformation> element whose value is of boolean type.
   With respect to a given LO, a LS is allowed to provide the timezone
   information corresponding to the LO, if and only if all of the
   following preconditions are satisfied:







Schulzrinne, et al.      Expires April 24, 2005                [Page 16]

Internet-Draft               Geopriv Policy                 October 2004


   1) the authorization policy related to the LO contains a rule with a
      <timezone-transformation> element,

   2) at least one of the rules safisfying 1) matches, and

   3) the combined value of this permission is 'true'.

   In all other cases, the LS MUST NOT provide timezone information.  In
   particular, this also comprises the case of an authorization policy
   that does not contain a rule with a <timezone-transformation>
   element.

8.5  Civil Location Transformation

   The civil location transformation can be specified by means of the
   <civil-loc-transformation> element to restrict the level of civil
   location information the LS is permitted to provide.  From lowest to
   highest level, the names of these levels are: 'null', 'country',
   'region', 'city', 'building', 'full'.  Each level is given by a set
   of civil location data items such as <country> and <A1>, ..., <A6>,
   as defined in [I-D.ietf-geopriv-pidf-lo].  Each level includes all
   elements included by the lower levels.

   The 'country' level includes only the <country> element; the 'region'
   level adds the <A1> element; the 'city' level adds the <A2> and <A3>
   elements; the 'building' level and the 'full' level add further civil
   location data as shown below:


                              full
      {<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>, <PRD>, <POD>,
       <STS>, <HNO>, <HNS>, <LMK>, <LOC>, <PC>, <NAM>, <FLR>, <ZIP>}
                               |
                            building
         {<country>, <A1>, <A2>, <A3>, <A4>, <A5>, <A6>,
         <PRD>, <POD>, <STS>, <HNO>, <HNS>, <LMK>, <PC>, <ZIP>}
                               |
                             city
                     {<country>, <A1>, <A2>}
                               |
                             region
                        {<country>, <A1>}
                               |
                            country
                          {<country>}
                               |
                             null
                               {}



Schulzrinne, et al.      Expires April 24, 2005                [Page 17]

Internet-Draft               Geopriv Policy                 October 2004


   With respect to a given LO, a LS is permitted to pass civil location
   information corresponding to the given LO on at the level l
   (l='country', 'region', 'city', 'building', or 'full'), if and only
   if all of the following preconditions are satisfied:

   1) the authorization policy related to the LO contains a rule with a
      <civil-loc-transformation> element,

   2) at least one of the rules satisfying 1) matches, and

   3) the combined value of this permission is the level l.

   In all other cases, including the case in which no rule of the
   authorization policy related to the given LO contains a
   <civil-loc-transformation> element, the LS MUST remove all civil
   location information from the LO before passing it on, thereby
   providing the 'null' level of civil location information.

8.6  Geospatial Location Transformation

   The geospatial location transformation can be specified by means of
   the <geospatial-loc-transformation> element to restrict the
   resolution of the geospatial location information to the value
   provided in the <latitude-resolution>, <longitude-resolution> and
   <altitude-resolution> child elements of the
   <geospatial-loc-transformation> element.  The resolution is specified
   as a positive, non-zero decimal number r.  If n is the nominal
   coordinate value, 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
   accuracy, one would use r=15 and obtain a value of 75 in this
   example.

   With respect to a given LO and to the latitude coordinate of
   ellipsoidal geospatial location information, a LS is allowed to pass
   the latitude value corresponding to the given LO on at the resolution
   value r, if and only if all of the following preconditions are
   satisfied:







Schulzrinne, et al.      Expires April 24, 2005                [Page 18]

Internet-Draft               Geopriv Policy                 October 2004


   1) the authorization policy related to the LO contains a rule with a
      <geospatial-loc-transformation> element that has a <latitude>
      element,

   2) at least one of the rules satisfying 1) matches, and

   3) the combined value of this permission is r.

   In all other cases, the LS MUST remove the latitude value from the
   geospatial location information.  Substituting in this paragraph
   'latitude' by 'longitude' and 'altitude', respectively, yields the
   corresponding regulations for the longitude and altitude coordinate.







































Schulzrinne, et al.      Expires April 24, 2005                [Page 19]

Internet-Draft               Geopriv Policy                 October 2004


9.  Example

   This section gives two simple examples for authorization policy rules
   that make use of the civil and the geospatial location condition.

9.1  Rule Example with Civil Location Condition

   This example illustrates a single rule that employs the civil
   location condition which matches if the current location of the
   Target is inside the area specified by the child elements of the
   <civil-loc-condition> element.  The syntax of this content complies
   with the 'civilAddress' complex type defined in
   [I-D.ietf-geopriv-pidf-lo].  In this example, requests match only if
   the Target is at his main office in a Siemens site in Munich.

   The rule is valid for one year as specified by the <validity>
   element.  No actions are imposed on LSs.  The <transformations>
   section indicates that LSs are allowed to distribute the LOs with
   authorization policy included, to provide timezone and the full set
   of civil location information, and to pass latitude and longitude
   values of geospatial location information on at quite a high level of
   resolution.  Since the policy does not contain a rule with a
   <retention-transformation>, LSs have to delete LOs immediately upon
   service completion.


   <?xml version="1.0" encoding="UTF-8"?>
   <cp:ruleset
     xmlns:cp="urn:ietf:params:xml:ns:common-policy"
     xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation=
       "urn:ietf:params:xml:ns:common-policy cp02.xsd
        urn:ietf:params:xml:ns:geopriv-policy gp03.xsd">

     <cp:rule id="AA56i09">

       <cp:conditions>

         <cp:validity>
           <cp:from>2004-11-01T00:00:00+01:00</cp:from>
           <cp:to>2005-11-01T00:00:00+01:00</cp:to>
         </cp:validity>

         <gp:civil-loc-condition>
           <country>DE</country>
           <A1>Bavaria</A1>
           <A3>Munich</A3>



Schulzrinne, et al.      Expires April 24, 2005                [Page 20]

Internet-Draft               Geopriv Policy                 October 2004


           <A4>Perlach</A4>
           <A6>Otto-Hahn-Ring</A6>
           <HNO>6</HNO>
         </gp:civil-loc-condition>

       </cp:conditions>

       <cp:actions></cp:actions>

       <cp:transformations>

         <gp:distribution-transformation>
           true
         </gp:distribution-transformation>

         <gp:keep-rules-transformation>
           true
         </gp:keep-rules-transformation>

         <gp:timezone-transformation>
           true
         </gp:timezone-transformation>

         <gp:civil-loc-transformation>full</gp:civil-loc-transformation>

         <gp:geospatial-loc-transformation>
           <gp:lat-resolution>0.00001</gp:lat-resolution>
           <gp:lon-resolution>0.00001</gp:lon-resolution>
         </gp:geospatial-loc-transformation>

       </cp:transformations>

     </cp:rule>

   </cp:ruleset>



9.2  Rule Example with Geospatial Location Information

   This example illustrates a rule that employs the geospatial location
   condition which matches if the current location of the Target is
   inside the area specified by the <point> child elements of the
   <polygon> 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 <polygon>
   element.  The given four points specify a quadrangle on the surface
   of the rotational ellipoid being part of the WGS-84 system,



Schulzrinne, et al.      Expires April 24, 2005                [Page 21]

Internet-Draft               Geopriv Policy                 October 2004


   corresponding to a certain area in Washington, DC, USA.  The Target
   associated to this authorization policy must be located within that
   area in order to make the rule match.

   The transformation part of the example rule allows LSs to distribute
   LO from which all authorization policy rules or pointers to them have
   been removed.  LSs are permitted to retain LOs related to the Target
   in question for at most one hour.  They are allowed to provide civil
   location information about the Target at city level of precision, and
   geospatial location information at a rather low level of resolution.
   The rule below specifies that LSs must not provide timezone
   information inside LOs as the <timezone-transformation> has been
   omitted.


   <?xml version="1.0" encoding="UTF-8"?>
   <cp:ruleset
     xmlns:cp="urn:ietf:params:xml:ns:common-policy"
     xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation=
       "urn:ietf:params:xml:ns:common-policy cp02.xsd
        urn:ietf:params:xml:ns:geopriv-policy gp03.xsd">

     <cp:rule id="BB56i09">

       <cp:conditions>

         <cp:validity>
           <cp:from>2004-11-01T00:00:00+01:00</cp:from>
           <cp:to>2005-11-01T00:00:00+01:00</cp:to>
         </cp:validity>

         <gp:geospatial-loc-condition>
           <gp:polygon
             crsName="urn:ietf:params:xml:ns:geopriv-policy:crs:wgs84">
             <gp:point>
               <gp:lat>38.8986</gp:lat>
               <gp:lon>-77.03724</gp:lon>
             </gp:point>
             <gp:point>
               <gp:lat>38.8986</gp:lat>
               <gp:lon>-77.03722</gp:lon>
             </gp:point>
             <gp:point>
               <gp:lat>38.8987</gp:lat>
               <gp:lon>-77.03722</gp:lon>
             </gp:point>



Schulzrinne, et al.      Expires April 24, 2005                [Page 22]

Internet-Draft               Geopriv Policy                 October 2004


             <gp:point>
               <gp:lat>38.8987</gp:lat>
               <gp:lon>-77.03724</gp:lon>
             </gp:point>
           </gp:polygon>
         </gp:geospatial-loc-condition>

       </cp:conditions>

       <cp:transformations>

         <gp:distribution-transformation>
           true
         </gp:distribution-transformation>

         <gp:keep-rules-transformation>
           false
         </gp:keep-rules-transformation>

         <gp:retention-transformation>
           3600
         </gp:retention-transformation>

         <gp:civil-loc-transformation>city</gp:civil-loc-transformation>

         <gp:geospatial-loc-transformation>
           <gp:lat-resolution>0.2</gp:lat-resolution>
           <gp:lon-resolution>0.1</gp:lon-resolution>
         </gp:geospatial-loc-transformation>

       </cp:transformations>

     </cp:rule>

   </cp:ruleset>


   In case of a policy consisting of more than one rule and a request
   for location information that let multiple rules match, there must be
   a procedure for combining the permissions contained in the matching
   rules.  This procedure is defined in
   [I-D.ietf-geopriv-common-policy], Section 10.









Schulzrinne, et al.      Expires April 24, 2005                [Page 23]

Internet-Draft               Geopriv Policy                 October 2004


10.  XML Schema

   This section presents the XML schema that defines the Geopriv policy
   language described in the previous sections.  The Geopriv policy
   markup language introduced by this schema extends the common policy
   markup language (see [I-D.ietf-geopriv-common-policy]) by introducing
   new members of the 'condition' and 'transformation' substitution
   groups whose heads (namely the elements <condition> and
   <transformation>) are specified by the common policy schema (once
   again, see [I-D.ietf-geopriv-common-policy]).

   This way, the Geopriv policy markup language specializes the common
   rules markup language for location-based presence information.  To
   this end, the following schema imports the vocabulary of the common
   policy markup language.  Furthermore, to express civil location
   conditions, it imports the 'civilAddress' complex type as defined in
   [I-D.ietf-geopriv-pidf-lo].


   <?xml version="1.0" encoding="UTF-8"?>
   <xs:schema
     targetNamespace="urn:ietf:params:xml:ns:geopriv-policy"
     xmlns:gp="urn:ietf:params:xml:ns:geopriv-policy"
     xmlns:cp="urn:ietf:params:xml:ns:common-policy"
     xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     elementFormDefault="qualified"
     attributeFormDefault="unqualified">

     <xs:import
       namespace="urn:ietf:params:xml:ns:common-policy"
       schemaLocation="cp02.xsd"/>

     <xs:import
       namespace="urn:ietf:params:xml:ns:pidf:geopriv10:civilLoc"
       schemaLocation="civilloc03.xsd"/>

     <!-- Geopriv conditions -->

     <xs:element name="civil-loc-condition" type="cl:civilAddress"
       substitutionGroup="cp:condition"/>

     <xs:element name="geospatial-loc-condition"
       substitutionGroup="cp:condition">
       <xs:complexType>
         <xs:choice>
           <xs:element name="polygon">
             <xs:complexType>



Schulzrinne, et al.      Expires April 24, 2005                [Page 24]

Internet-Draft               Geopriv Policy                 October 2004


               <xs:sequence>
                 <xs:element name="point"
                   minOccurs="3" maxOccurs="unbounded">
                   <xs:complexType>
                     <xs:sequence>
                       <xs:element name="lat" type="xs:string"
                         minOccurs="1" maxOccurs="1" />
                       <xs:element name="lon" type="xs:string"
                         minOccurs="1" maxOccurs="1"/>
                       <xs:element name="alt" type="xs:string"
                         minOccurs="0" maxOccurs="1"/>
                     </xs:sequence>
                   </xs:complexType>
                 </xs:element>
               </xs:sequence>
               <xs:attribute name="crsName" type="xs:anyURI"/>
             </xs:complexType>
           </xs:element>
           <xs:any namespace="##other" processContents="lax"/>
         </xs:choice>
       </xs:complexType>
     </xs:element>

     <!-- Geopriv transformations -->

     <xs:element name="distribution-transformation"
       type="xs:boolean" substitutionGroup="cp:transformation"/>

     <xs:element name="retention-transformation"
       type="xs:integer" substitutionGroup="cp:transformation"/>

     <xs:element name="keep-rules-transformation"
       type="xs:boolean" substitutionGroup="cp:transformation"/>

     <xs:element name="timezone-transformation"
       type="xs:boolean" substitutionGroup="cp:transformation"/>

     <xs:element name="civil-loc-transformation"
       substitutionGroup="cp:transformation">
       <xs:simpleType>
         <xs:restriction base="xs:string">
           <xs:enumeration value="full"/>
           <xs:enumeration value="building"/>
           <xs:enumeration value="city"/>
           <xs:enumeration value="region"/>
           <xs:enumeration value="country"/>
         </xs:restriction>
       </xs:simpleType>



Schulzrinne, et al.      Expires April 24, 2005                [Page 25]

Internet-Draft               Geopriv Policy                 October 2004


     </xs:element>

     <xs:element name="geospatial-loc-transformation"
       substitutionGroup="cp:transformation">
       <xs:complexType>
         <xs:sequence>
           <xs:element name="lat-resolution" type="xs:double"
             minOccurs="0" maxOccurs="1" />
           <xs:element name="lon-resolution" type="xs:double"
             minOccurs="0" maxOccurs="1"/>
           <xs:element name="alt-resolution" type="xs:double"
             minOccurs="0" maxOccurs="1"/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

   </xs:schema>


































Schulzrinne, et al.      Expires April 24, 2005                [Page 26]

Internet-Draft               Geopriv Policy                 October 2004


11.  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 [RFC3694] and are applicable to
   this draft as well.  Requirements are addressed in [RFC3693].
   Section 5 addresses issues of protecting the policy rules within the
   LO and location information itself.  Aspects of combining permissions
   in cases of multiple occurrence are treated in
   [I-D.ietf-geopriv-common-policy]).  How the behavior of LSs can be
   regulated in terms of location object handling in a privacy-safe
   fashion is specified in Section 8.







































Schulzrinne, et al.      Expires April 24, 2005                [Page 27]

Internet-Draft               Geopriv Policy                 October 2004


12.  Open Issues

   Due to the complexity of specifying polygons on the earth ellipsoid,
   it may be preferable to consider other boundaries, such as distance
   from a fixed point or approximate coordinate-based representations on
   a plane.













































Schulzrinne, et al.      Expires April 24, 2005                [Page 28]

Internet-Draft               Geopriv Policy                 October 2004


13.  References

13.1  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", March 1997.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J. and J.
              Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [RFC3694]  Danley, M., Mulligan, D., Morris, J. and J. Peterson,
              "Threat Analysis of the Geopriv Protocol", RFC 3694,
              February 2004.

13.2  Informative References

   [I-D.ietf-geopriv-common-policy]
              Schulzrinne, H., Morris, J., Tschofenig, H., Cuellar, J.,
              Polk, J. and J. Rosenberg, "A Document Format for
              Expressing Privacy Preferences",
              draft-ietf-geopriv-common-policy-02 (work in progress),
              October 2004.

   [I-D.ietf-geopriv-dhcp-civil]
              Schulzrinne, H., "Dynamic Host Configuration Protocol
              (DHCPv4 and DHCPv6) Option for Civic Addresses",
              draft-ietf-geopriv-dhcp-civil-03 (work in progress), July
              2004.

   [I-D.ietf-geopriv-pidf-lo]
              Peterson, J., "A Presence-based GEOPRIV Location Object
              Format", draft-ietf-geopriv-pidf-lo-03 (work in progress),
              September 2004.

   [I-D.ietf-simple-xcap]
              Rosenberg, J., "The Extensible Markup Language (XML)
              Configuration Access Protocol (XCAP)",
              draft-ietf-simple-xcap-03 (work in progress), July 2004.

   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S. and D.
              Jensen, "HTTP Extensions for Distributed Authoring --
              WEBDAV", RFC 2518, February 1999.

   [RFC3825]  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 April 24, 2005                [Page 29]

Internet-Draft               Geopriv Policy                 October 2004


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


   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


   Hannes Tschofenig
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   EMail: Hannes.Tschofenig@siemens.com
   URI:   http://www.tschofenig.com


   Jorge R. Cuellar
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern  81739
   Germany

   EMail: Jorge.Cuellar@siemens.com










Schulzrinne, et al.      Expires April 24, 2005                [Page 30]

Internet-Draft               Geopriv Policy                 October 2004


   James Polk
   Cisco
   2200 East President George Bush Turnpike
   Richardson, Texas  75082
   USA

   EMail: jmpolk@cisco.com












































Schulzrinne, et al.      Expires April 24, 2005                [Page 31]

Internet-Draft               Geopriv Policy                 October 2004


Appendix A.  Contributors

   We would like to thank Christian Guenther for his help with this
   document.


   Christian Guenther
   Siemens
   Otto-Hahn-Ring 6
   Munich, Bayern 81730
   Germany

   EMail: christian.guenther@siemens.com






































Schulzrinne, et al.      Expires April 24, 2005                [Page 32]

Internet-Draft               Geopriv Policy                 October 2004


Appendix B.  Acknowledgments

   This document is partially based on the discussions within the IETF
   GEOPRIV working group.  Discussions at the Geopriv Interim Meeting
   2003 in Washington, D.C., helped the working group to make progress
   on the authorization policies based on the discussions among the
   participants.

   We particularly want to thank Allison Mankin <mankin@psg.com>,
   Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton
   <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, Jon
   Peterson <jon.peterson@neustar.biz> for their time discussing a
   number of details with us.  They helped us to improve the quality of
   this document.





































Schulzrinne, et al.      Expires April 24, 2005                [Page 33]

Internet-Draft               Geopriv Policy                 October 2004


Intellectual Property Statement

   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.


Disclaimer of Validity

   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 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.


Copyright Statement

   Copyright (C) The Internet Society (2004).  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.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Schulzrinne, et al.      Expires April 24, 2005                [Page 34]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/