view Side-By-Side changes

Geopriv                                                  J. Winterbottom
Internet-Draft                                                M. Thomson
Intended status: Standards Track                      Andrew Corporation
Expires: July 19, August 29, 2009                                   H. Tschofenig
                                                  Nokia Siemens Networks
                                                               R. Barnes
                                                        BBN Technologies
                                                        January 15,
                                                       February 25, 2009


                        HELD


    Use of Target Identity Extensions
         draft-winterbottom-geopriv-held-identity-extensions-08 in HTTP-Enabled Location Delivery (HELD)
         draft-winterbottom-geopriv-held-identity-extensions-09

Status of this This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and 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 July 19, August 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.





Winterbottom, et al.     Expires July 19, August 29, 2009                [Page 1]

Internet-Draft                HELD Identity                 January                February 2009


Abstract

   When a Location Information Server receives a request for location
   information (using the locationRequest message), described in the
   base HTTP Enabled Location Delivery (HELD) specification, it uses the
   source IP address of arriving message as a pointer to the location
   determination process.  This is sufficient in environments where an a
   Target's location can be determined based on its IP address.

   Two additional use cases are addresses by this document.  In the
   first, location configuration requires additional or alternative
   identifiers from the source IP address provided in the request is not the only
   identifier for the Target. request.  In
   the second, an entity other than the Target requests the Target's
   location.

   This document extends the HELD protocol to allow the location request
   message to carry additional identifiers assisting the location
   determination process.  It defines a set of URIs for Target
   identifiers and an XML containment schema.  This extension is used in
   conjunction with HELD to provide Target identification, and set of
   criteria of when to use this extensions are provided.  Examples identifiers.  Privacy and
   usage in HELD message syntax security
   considerations describe the conditions where requests containing
   identifiers are also shown. permitted.
































Winterbottom, et al.     Expires July 19, August 29, 2009                [Page 2]

Internet-Draft                HELD Identity                 January                February 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Applications . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  6  5
   3.  Target Identity Extension Details  . . . . . . . . . . . . . . . . . .  7 . . . . .  5
     3.1.  URI Definitions  Identifier Format and Protocol Details . . . . . . . . . .  6
     3.2.  Identifiers  . . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.1.  MAC
       3.2.1.  IP Address URI . . . . . . . . . . . . . . . . . . . . . .  7
       3.1.2.  IP
       3.2.2.  MAC Address URIs  . . . . . . . . . . . . . . . . . . .  7
     3.2.  Schema . .  7
       3.2.3.  TCP or UDP Port Number . . . . . . . . . . . . . . . .  8
       3.2.4.  Network Access Identifier  . . . . . . . . .  8
   4.  Privacy Considerations . . . . .  8
       3.2.5.  URI  . . . . . . . . . . . . . . . 11
   5.  Security Considerations . . . . . . . . . .  8
       3.2.6.  Hostname . . . . . . . . . 13
     5.1.  Location Configuration Protocol Requests . . . . . . . . . 13
     5.2.  Third Party Requests . . . . .  9
       3.2.7.  Directory Number . . . . . . . . . . . . . . 13
     5.3.  Distinguishing LCP Requests from Third Party Requests . . 14
   6.  IANA Considerations . . .  9
       3.2.8.  Cellular Telephony Identifiers . . . . . . . . . . . .  9
       3.2.9.  DHCP Unique Identifier . . . . . . 15
     6.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 15
     6.2. 10
   4.  XML Schema Registration . . . . . . . . . . . . . . . . . 15
     6.3.  Identifier 'type' Attribute values . . . . . . . . . 10
   5.  Privacy Considerations . . . 16
     6.4.  URI Type Attribute Values . . . . . . . . . . . . . . . . 16
   7.  Acknowledgements . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
     6.1.  Location Configuration Protocol Requests . . . 18
   8.  References . . . . . . 14
     6.2.  Third Party Requests . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . 19
     8.1.  Normative references . . . . . . . . . . . . . . . . . . . 19
     8.2.  Informative references . 14
     7.1.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:geopriv:held:id . . . . . . . . . . 14
     7.2.  XML Schema Registration  . . . . . . . 19
   Authors' Addresses . . . . . . . . . . 15
     7.3.  Registration of HELD 'badIdentifier' Error Code  . . . . . 15
   8.  Acknowledgements . . . . . . . . . 21

























Winterbottom, et al.      Expires July 19, 2009                 [Page 3]

Internet-Draft                HELD Identity                 January 2009


1.  Introduction

   Protocols for requesting and providing location information require a
   way for the . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative references . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative references . . . . . . . . . . . . . . . . . . 17




















Winterbottom, et al.     Expires August 29, 2009                [Page 3]

Internet-Draft                HELD Identity                February 2009


