[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

GEOPRIV                                                       M. Thomson
Internet-Draft                                           J. Winterbottom
Intended status: Standards Track                                  Andrew
Expires: November 28, 2008                                  May 27, 2008


     Specifying Location Quality Constraints in Location Protocols
               draft-thomson-geopriv-location-quality-01

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 November 28, 2008.


















Thomson & Winterbottom  Expires November 28, 2008               [Page 1]


Internet-Draft              Location Quality                    May 2008


Abstract

   Parameters that define the expected quality of location information
   are defined for use in location protocols.  These parameter can be
   used by a requester to indicate to a Location Server the desired
   constraints on the quality of the location information provided.  If
   applicable, the Location Server is able to use this information to
   control how location information is determined.  An optional
   indication of whether the quality constraints were met is defined to
   be provided by the Location Server alongside location information.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions used in this document  . . . . . . . . . . . .  4
   2.  Location Quality Operation . . . . . . . . . . . . . . . . . .  5
   3.  Location Quality Objects . . . . . . . . . . . . . . . . . . .  6
     3.1.  Location Quality Request . . . . . . . . . . . . . . . . .  6
       3.1.1.  Maximum Uncertainty  . . . . . . . . . . . . . . . . .  6
       3.1.2.  Required Civic Elements  . . . . . . . . . . . . . . .  7
       3.1.3.  Maximum Age  . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Location Quality Indication  . . . . . . . . . . . . . . .  8
   4.  Location Quality Schema  . . . . . . . . . . . . . . . . . . . 10
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     6.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:lq  . . . . . . . . . . . . 14
     6.2.  XML Schema Registration for Location Quality Schema  . . . 14
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
   Intellectual Property and Copyright Statements . . . . . . . . . . 19

















Thomson & Winterbottom  Expires November 28, 2008               [Page 2]


Internet-Draft              Location Quality                    May 2008


1.  Introduction

   Location determination methods produce results of varying accuracy.
   In general, the accuracy of location information increases as the
   effort expended in generating the information increases.  Accuracy is
   the primary aspect of the quality of location information that is
   relevant to a Location Recipient (LR), but other aspects of quality
   can also be significant, such as the currency of the data.

   This document provides XML extension objects that can be added to any
   protocol that provides location information.  These elements provide
   the ability to communicate location quality constraints to the
   location server.

   This document provides semantics, examples and security
   considerations for the HELD protocol
   [I-D.ietf-geopriv-http-location-delivery].  Application of the
   parameters described in this document to other protocols is out of
   scope.

   Means for expressing the quality of location information is outlined
   in [I-D.thomson-geopriv-uncertainty] and [GeoShape].  An entity
   requesting location information of a Location Server (LS) is unable
   to specify the quality of the location that it ultimately receives.
   This is inefficient because an LS either provides location
   information that is inadequate for the intended task; or the LS could
   waste resources generating location information that is of
   eccessively high quality.

   This document describes an optional HELD parameter that communicates
   location quality constraints to an LS.  These constraints specify a
   desired uncertainty at a certain confidence, plus the maximum
   acceptable age where location information is stored.  Guidelines for
   deterministically evaluating location information against these rules
   are provided.

   Some of the benefits of providing an LS with location quality
   constraints are described in [I-D.busin-geopriv-location-qos-req].
   Location quality constraints provide information that an LS can use
   in deciding how to generate location information, if the LS uses a
   Location Generator as a source of location information.  This is the
   case for a Location Information Server (LIS) and the HELD protocol.
   For example, a LIS that is able to provide a location estimate with a
   sufficiently small uncertainty might be able to provide a response
   before the time indicated within the time indicated in the request
   (the "responseTime").

   This document also provides a means by which the LS is able to



Thomson & Winterbottom  Expires November 28, 2008               [Page 3]


Internet-Draft              Location Quality                    May 2008


   indicate if the location quality meets the constraints.  These
   parameters can be used by a Location Recipient to ensure that the
   location is of adequate quality without requiring specific checking
   (although the PIDF-LO should include sufficient information to
   perform this check).  Response parameters are optional; the presence
   of a quality indication in the response also indicates that the LS
   has understood the location quality constraints.

   This document provides solutions that address a subset of the
   requirements in [I-D.busin-geopriv-location-qos-req].

1.1.  Conventions used in this document

   Terms and procedures relating to uncertainty and confidence are taken
   from [I-D.thomson-geopriv-uncertainty].  Familiarity with terminology
   outlined in [I-D.ietf-geopriv-l7-lcp-ps] and [RFC3693] is also
   assumed.

   The term Location Server (LS) is used as a generic label, since these
   paramters apply in all cases where location information is served to
   a requesting entity.  From the perspective of this document, the LS
   could be a Location Information Server (LIS).  Similarly, the term
   Location Recipient (LR) is used to refer to the requester of location
   information, which could be a Device or Target for HELD.

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























Thomson & Winterbottom  Expires November 28, 2008               [Page 4]


Internet-Draft              Location Quality                    May 2008


2.  Location Quality Operation

   Location quality parameters are provided by a Device or any other
   client of an LS in a location request message.  Figure 1 shows an
   example message.

     <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
       <locationType exact="true">geodetic</locationType>
       <quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
         <maxUncertainty confidence="95">
           <horizontal>150</horizontal>
           <vertical>1000</vertical>
         </maxUncertainty>
         <maxAge>2008-05-27T05:47:55Z</maxAge>
       </quality>
     </locationRequest>

                  Figure 1: Example HELD Location Request

   A LS that supports the location quality element uses the information
   contained in the request to choose how it serves the query.  The
   response to this message contains a quality indicator element that
   includes a list of the quality constraints that were met.  Figure 2
   shows a location response that includes a quality indicator.

     <locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
       <presence xmlns="urn:ietf:params:xml:ns:pidf"
                 entity="pres:user@example.com">
         <!-- Actual location information omitted -->
       </presence>
       <qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
         maxUncertainty/vertical maxAge
       </qualityInd>
     </locationResponse>

                 Figure 2: Example HELD Location Response

   A LS doesn't indicate the quality of the location estimate in the
   quality indicator; quality information is included in the PIDF-LO.
   The quality indicator provides notice to its recipient that the
   requested quality was provided.










Thomson & Winterbottom  Expires November 28, 2008               [Page 5]


Internet-Draft              Location Quality                    May 2008


3.  Location Quality Objects

   This section defines the format and semantics of the location quality
   parameters for requests and the indication that is included with
   responses.

3.1.  Location Quality Request

   The "quality" element is included in a HELD request to indicate the
   constraints set by the Location Recipient (LR) on the quality of
   returned location information.  This document defines three elements
   that are included.

3.1.1.  Maximum Uncertainty

   The "maxUncertainty" element describes an upper limit on uncertainty
   at a given confidence.  Uncertainty is divided in to horizontal and
   vertical components.  Horizontal uncertainty is the maximum distance
   from the centroid of the area to the point in the shape furthest from
   the centroid on the horizontal plane.  Vertical uncertainty is the
   difference in altitude from the centroid to the point in the shape
   with the greatest altitude.

      Note: An LS MAY provide location information using the Point shape
      and indicate that the requested uncertainty is met providing that
      the LS has access to uncertainty information.  However, this is
      NOT RECOMMENDED since the LR has no way of verifying that the
      uncertainty meets their requirements.

   The "horizontal" and "vertical" elements are numerical values that
   contain a decimal value in meters.  Maximum uncertainty values MUST
   be greater than zero.

   A location estimate that does not contain uncertainty (i.e. a Point
   shape), never meets location quality constraints.  Where uncertainty
   is unknown, it MUST be assumed to be infinite at any non-zero
   confidence.  In particular, this applies to vertical uncertainty
   where the location estimate is two-dimensional only; location
   estimates without a vertical component of uncertainty never meet
   vertical uncertainty constraints.

   The "confidence" attribute of this element includes the confidence
   level (expressed as a percentage) that the uncertainty is evaluated
   at.  Confidence is set to a default of 95%.

   To evaluate uncertainty, the location estimate is first scaled so
   that the confidence of the estimate matches (or exceeds) the
   requested confidence.  The LS MAY convert the shape of the



Thomson & Winterbottom  Expires November 28, 2008               [Page 6]


Internet-Draft              Location Quality                    May 2008


   uncertainty to a circle or a sphere prior to scaling to simply the
   scaling process.  For consistency -- and contrary to the rules in
   [I-D.thomson-geopriv-uncertainty] -- it is RECOMMENDED that a normal
   PDF be used for all location information except where confidence is
   reduced for a rectangular PDF.

   Horizontal uncertainty is evalulated by removing the altitude and
   altitude uncertainty components from the location estimate.  While
   removing altitude components from a location estimate might normally
   increase confidence, confidence MUST NOT be increased at this step;
   the confidence value has already been considered.  The shape is then
   converted to a circle, if it is not already in that shape.  The
   radius of the resulting circle is compared to the maximum horizontal
   uncertainty.

   Vertical uncertainty is evaluated for shapes that contain altitude
   uncertainty.  The value used for evaluating vertical uncertainty
   depends on the shape type: the vertical axis value for the Ellipsoid
   shape; the radius of the Sphere shape; half the height of the Prism
   shape.

   The LS MAY use location quality parameters to alter the way that it
   generates location information and to provide location information
   that more closely matches what is requested.  If maximum value is
   provided for vertical uncertainty, it is RECOMMENDED that the LS
   provide a location estimate that includes altitude and altitude
   uncertainty.  It is RECOMMENDED that the LS provide location
   information at the confidence included in the request, if possible
   and if the location information is not significantly degraded by any
   scaling that might be required to do this.

3.1.2.  Required Civic Elements

   The "requiredCivic" element represents the requirements of an LR for
   civic address information.  An LR can specify the address elements
   that need to be present in the civic address in order for the
   location information to meet their quality requirements.

   The "requiredCivic" element contains a whitespace-separated list of
   element names.  These can be interpreted as XPath
   [W3C.REC-xpath-19991116] expressions that are evaluated in the
   context of the "civicAddress" element [RFC5139].  These XPath
   statements are restricted to use of qualified names only (using the
   response document namespace context) and the "/" separator; that is,
   the only permitted axis is the "child::" axis.  All child nodes of
   elements (including attributes and textual content) are treated as
   belonging to an element.




Thomson & Winterbottom  Expires November 28, 2008               [Page 7]


Internet-Draft              Location Quality                    May 2008


   Figure 3 shows an example request where an LR requires country, state
   (or equivalent) and post code civic address elements in the location
   information provided by the LS.

     <quality xmlns="urn:ietf:params:xml:ns:geopriv:lq">
       <requiredCivic
           xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr">
         ca:country ca:A1 ca:PC
       </requiredCivic>
     </quality>

        Figure 3: Example Specifying Required Civic Address Fields

   Note that this does not force the LS to restrict civic address
   information to the indicated fields.  Additional fields MAY be
   provided.

3.1.3.  Maximum Age

   Where location information is stored or cached, an LR can specify a
   limit on the age of this information.  This is particularly important
   if location information is generated in advance.  The "age" of
   location information is indicated by the the "timestamp" element in
   the PIDF tuple.  The age parameter specifies the minimum value for
   this field; that is, the oldest location information that is
   acceptable.

   Location information that has greater age than requested SHOULD
   either be determined anew, or checked so that the timestamp can be
   updated.  A value of "now" can be used to indicate that stored
   location information is not acceptable to the LR.

3.2.  Location Quality Indication

   The "qualityInd" element is used in responses to indicate which of
   the location quality constraints from a request were met.  The
   "qualityInd" element contains a list of the quality constraints that
   the accompanying location information meets.

   The list of constraints is represented as a whitespace-separated list
   of element names.  These can be interpreted as XPath
   [W3C.REC-xpath-19991116] expressions that are evaluated in the
   context of the original location quality request.  These statements
   follow the same constraints as the list of elements in Section 3.1.2.

   Where elements are nested, such as the "maxUncertainty" element, the
   outer element can be included to indicate an entire constraint is
   met; or, each individual child element can be identified.  Two



Thomson & Winterbottom  Expires November 28, 2008               [Page 8]


Internet-Draft              Location Quality                    May 2008


   equivalent indications are shown in Figure 4.

       <qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
         maxUncertainty
       </qualityInd>

       <qualityInd xmlns="urn:ietf:params:xml:ns:geopriv:lq">
         maxUncertainty/horizontal maxUncertainty/vertical
       </qualityInd>

                 Figure 4: Equivalent Quality Indications

   A LS that is unable to determine if a constraint MUST either omit the
   quality indication, or indicate that the constraint was not met.

   Two special values are added to the quality indication element for
   convenience.  The value "##all" indicates that all quality
   constraints were met (including any extensions).  The value "##none"
   indicates that none of the constraints were met.
































Thomson & Winterbottom  Expires November 28, 2008               [Page 9]


Internet-Draft              Location Quality                    May 2008


4.  Location Quality Schema

   Note that the pattern rules in the following schema wrap due to
   length constraints in RFC documents.  None of the patterns contain
   whitespace.

   <?xml version="1.0"?>
   <xs:schema
       xmlns:lq="urn:ietf:params:xml:ns:geopriv:lq"
       xmlns:conf="urn:ietf:params:xml:ns:geopriv:conf"
       xmlns:xs="http://www.w3.org/2001/XMLSchema"
       targetNamespace="urn:ietf:params:xml:ns:geopriv:lq"
       elementFormDefault="qualified"
       attributeFormDefault="unqualified">

     <xs:annotation>
       <xs:appinfo
           source="urn:ietf:params:xml:schema:geopriv:lq">
         HELD Location Quality
       </xs:appinfo>
       <xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
         <!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
              published RFC and remove this note.]] -->
         This schema defines a framework for location quality requests
         and indications of whether they are met.
       </xs:documentation>
     </xs:annotation>

     <xs:import namespace="urn:ietf:params:xml:ns:geopriv:conf"/>

     <xs:element name="quality">
       <xs:complexType>
         <xs:complexContent>
           <xs:restriction base="xs:anyType">
             <xs:sequence>
               <xs:element ref="lq:maxUncertainty" minOccurs="0"/>
               <xs:element ref="lq:requiredCivic" minOccurs="0"/>
               <xs:element ref="lq:maxAge" minOccurs="0"/>
               <xs:any namespace="##other" processContents="lax"
                       minOccurs="0" maxOccurs="unbounded"/>
             </xs:sequence>
             <xs:anyAttribute namespace="##any" processContents="lax"/>
           </xs:restriction>
         </xs:complexContent>
       </xs:complexType>
     </xs:element>

     <xs:element name="maxUncertainty" type="lq:maxUncertaintyType"/>