1.  Introduction

   Protocols for requesting and providing location information require a
   way for the requestor to specify the location that should be
   returned.  In a location configuration protocol (LCP), the location
   being requested is the requestor's location.  This fact can make the
   problem of identifying the Target Device simpler for LCPs, since IP
   datagrams that carry the request already carry an identifier for the
   Target,
   Device, namely the source IP address of an incoming request.
   Existing LCPs, such as HELD [I-D.ietf-geopriv-http-location-delivery]
   and DHCP ([RFC3825], [RFC4776]) rely on the source IP address, and
   possibly lower-layer identifiers to identify a Target. Device.

   Aside from the datagrams that form a request, a location information
   server (LIS) does not necessarily have access to information that
   could further identify the Target of the request. Target.  In some circumstances, as shown
   in [I-D.ietf-geopriv-l7-lcp-ps], additional identification
   information can be included in a request to identify a Target.

   This document extends the HELD protocol to support the inclusion of
   additional identifiers for the Target in HELD location requests.  The
   identifiers are defined as URIs that include a range of different
   types of identification information.  Finally, an  An
   XML schema is defined that provides a structure for including these
   identifiers in HELD requests.

   An important characteristic of this addition to the HELD protocol is
   that is also expands the potential scope of HELD beyond that of an
   LCP.  The scope of an LCP is limited to the interaction between a
   Target
   Device and a LIS.  That is, an LCP is limited to the Target Device
   retrieving information about their own location.  With this addition,
   third party location recipients (LRs) are able to make requests that
   include identifiers to retrieve location information about a
   particular Target.

   The usage of HELD for purposes beyond the Target-LIS Device-LIS interaction
   obviously introduces a new set of privacy concerns.  In an LCP, the
   requester is implicitly authorized to access the request requested location
   information, because it is their own location.  In contrast, when a
   third party LR requests a Target's location, the LR MUST be
   explicitly authorized.  Establishing appropriate authorization and
   other related privacy concerns are discussed in Section 4. 5.

1.1.  Applications

   The use of additional identifiers in HELD falls into two categories.
   A Device can use these parameters to provide additional



Winterbottom, et al.      Expires July 19, 2009                 [Page 4]

Internet-Draft                HELD Identity                 January 2009
   identification information to a LIS.  Identification such as the
   hardware address of the Device can be used to reduce the time
   required to determine the location of the Device.  In other cases, a



Winterbottom, et al.     Expires August 29, 2009                [Page 4]

Internet-Draft                HELD Identity                February 2009


   LIS might require Device identification before any location
   information can be generated.

   A third party LR can be granted authorization to make requests for a
   Device.
   given Target.  In particular, network services can be permitted to
   retrieve location for a Device that is unable to acquire location
   information for itself (see Section 6.3 of
   [I-D.ietf-ecrit-phonebcp]).  This allows use of location-dependent
   applications--particularly essential services like emergency
   calling--where Devices do not support an LCP a location configuration
   protocol (LCP) or they are unable to successfully retrieve location
   information.






































Winterbottom, et al.      Expires July 19, 2009                 [Page 5]

Internet-Draft                HELD Identity                 January 2009

2.  Terminology

   This document reuses uses the term Target, Location Information Server (LIS) and
   location configuration protocol (LCP) as defined described in [RFC3693].
   [I-D.ietf-geopriv-l7-lcp-ps].

   This document uses reuses the term Location Information Server, LIS Target to refer to the subject of any
   request for location information.  The term Device is used
   specifically as
   described the subject of an LCP, consistent with
   [I-D.ietf-geopriv-http-location-delivery].  Both these terms are
   defined in [I-D.ietf-geopriv-l7-lcp-ps]. [RFC3693].

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









































Winterbottom, et al.      Expires July 19, 2009                 [Page 6]

Internet-Draft                HELD Identity                 January 2009

3.  Target Identity Extension Details

   This section defines

   Identifiers are used as the starting point in location determination.
   They should not be confused with measurement information
   ([I-D.thomson-geopriv-held-measurements]).  Measurement information
   is information about a Device and the time varying details of its
   network attachment.  Identifiers might be associated with a different
   Target over time, but the schema extension for HELD their purpose is to
   support identify the inclusion Target,
   not to describe its environment or network attachment.

   Use of any identifier MUST only be allowed if it uniquely identifies
   a Target identity in the form single Target.  In some circumstances, certain of a URI these identifiers
   are either temporary or
   typed-token.  A set of URI definitions could potentially identify multiple devices.
   Identifiers that can are transient or ambiguous could be used exploited by an
   attacker to specify
   these identities is also provided.

3.1.  URI Definitions either gain information about another device or to obtain
   misleading information.

   The URIs defined identifiers described in this section are designed to identify a Target;
   they do not identify measurements or sighting data associated with a
   Target, such SHOULD only be used where
   that identifier is used as the switch and port information to which the Target basis for location determination.  It



Winterbottom, et al.     Expires August 29, 2009                [Page 5]

Internet-Draft                HELD Identity                February 2009


   is attached.  This information may, tempting for example, be acquired using
   DHCP relay information [RFC3046] a LIS implementation to allow alternative identifiers
   for convenience or LLDP [LLDP].  Device measurements
   and sighting data are described in
   [I-D.thomson-geopriv-held-measurements].  The identity provided may some other perceived benefit.  However, care needs
   to be transitory, such as an IP address taken to ensure that is leased from a DHCP
   server pool.

   The URIs in the following sub-sections are defined using ABNF
   (augmented Backus-Naur form) described in [RFC5234].

3.1.1.  MAC Address URI

   A MAC URI represents the media access control address of binding between the Device,
   as defined in indicated
   identifier and the IEEE 802 series of specifications.  The ABNF identifier that is used for
   this URI type location determination
   is defined as:

   mac-uri = "mac:" 2*2HEXDIG 5*5macdig
   macdig = "-" 2*2HEXDIG

   MAC URIs can be unique and not subject to attacks.

3.1.  Identifier Format and Protocol Details

   XML elements are used in to express the same manner as Target identity.  The "target"
   element is suggested by the
   undefined "mac:" URIs used in examples in RFC 4479 [RFC4479]. as a general container for identity information.
   This document defines a basic set of identifiers.  An example of its use is provided HELD
   request, shown in Figure 3.

3.1.2.  IP Address URIs

   This section provides the ABNF for 1, includes an IP version 4 and IP version 6
   URIs.  One application of address.

     <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
                      responseTime="8">
       <locationType exact="true">geodetic</locationType>
       <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
         <ip v="4">192.0.2.5</ip>
       </target>
     </locationRequest>

                                 Figure 1

   A LIS that supports this URI scheme is described specification echoes the "target" element in
   [I-D.ietf-geopriv-l7-lcp-ps], where an outbound SIP proxy needs to
   make location requests to a LIS on behalf of
   a Target because, successful HELD response, including the identifiers that were used
   as the basis for
   some reason, location determination.  Absence of this indication
   means that the necessary location information was generated using the source IP
   address in the request.

   If an identifier is invalid, not provided supported by the
   Target.

   ip-uri = "ip:" ipv4 / ipv6
   ipv4 = "IPv4+" IPv4address    ; from RFC 3986
   ipv6 = "IPv6+" IPv6address    ; from RFC 3986




Winterbottom, et al.      Expires July 19, 2009                 [Page 7]

Internet-Draft LIS, or the
   requester is not authorized to use that identifier, a HELD Identity                 January 2009


   The definitions for "IPv4address" and "IPv6address" are taken from
   [RFC3986].

   An example error
   response of a location request including a URI "badIdentifier".  This code is registered in this form to
   identify Section 7.3.

   If the Target device LIS requires an identifier that is shown not provided in Figure 1.

 <locationRequest
        xmlns="urn:ietf:params:xml:ns:geopriv:held" responseTime="8000">
   <locationType>geodetic</locationType>
   <deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
     <uri>ip:IPv4+192.0.2.5</uri>
   </deviceIdentity>
 </locationRequest>

            Figure 1: the
   request, the desired identifiers MAY be identified in the HELD Location Request Using an IP Address

   Note error
   response, using the "requiredIdentifiers" element.  This element
   contains a list of XML qualified names [W3C.REC-xml-names11-20060816]
   that identify the URI types identifier elements required by the LIS.  Namespace
   prefix bindings for the qualified names are not case sensitive and taken from document
   context.  Figure 2 shows an example error indicating that the iP:ipv4+
   192.0.2.5 is still a valid URI.

3.2.  Schema

   This section defines
   requester needs to include a schema that MAC address (Section 3.2.2) if the
   request is used to provide Target
   identifiers in a HELD location request. succeed.









Winterbottom, et al.     Expires July 19, August 29, 2009                [Page 8] 6]

Internet-Draft                HELD Identity                 January                February 2009


   <?xml version="1.0"?>
   <xs:schema
   targetNamespace="urn:ietf:params:xml:ns:geopriv:held:id"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:heldDI="urn:ietf:params:xml:ns:geopriv:held:id"
   xmlns:xml="http://www.w3.org/XML/1998/namespace"
   elementFormDefault="qualified" attributeFormDefault="unqualified">

     <!-- typedURI definition -->

     <xs:complexType name="typedURI">
       <xs:simpleContent>
         <xs:extension base="xs:anyURI">
           <xs:attribute name="type" type="xs:token"
                         use="optional"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

     <!-- typedToken definition -->

     <xs:complexType name="typedToken">
       <xs:simpleContent>
         <xs:extension base="xs:token">
           <xs:attribute name="type" type="xs:token"
                         use="required"/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>


     <!-- Identity Parameters -->

     <xs:complexType name="idParameters">
       <xs:sequence>
         <xs:element name="uri" type="heldDI:typedURI"
                     minOccurs="0" maxOccurs="unbounded"/>
         <xs:element name="identifier" type="heldDI:typedToken"
                     minOccurs="0" maxOccurs="unbounded"/>
       </xs:sequence>
     </xs:complexType>

     <xs:element name="deviceIdentity" type="heldDI:idParameters"/>

   </xs:schema>


     <error xmlns="urn:ietf:params:xml:ns:geopriv:held"
            code="badIdentifier" message="MAC address required"
            xml:lang="en">
       <requiredIdentifiers
           xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
         mac
       </requiredIdentifiers>
     </error>

                                 Figure 2: Schema 2

3.2.  Identifiers

   A limited selection of identifiers are included in this document.
   The basic Target identity schema allows for the inclusion of elements
   from any namespace, therefore additional elements can be defined
   using different XML namespaces.

3.2.1.  IP Address

   The "ip" element can express a Target identity as an IP address.  An
   optional "v" attribute identifies the IP version.  The element uses
   the textual format specific to the indicated IP version.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <ip v="6">2001:DB8::1:ea7:fee1:d1e</ip>
     </target>

   In situations where location configuration does not require
   additional identifiers, using IP address as an identifier enables
   third party requests.

3.2.2.  MAC Address

   The media access control (MAC) address used by the IEEE 802 family of
   access technologies is an identifier that is assigned to a particular
   network device.  A MAC address is a unique sequence that is either
   assigned at the time of manufacture of a device, or assigned by a
   local administrator.  A MAC address rarely changes; therefore, a MAC
   address is an appropriate identifier for a Device.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <mac>A0-12-34-56-78-90</mac>
     </target>







Winterbottom, et al.     Expires August 29, 2009                [Page 7]

Internet-Draft                HELD Identity                February 2009