Thomson & Winterbottom  Expires November 28, 2008              [Page 10]


Internet-Draft              Location Quality                    May 2008


     <xs:complexType name="maxUncertaintyType">
       <xs:complexContent>
         <xs:restriction base="xs:anyType">
           <xs:sequence>
             <xs:element name="horizontal" type="lq:limitType"/>
             <xs:element name="vertical" type="lq:limitType"/>
           </xs:sequence>
           <xs:attribute name="confidence" type="conf:confidenceBase"
                         default="95"/>
         </xs:restriction>
       </xs:complexContent>
     </xs:complexType>

     <xs:simpleType name="limitType">
       <xs:restriction base="xs:decimal">
         <xs:minExclusive value="0.0"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:element name="maxAge" type="lq:maxAgeType"/>
     <xs:simpleType name="maxAgeType">
       <xs:restriction base="xs:duration">
         <xs:minInclusive value="PT0S"/>
       </xs:restriction>
     </xs:simpleType>

     <xs:element name="requiredCivic" type="lq:elementListType"/>

     <xs:element name="qualityInd" type="lq:qualityIndType"/>
     <xs:simpleType name="qualityIndType">
       <xs:union memberTypes="lq:elementListType">
         <xs:simpleType>
           <xs:restriction base="xs:token">
             <xs:enumeration value="##all"/>
             <xs:enumeration value="##none"/>
           </xs:restriction>
         </xs:simpleType>
       </xs:union>
     </xs:simpleType>

     <xs:simpleType name="elementListType">
       <xs:list>
         <xs:simpleType>
           <xs:restriction base="xs:token">
             <xs:pattern
                 value="(([\i-[:]][\c-[:]]*:)?[\i-[:]][\c-[:]]*/)*
                        ([\i-[:]][\c-[:]]*:)?[\i-[:]][\c-[:]]*"/>
           </xs:restriction>