3.2.3.  TCP or UDP Port Number

   On its own, a TCP or UDP port number is insufficient to uniquely
   identify a single host, but in combination with an IP address, it can
   be used to identify a Target.

   Use of a particular port number can be transient; often significantly
   more than use of any given IP address.  However, widespread use of
   network address translation (NAT) means that some Targets cannot be
   uniquely identified by IP address alone.  An individual Target might
   be identified by a flow of packets that it generates.  Providing that
   a LIS has sufficient knowledge of the mappings used by the NAT, an
   individual target on the remote side of the NAT might be able to be
   identified uniquely.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <ip v="6">2001:DB8::1:ea7:fee1:d1e</ip>
       <udpport>51393</udpport>
     </target>

   As with any identifier, use of port numbers is contingent on the
   value remaining consistent over time.  Use of port numbers is not
   suitable if port numbers cannot be deterministically attributed to a
   unique Target over a sufficient period of time.

3.2.4.  Network Access Identifier

   A Network Access Identifier (NAI) [RFC4282] is an identifier used in
   network authentication in a range of networks.  The identifier
   establishes a user identity within a particular domain.  Often,
   network services use an NAI in relation to location records, tying
   network access to user authentication and authorization.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <nai>user@example.net</nai>
     </target>

   Note:  The formal grammar for NAI permits invalid Unicode, which
      cannot be expressed using XML.  This is a known problem with that
      grammar.  Any NAI that contains invalid character sequences cannot
      be used as a Target identifier.

3.2.5.  URI

   A Target can be identified by a URI.  Any URI can be used providing
   that the requester and LIS have a common understanding of the
   semantics implied by use of the URI.




Winterbottom, et al.     Expires August 29, 2009                [Page 8]

Internet-Draft                HELD Identity                February 2009


     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <uri>sip:user@example.net;gr=kjh29x97us97d</uri>
     </target>

3.2.6.  Hostname

   A domain name can be used as the basis for identification using the
   "hostname" element.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <hostname>host.example.net</hostname>
     </target>

3.2.7.  Directory Number

   Telephony devices are typically identified by the number that is used
   to reach them.  Within enterprises, where globally accessible
   telephone numbers might not be used, a directory number is the usual
   form of identification.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <dn>7515</dn>
     </target>

3.2.8.  Cellular Telephony Identifiers

   A range of different forms of mobile station identifiers are used for
   different cellular telephony systems.  Elements are defined for these
   identifiers.  The following identifiers are defined:

   msisdn:  The Mobile Subscriber Integrated Services Digital Network
      Number (MSISDN) is an E.164 number between 6 and 15 digits long.

   imsi:  The International Mobile Subscriber Identity (IMSI) an
      identifier associated with all GSM and UMTS mobile subscribers.

   imei:  The International Mobile Equipment Identifier (IMEI) is a
      unique device serial number up to 15 digits long.

   min:  The Mobile Identification Number (MIN) is a unique number
      assigned to CDMA handsets.

   mdn:  The Mobile Directory Number (MDN) is an E.164 number, with
      usage similar to MSISDN.


     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <msisdn>11235550123</msisdn>



Winterbottom, et al.     Expires July 19, August 29, 2009                [Page 9]

Internet-Draft                HELD Identity                 January                February 2009


     </target>

3.2.9.  DHCP Unique Identifier

   The schema provided in Figure 2 allows a URI and/or token to be
   provided so that Dynamic Host Configuration Protocol (DHCP) uses a Target can identify itself by more than just binary
   identifier for its
   IP address. clients.  The URI can also include an optional "type" attribute so
   that URIs that might otherwise look the same can be distinguished
   based on their usage.

   For example <uri type="gruu">sip:callee@example.com</uri> or <uri
   type="aor">sip:callee@example.com</uri>

   An IANA registry DHCP Unique Identifier (DUID) is established for defining uri token types,
   expressed in Option 61 of DHCPv4 (see [RFC4361]) or Option 1 of
   DHCPv6 and
   this follows the format defined in Section 6.4.

   When the <identifier> 9 of [RFC3315].  The
   "duid" element is used the "type" attribute is
   mandatory as it tells the LIS or receiving entity how to interpret
   the identifier.  An IANA registry is established for includes the central
   repository for recognized identifier types.  The set binary value of initial types
   is provided in Section 6.3.

   A HELD location request sent by a device using the schema shown DUID expressed in
   Figure 2 to provide its identity as a MAC URI would look similar to
   Figure 3.

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
                    responseTime="8000">
     <locationType>geodetic</locationType>
     <deviceIdentity
   hexadecimal.

     <target xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
          <uri>mac:01-ab-34-ef-69-0c</uri>
     </deviceIdentity>
   </locationRequest>

                Figure 3: HELD Location Request URI example

   Similarly a Target identifying itself using its DHCP client
   identifier (DHCP option 61 in [RFC2132]) in a location request to a
   LIS would send something similar to Figure
       <duid>1234567890AaBbCcDdEeFf</duid>
     </target>

4.

   <locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"
                    responseTime="8000">
     <locationType>geodetic</locationType>
     <deviceIdentity xmlns="urn:ietf:params:xml:ns:geopriv:held:id">
       <identifier type="dhcpClientId">035552764</identifier>
     </deviceIdentity>
   </locationRequest>

            Figure 4:  XML Schema

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

    <!-- Target Identity -->
    <xs:element name="target" type="id:targetIdentity"/>
    <xs:complexType name="targetIdentity">
      <xs:sequence>
        <xs:any namespace="##any" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>

    <xs:element name="requiredIdentifiers" type="id:qnameList"/>
    <xs:simpleType name="qnameList">
      <xs:list itemType="xs:QName"/>
    </xs:simpleType>

    <xs:element name="ip" type="id:ipAddress"/>
    <xs:complexType name="ipAddress">
      <xs:simpleContent>
        <xs:extension base="xs:token">
          <xs:attribute name="v" use="optional">
            <xs:simpleType>
              <xs:restriction base="xs:token">
                <xs:pattern value="[\da-fA-F]"/>
              </xs:restriction>
            </xs:simpleType>