Thomson & Winterbottom  Expires November 28, 2008              [Page 11]


Internet-Draft              Location Quality                    May 2008


         </xs:simpleType>
       </xs:list>
     </xs:simpleType>

   </xs:schema>














































Thomson & Winterbottom  Expires November 28, 2008              [Page 12]


Internet-Draft              Location Quality                    May 2008


5.  Security Considerations

   This document does not introduce any security considerations.
   [[Editor's Note: Please let us know if you can think of some.]]















































Thomson & Winterbottom  Expires November 28, 2008              [Page 13]


Internet-Draft              Location Quality                    May 2008


6.  IANA Considerations

   This section registers a namespace and schema for the location
   quality objects.

6.1.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:lq

   This section registers a new XML namespace,
   "urn:ietf:params:xml:ns:geopriv:lq", as per the guidelines in
   [RFC3688].

      URI: urn:ietf:params:xml:ns:geopriv:lq

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), Martin Thomson (martin.thomson@andrew.com).

      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>Location Quality</title>
             </head>
             <body>
               <h1>Namespace for Location Quality</h1>
               <h2>urn:ietf:params:xml:ns:geopriv:lq</h2>
   [[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
       with the RFC number for this specification.]]
               <p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
             </body>
           </html>
         END

6.2.  XML Schema Registration for Location Quality Schema

   This section registers an XML schema as per the guidelines in
   [RFC3688].

   URI:  urn:ietf:params:xml:schema:geopriv:lq

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      Martin Thomson (martin.thomson@andrew.com).





Thomson & Winterbottom  Expires November 28, 2008              [Page 14]


Internet-Draft              Location Quality                    May 2008


   Schema:  The XML for this schema can be found in Section 4 of this
      document.

















































Thomson & Winterbottom  Expires November 28, 2008              [Page 15]


Internet-Draft              Location Quality                    May 2008


7.  References

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

   [RFC5139]  Thomson, M. and J. Winterbottom, "Revised Civic Location
              Format for Presence Information Data Format Location
              Object (PIDF-LO)", RFC 5139, February 2008.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-07 (work in
              progress), April 2008.

   [I-D.thomson-geopriv-uncertainty]
              Thomson, M. and J. Winterbottom, "Representation of
              Uncertainty and Confidence in PIDF-LO",
              draft-thomson-geopriv-uncertainty-00 (work in progress),
              November 2007.