Winterbottom, et al.     Expires August 29, 2009               [Page 10]

Internet-Draft                HELD Location Request Identifier example Identity                February 2009


          </xs:attribute>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>

    <xs:element name="mac" type="id:macAddress"/>
    <xs:simpleType name="macAddress">
      <xs:restriction base="xs:token">
        <xs:pattern value="[\da-fA-F]{2}(-[\da-fA-F]{2}){5}"/>
      </xs:restriction>
    </xs:simpleType>

    <xs:element name="udpport" type="id:portNumber"/>
    <xs:element name="tcpport" type="id:portNumber"/>
    <xs:simpleType name="portNumber">
      <xs:restriction base="xs:nonNegativeInteger">
        <xs:maxInclusive value="65535"/>
      </xs:restriction>
    </xs:simpleType>

    <xs:element name="nai" type="xs:token"/>

    <xs:element name="uri" type="xs:anyURI"/>

    <xs:element name="dn" type="id:digits"/>
    <xs:simpleType name="digits">
      <xs:restriction base="xs:token">
        <xs:pattern value="[\d]+"/>
      </xs:restriction>
    </xs:simpleType>

    <xs:element name="hostname" type="id:domainName"/>
    <xs:simpleType name="domainName">
      <xs:restriction base="xs:token">
        <!-- the following pattern does not include whitespace;
             whitespace is added only to conform to document
             formatting restrictions -->
        <xs:pattern value="([A-Za-z\d]([A-Za-z\d-]*[A-Za-z\d])*\.)*
                           [A-Za-z\d]([A-Za-z\d-]*[A-Za-z\d])*"/>
      </xs:restriction>
    </xs:simpleType>

    <xs:element name="duid" type="xs:hexBinary"/>

    <xs:element name="msisdn" type="id:e164"/>
    <xs:element name="imsi" type="id:e164"/>
    <xs:element name="imei" type="id:digit15"/>
    <xs:element name="min" type="id:digit10"/>



Winterbottom, et al.     Expires July 19, August 29, 2009               [Page 10] 11]

Internet-Draft                HELD Identity                 January                February 2009


4.


    <xs:element name="mdn" type="id:e164"/>
    <xs:simpleType name="e164">
      <xs:restriction base="id:digit15">
        <xs:minLength value="6"/>
      </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="digit15">
      <xs:restriction base="id:digits">
        <xs:maxLength value="15"/>
      </xs:restriction>
    </xs:simpleType>
    <xs:simpleType name="digit10">
      <xs:restriction base="id:digits">
        <xs:length value="10"/>
      </xs:restriction>
    </xs:simpleType>

  </xs:schema>

5.  Privacy Considerations

   A location configuration protocol has a very simple privacy model.
   Because the requester is also the Target, it can be assumed that
   providing that requester with location information is allowed.  Such
   a policy  This
   "LCP policy" makes the simple assumption that as the subject of the
   location information, the Target is also permitted access to that
   information.  In effect, an LCP server (that is, the LIS) follows a
   single rule policy that states that the Target is the only authorized
   Location Recipient.

   Note:  HELD explicitly takes the position that the Target is a Device
      and not a person.  For the purpose of the discussion in related to
      privacy, this distinction is not important.  In this section, the two are considered one
      Target refers equally to Device and the same. person.

   When the Target identity extensions defined above are used by is used, the Target to
   augment an LCP query, this default "LCP policy" remains is only applicable if
   the identity of requester and Target are identical.  If the relevant
   policy,
   authenticated identity of the requester and the Target are the same,
   the security and privacy considerations of the base HELD protocol
   [I-D.ietf-geopriv-http-location-delivery] apply.  The only
   augmentation required is that if the LCP policy is to MAY be applied, the applied by a LIS.
   The LIS MUST NOT use LCP policy unless it can authenticate that the requested
   requester identity is in fact that of the requestor, same as the requested identity.  Requester
   and target identities MUST deny access be identical, related identities are not
   sufficient.

      For example, it is not appropriate to location apply LCP policy where a
      requester is authenticated by NAI and the supplied Target identity
      is a MAC address, even if that MAC address is currently registered



Winterbottom, et al.     Expires August 29, 2009               [Page 12]

Internet-Draft                HELD Identity                February 2009


      with the network under the given NAI.  In this
   authentication fails. case, the requester
      might be requesting from a different MAC address registered under
      the same NAI.  The correct way of gaining authorization is to
      establish a policy that permits this particular request as a third
      party request.

   The LCP policy does not allow requests made by third parties.  If a
   LIS permits requests from third parties using identity extensions, it
   assumes the rule of a Location Server (LS).  HELD becomes a more
   general location request protocol--a "using protocol" by the
   definitions in [RFC3693]--and the privacy considerations for using
   protocols apply.  As a Location Server, the LIS MUST explicitly
   authorize requests according to the policies that are provided by
   Rule Makers, including the Target.  This includes authentication of
   requesters where required by the authorization policies.

   An organization that provides a LIS that allows third party requests
   SHOULD provide a means for a Rule Maker to specify authorization
   policies before allowing third party requests for that Target's
   location.  Until an authorization policy is established, the LIS MUST
   reject requests by third parties.

   For a network operator, authorization might be a manual process, an
   explicit part of the terms of service for the network, or an
   automated system that accepts formal authorization policies (see
   [RFC4745], [RFC4825]).  This document does not mandate any particular
   mechanism for establishing an authorization policy.

   When the LIS is operated by the Target's access network, the
   relationship between the Target and the LIS can be transient.



Winterbottom, et al.      Expires July 19, 2009                [Page 11]

Internet-Draft                HELD Identity                 January 2009 be transient.
   However, the process of establishing network access usually results
   in a form of agreement between the Target and the network provider.
   This process offers a natural vehicle for establishing location
   privacy policies.















































Winterbottom, et al.      Expires July 19, 2009                [Page 12]

Internet-Draft                HELD Identity                 January 2009


5.  Establishing authorization policy might be a
   manual process, an explicit part of the terms of service for the
   network, or an automated system that accepts formal authorization
   policies (see [RFC4745], [RFC4825]).  This document does not mandate
   any particular mechanism for establishing an authorization policy.

6.  Security Considerations

   The security considerations in
   [I-D.ietf-geopriv-http-location-delivery] describe the use of TLS for
   server authentication, confidentiality and protection from
   modification.  These protections apply to both LCP requests and the
   requests made by third parties.

5.1.

   All HELD requests MUST be authenticated by the LIS.  How
   authentication is accomplished and what assurances are desired is a
   matter for policy.  The base HELD protocol uses return reachability--
   the proof of ownership of an IP address implied by the requester
   being able to successfully complete a TCP handshake.  It is
   RECOMMENDED that any means of authentication provide at least this
   degree of assurance.  [[MT: last sentence too subjective?]]  For



Winterbottom, et al.     Expires August 29, 2009               [Page 13]

Internet-Draft                HELD Identity                February 2009


   requests that include Target identity, the LIS MUST support
   authentication of TLS clients.

6.1.  Location Configuration Protocol Requests

   Requests made by a Device (or Target) in the context of a location configuration
   protocol are covered by the same set of protections offered by HELD.  All the security considerations for HELD apply.
   LCP requests are authorized under an "LCP policy" that permits a
   Target access to location information about itself.

   Identity information provided by the Device is private data that
   might be sensitive.  The Device provides this information in the
   expectation that it assists the LIS in providing the Device a
   service.  The LIS MUST NOT use identity information for any other
   purpose other than serving the request that includes that
   information.

   Falsification of identification information could be used by
   malicious Devices to gain access to location information for others,
   or to acquire false location information.  For location
   configuration, the LIS MUST ensure that claimed identity information
   belongs to the requester before relying upon it.  If this
   verification cannot be performed, the LIS MUST treat the request as
   if it were a third party request.

   Note:  This might seem to negate much of the advantage provided by
      the inclusion of identity parameters for the LCP case.  However,
      checking that the identity information is correct is generally
      more feasible than acquiring it assists the information LIS in providing the first place.

   For example, a MAC address provided by a target device can be
   verified by performing Device a DHCP lease-query ([RFC4388]).  Identity
   extensions such as tel: URIs and hostnames can be validated using
   network services such as
   service.  The LIS MUST NOT use identity information for any other
   purpose other than serving the DNS, ENUM, LDAP and SIP registrars.

5.2. request that includes that
   information.

6.2.  Third Party Requests

   Requests from third parties have the same requirements for server
   authentication, confidentiality and protection from modification as
   LCP requests.  However, because the third party needs to be
   authorized, the requester MUST be authenticated by the LIS.  The LIS
   MUST NOT provide location information to unauthorized requesters.

   A LIS that allows requests from third parties MUST support TLS client



Winterbottom, et al.      Expires July 19, 2009                [Page 13]

Internet-Draft                HELD Identity                 January 2009


   authentication.

   More detail on the privacy implications of  In
   addition, third party requests are
   covered in Section 4.

5.3.  Distinguishing LCP Requests from Third Party Requests

   There is a risk that a LIS that supports both LCP requests as well as
   requests from third parties could leak information.  To successfully
   exploit this leak, a third party could convince the server that its
   request is an LCP request and that the identity information it
   provides indeed belongs to it.  This could mean that the third party
   is exempted from the mandatory authorization process.

   A LIS that only provides LCP access to Targets is subject to the same
   attack.  If a Target can provide false identification information
   that is accepted by the LIS, it can effectively act as an MUST be explicitly authorized
   third party.

   This is limited by the ability of the LIS to detect falsified
   identity information.  Implementations need to take care to verify
   identity information as described in Section 5.1.

   For all requests, the LIS MUST ensure a
   policy that the requester is
   authorized to receive location information for the specified Target
   before providing that information.

























Winterbottom, et al.      Expires July 19, 2009                [Page 14]

Internet-Draft                HELD Identity                 January 2009


6. established by a Rule Maker.

   More detail on the privacy implications of third party requests are
   covered in Section 5.

7.  IANA Considerations

   This document registers an XML namespace and schema with IANA in
   accordance with guidelines in [RFC3688].  It also creates a new
   registry for device identity types, and stipulates how new types are
   to be added.

6.1.

7.1.  URN Sub-Namespace Registration for
      urn:ietf:params:xml:ns:geopriv:held:id

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

      URI: urn:ietf:params:xml:ns:geopriv:held:id

      Registrant Contact: IETF, GEOPRIV working group,
      (geopriv@ietf.org), James Winterbottom
      (james.winterbottom@andrew.com).



Winterbottom, et al.     Expires August 29, 2009               [Page 14]

Internet-Draft                HELD Identity                February 2009


      XML:

       BEGIN
         <?xml version="1.0"?>
         <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
           "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
         <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
           <head>
             <title>HELD Device Target Identity Extensions</title> Parameters</title>
           </head>
           <body>
             <h1>Namespace for HELD Device Target Identity Extensions</h1> Parameters</h1>
             <h2>urn:ietf:params:xml:ns:geopriv:held:id</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.