7.2.  Informative References

   [W3C.REC-xpath-19991116]
              Clark, J. and S. DeRose, "XML Path Language (XPath)
              Version 1.0", World Wide Web Consortium
              Recommendation REC-xpath-19991116, November 1999,
              <http://www.w3.org/TR/1999/REC-xpath-19991116>.

   [I-D.busin-geopriv-location-qos-req]
              Busin, A., Jin, Y., Mosmondor, M., and S. Loreto,
              "Requirements for a Location Quality of Service (QoS)
              Information Object",
              draft-busin-geopriv-location-qos-req-01 (work in
              progress), November 2007.

   [I-D.ietf-geopriv-l7-lcp-ps]
              Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
              Location Configuration Protocol; Problem Statement and
              Requirements", draft-ietf-geopriv-l7-lcp-ps-07 (work in
              progress), March 2008.

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and



Thomson & Winterbottom  Expires November 28, 2008              [Page 16]


Internet-Draft              Location Quality                    May 2008


              J. Polk, "Geopriv Requirements", RFC 3693, February 2004.

   [GeoShape]
              Thomson, M. and C. Reed, "GML 3.1.1 PIDF-LO Shape
              Application Schema for use by the Internet Engineering
              Task Force (IETF)", Candidate OpenGIS Implementation
              Specification 06-142r1, Version: 1.0, April 2007.












































Thomson & Winterbottom  Expires November 28, 2008              [Page 17]


Internet-Draft              Location Quality                    May 2008


Authors' Addresses

   Martin Thomson
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2915
   Email: martin.thomson@andrew.com
   URI:   http://www.andrew.com/


   James Winterbottom
   Andrew
   PO Box U40
   Wollongong University Campus, NSW  2500
   AU

   Phone: +61 2 4221 2938
   Email: james.winterbottom@andrew.com
   URI:   http://www.andrew.com/





























Thomson & Winterbottom  Expires November 28, 2008              [Page 18]


Internet-Draft              Location Quality                    May 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.











Thomson & Winterbottom  Expires November 28, 2008              [Page 19]


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