7.2.  XML Schema Registration

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







Winterbottom, et al.      Expires July 19, 2009                [Page 15]

Internet-Draft                HELD Identity                 January 2009

   URI:  urn:ietf:params:xml:schema:geopriv:held:id

   Registrant Contact:  IETF, GEOPRIV working group, (geopriv@ietf.org),
      James Winterbottom (james.winterbottom@andrew.com).

   Schema:  The XML for this schema can be found as the entirety of
      Figure 2 of this document.

6.3.  Identifier 'type' Attribute values

   This document requests that the IANA create a new registry for
   identifier 'type' attribute values.  These are text strings that
   clarify how the value identifies the Device.  Referring to [RFC5226]
   this registry operates under the "Expert Review" rule.

   The following identifier types are registered as part of this memo:

   dhcpClientId:  The DHCP client identifier as defined by DHCP option
      61 in [RFC2132]

   msisdn:  The Mobile Station International Subscriber Dial Number.
      This is an E.164 number made up of 6 to 15 digits

   imsi:  The International Mobile Subscriber identifier.  A unique
      identifier for GSM or UMTS mobile terminal made up of 6 to 15
      digits that identify the country code, the network code and
      device.

   imei:  The International Mobile Equipment identifier.  This is an
      electronic serial number for a mobile device and is consists of up
      to 15 digits

   min:  Mobile Identification Number.  A unique equipment identifier
      assigned to CDMA handsets.

   mdn:  Mobile Dial Number.  An E.164 number made up of 6 to 15 digits.

   hostname:  The hostname or FQDN of the device.

   directoryNumber:  The directory number of the device.

6.4.  URI Type Attribute Values

   This document requests that the IANA create a new registry for uri
   'type' attribute values.  These are text strings that clarify what a
   URI actually identifies, and MUSt include the URI scheme to which the
   type applies.  Referring to [RFC5226] this registry operates under
   the "Expert Review" rule.



Winterbottom, et al.      Expires July 19, 2009                [Page 16]

Internet-Draft                HELD Identity                 January 2009


   The following identifier types are registered schema can be found as part the entirety of
      Section 4 of this memo:

   aor:  The SIP address document.

7.3.  Registration of record as defined [RFC3261].  Applies to
      'sip:', 'sips:', 'pres:'

   gruu:  The Globally Routable User Agent URI (GRUU) as defined HELD 'badIdentifier' Error Code

   This section registers the "badIdentifier" error code in
      [I-D.ietf-sip-gruu].  Applies to 'sip:', 'sips:'












































Winterbottom, et al.      Expires July 19, 2009                [Page 17]

Internet-Draft the "Geopriv
   HELD Identity                 January 2009


7. Registries, Error codes for HELD" IANA registry.

   badIdentifier  This error code indicates that the Target identifiers
      used in the HELD request were either: not supported by the LIS,
      badly formatted, or that the requester was not authorized to make
      a erquest for that identifier.

8.  Acknowledgements

   The authors wish to thank the NENA VoIP location working group for
   their assistance in the definition of the schema used in this
   document.  Special thanks go to Barbara Stark, Guy Caron, Nadine



Winterbottom, et al.     Expires August 29, 2009               [Page 15]

Internet-Draft                HELD Identity                February 2009


   Abbott, Jerome Grenier and Martin Dawson.  Thanks also to  Bob Sherry
   for requesting that URI-types be supported which led to the typedURI
   form. provided input
   on use of URIs.  Thanks to Adam Muhlbauer and Eddy Corbett for
   providing further corrections.










































Winterbottom, et al.      Expires July 19, 2009                [Page 18]

Internet-Draft                HELD Identity                 January 2009


8.  Bernard Aboba provided extensive
   feedback on use cases and the security model; Bernard, along with
   Alan DeKok, also helped resolve an issue with NAIs.  Ray Bellis
   provided motivation for the protocol port parameters.

9.  References

8.1.

9.1.  Normative references

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

   [RFC3315]                                  Droms, R., Bound, J.,
                                              Volz, B., Lemon, T.,
                                              Perkins, C., and M.
                                              Carney, "Dynamic Host
                                              Configuration Protocol for
                                              IPv6 (DHCPv6)", RFC 3315,
                                              July 2003.

   [RFC3688]                                  Mealling, M., "The IETF
                                              XML Registry", BCP 81,
                                              RFC 3688, January 2004.

   [I-D.ietf-geopriv-http-location-delivery]
              Barnes,

   [RFC4282]                                  Aboba, B., Beadles, M., Winterbottom,
                                              Arkko, J., Thomson, M., and B. Stark,
              "HTTP Enabled Location Delivery (HELD)",
              draft-ietf-geopriv-http-location-delivery-11 (work in
              progress), December 2008.

   [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-08 (work in
              progress), June 2008.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66, Eronen,
                                              "The Network Access
                                              Identifier", RFC 3986, January 4282,
                                              December 2005.

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining

   [RFC4361]                                  Lemon, T. and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation B.
                                              Sommerfeld, "Node-specific
                                              Client Identifiers for
                                              Dynamic Host Configuration
                                              Protocol
              (SIP)", draft-ietf-sip-gruu-15 (work in progress),
              October 2007.

8.2.  Informative references

   [RFC3693]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
              J. Polk, "Geopriv Requirements", Version Four
                                              (DHCPv4)", RFC 3693, 4361,
                                              February 2004.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997. 2006.

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



Winterbottom, et al.     Expires July 19, August 29, 2009               [Page 19] 16]

Internet-Draft                HELD Identity                 January                February 2009


   [I-D.ietf-ecrit-phonebcp]
              Rosen, B. and J. Polk, "Best Current Practice for
              Communications Services in support of Emergency  Calling",
              draft-ietf-ecrit-phonebcp-06


                                              location-delivery-12 (work
                                              in progress),
              November 2008.

   [I-D.thomson-geopriv-held-measurements]
              Thomson, M.
                                              January 2009.

   [I-D.ietf-geopriv-l7-lcp-ps]               Tschofenig, H. and J. Winterbottom, "Using Device-provided
              Location-Related Measurements in H.
                                              Schulzrinne, "GEOPRIV
                                              Layer 7 Location
                                              Configuration
              Protocols", draft-thomson-geopriv-held-measurements-03 Protocol;
                                              Problem Statement and
                                              Requirements", draft-ietf-
                                              geopriv-l7-lcp-ps-09 (work
                                              in progress), October 2008.

   [RFC5226]  Narten, T.
                                              February 2009.

   [W3C.REC-xml-names11-20060816]             Tobin, R., Layman, A.,
                                              Bray, T., and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section D.
                                              Hollander, "Namespaces in RFCs", BCP 26, RFC 5226,
              May 2008.

   [LLDP]     IEEE, "802.1AB, IEEE Standard for Local and Metropolitan
              area networks, Station and Media Access Control
              Connectivity Discovery", June 2005.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC4479]  Rosenberg,
                                              XML 1.1 (Second Edition)",
                                              World Wide Web Consortium
                                              Recommendation REC-xml-
                                              names11-20060816,
                                              August 2006, <http://
                                              www.w3.org/TR/2006/
                                              REC-xml-names11-20060816>.

9.2.  Informative references

   [RFC3693]                                  Cuellar, J., Morris, J.,
                                              Mulligan, D., Peterson,
                                              J., "A Data Model for Presence", RFC 4479,
              July 2006.

   [RFC4388]  Woundy, R. and K. Kinnear, "Dynamic Host Configuration
              Protocol (DHCP) Leasequery", J. Polk, "Geopriv
                                              Requirements", RFC 4388, 3693,
                                              February 2006. 2004.

   [RFC3825]                                  Polk, J., Schnizlein, J.,
                                              and M. Linsner, "Dynamic
                                              Host Configuration
                                              Protocol Option for
                                              Coordinate-based Location
                                              Configuration
                                              Information", RFC 3825,
                                              July 2004.

   [RFC4825]  Rosenberg, J., "The Extensible Markup Language (XML)

   [RFC4388]                                  Woundy, R. and K. Kinnear,
                                              "Dynamic Host
                                              Configuration Access Protocol (XCAP)",
                                              (DHCP) Leasequery",
                                              RFC 4825, May 2007. 4388, February 2006.




Winterbottom, et al.     Expires August 29, 2009               [Page 17]

Internet-Draft                HELD Identity                February 2009


   [RFC4745]                                  Schulzrinne, H.,
                                              Tschofenig, H., Morris,
                                              J., Cuellar, J., Polk, J.,
                                              and J. Rosenberg, "Common
                                              Policy: A Document Format
                                              for Expressing Privacy
                                              Preferences", RFC 4745,
                                              February 2007.

   [RFC4776]                                  Schulzrinne, H., "Dynamic
                                              Host Configuration
                                              Protocol (DHCPv4 and
                                              DHCPv6) Option for Civic
                                              Addresses Configuration
                                              Information", RFC 4776,
                                              November 2006.

   [RFC4825]                                  Rosenberg, J., "The
                                              Extensible Markup Language
                                              (XML) Configuration Access
                                              Protocol (XCAP)",
                                              RFC 4825, May 2007.

   [I-D.ietf-ecrit-phonebcp]                  Rosen, B. and J. Polk,
                                              "Best Current Practice for
                                              Communications Services in
                                              support of Emergency
                                              Calling", draft-ietf-
                                              ecrit-phonebcp-07 (work in
                                              progress), January 2009.

   [I-D.thomson-geopriv-held-measurements]    Thomson, M. and J.
                                              Winterbottom, "Using
                                              Device-provided Location-
                                              Related Measurements in
                                              Location  Configuration
                                              Protocols", draft-thomson-
                                              geopriv-held-measurements-
                                              03 (work in progress),
                                              October 2008.

   [LLDP]                                     IEEE, "802.1AB, IEEE
                                              Standard for Local and
                                              Metropolitan area
                                              networks, Station and
                                              Media Access Control
                                              Connectivity Discovery",
                                              June 2005.



Winterbottom, et al.     Expires July 19, August 29, 2009               [Page 20] 18]

Internet-Draft                HELD Identity                 January                February 2009


Authors' Addresses

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

   Email:

   EMail: james.winterbottom@andrew.com


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

   Email:

   EMail: martin.thomson@andrew.com


   Hannes Tschofenig
   Nokia Siemens Networks
   Linnoitustie 6
   Espoo  02600
   Finland

   Phone: +358 (50) 4871445
   Email:
   EMail: Hannes.Tschofenig@gmx.net
   URI:   http://www.tschofenig.priv.at


   Richard Barnes
   BBN Technologies
   9861 Broken Land Pkwy, Suite 400
   Columbia, MD  21046
   USA

   Phone: +1 410 290 6169
   Email:
   EMail: rbarnes@bbn.com












Winterbottom, et al.     Expires July 19, August 29, 2009               [Page 21] 19]


----