GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4119

Network Working Group J. Peterson Request for Comments: 4119 NeuStar Category: Standards Track December 2005

          A Presence-based GEOPRIV Location Object Format

Status of This Memo

 This document specifies an Internet standards track protocol for the
 Internet community, and requests discussion and suggestions for
 improvements.  Please refer to the current edition of the "Internet
 Official Protocol Standards" (STD 1) for the standardization state
 and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

 Copyright (C) The Internet Society (2005).

Abstract

 This document describes an object format for carrying geographical
 information on the Internet.  This location object extends the
 Presence Information Data Format (PIDF), which was designed for
 communicating privacy-sensitive presence information and which has
 similar properties.

Peterson Standards Track [Page 1] RFC 4119 GEOPRIV Location Object December 2005

Table of Contents

 1. Introduction ....................................................2
    1.1. Conventions Used in This Document ..........................3
 2. Location Object Format ..........................................4
    2.1. Baseline PIDF Usage ........................................4
    2.2. Extensions to PIDF for Location and Usage Rules ............5
         2.2.1. 'location-info' Element .............................5
         2.2.2. 'usage-rules' Element ...............................7
         2.2.3. 'method' Element ....................................9
         2.2.4. 'provided-by' Element ...............................9
         2.2.5. Schema Definitions .................................10
    2.3. Example Location Objects ..................................14
 3. Carrying PIDF in a Using Protocol ..............................15
 4. Securing PIDF ..................................................15
 5. Security Considerations ........................................17
 6. IANA Considerations ............................................17
    6.1. 'method' Tokens ...........................................17
    6.2. 'provided-by' Elements ....................................18
    6.3. URN Sub-Namespace Registration for
         urn:ietf:params:xml:ns:pidf:geopriv10 .....................18
 7. Acknowledgements ...............................................19
 A. Appendix: NENA Provided-by Schema ..............................20
    A.1. dataProvider XML Schema ...................................21
 Normative References ..............................................22
 Informative References ............................................22

1. Introduction

 Geographical location information describes a physical position in
 the world that may correspond to the past, present, or future
 location of a person, event, or device.  Numerous applications used
 in the Internet today benefit from sharing location information
 (including mapping/navigation applications, 'friend finders' on cell
 phones, and so on).  However, such applications may disclose the
 whereabouts of a person in a manner contrary to the user's
 preferences.  Privacy lapses may result from poor protocol security
 (which permits eavesdroppers to capture location information),
 inability to articulate or accommodate user preferences, or similar
 defects common in existing systems.  The privacy concerns surrounding
 the unwanted disclosure of a person's physical location are among the
 more serious issues that confront users on the Internet.
 Consequently, a need has been identified to convey geographical
 location information within an object that includes a user's privacy
 and disclosure preferences and which is protected by strong
 cryptographic security.  Previous work [13] has observed that this
 problem bears some resemblance to the general problem of

Peterson Standards Track [Page 2] RFC 4119 GEOPRIV Location Object December 2005

 communicating and securing presence information on the Internet.
 Presence (defined in [12]) provides a real-time communications
 disposition for a user, and thus has similar requirements for
 selective distribution and security.
 Therefore, this document extends the XML-based Presence Information
 Data Format (PIDF [2]) to allow the encapsulation of location
 information within a presence document.
 This document does not invent any format for location information
 itself.  Numerous existing formats based on civic location,
 geographic coordinates, and the like, have been developed in other
 standards fora.  Instead, this document defines an object that is
 suitable both for identifying and encapsulating preexisting location
 information formats, and for providing adequate security and policy
 controls to regulate the distribution of location information over
 the Internet.
 The location object described in this document can be used
 independently of any 'using protocol', as the term is defined in the
 GEOPRIV requirements [10].  It is considered an advantage of this
 proposal that existing presence protocols (such as [14]) would
 natively accommodate the location object format defined in this
 document, and be capable of composing location information with other
 presence information, because this location object is an extension of
 PIDF.  However, the usage of this location object format is not
 limited to presence-using protocols-- any protocol that can carry XML
 or MIME types can carry PIDF.
 Some of the requirements in [10] and [11] concern data collection and
 usage policies associated with location objects.  This document
 provides only the minimum markup necessary for a user to express the
 necessary privacy preferences as specified by the GEOPRIV
 requirements (the three basic elements in [11]).  However, this
 document does not demonstrate how a full XML-based ruleset,
 accommodating the needs of Location Servers, could be embedded in
 PIDF.  It is assumed that other protocols (such as HTTP) will be used
 to move rules between Rule Holders and Location Servers, and that
 full rulesets will be defined in a separate document.

1.1. Conventions Used in This Document

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [1].

Peterson Standards Track [Page 3] RFC 4119 GEOPRIV Location Object December 2005

2. Location Object Format

2.1. Baseline PIDF Usage

 The GEOPRIV requirements [10] (or REQ for short) specify the need for
 a name for the person, place or thing that location information
 describes (REQ 2.1).  PIDF has such an identifier already:  every
 PIDF document has an "entity" attribute of the 'presence' element
 that signifies the URI of the entity whose presence the document
 describes.  Consequently, if location information is contained in a
 PIDF document, the URI in the "entity" attribute of the 'presence'
 element indicates the target of that location information (the
 'presentity').  The URI in the "entity" attribute generally uses the
 "pres" URI scheme defined in [3].  Such URIs can serve as unlinkable
 pseudonyms (per REQ 12).
 PIDF optionally contains a 'contact' element that provides a URI
 where the presentity can be reached by some means of communication.
 Usually, the URI scheme in the value of the 'contact' element gives
 some sense of how the presentity can be reached; if it uses the SIP
 URI scheme, for example, SIP can be used, and so on.  Location
 information can be provided without any associated means of
 communication.  Thus, the 'contact' element may or may not be
 present, as desired by the creator of the PIDF document.
 PIDF optionally contains a 'timestamp' element that designates the
 time at which the PIDF document was created.  This element
 corresponds to REQ 2.7a.
 PIDF contains a 'status' element, which is mandatory.  'status'
 contains an optional child element, 'basic', that describes the
 presentity's communications disposition (in very broad terms: either
 OPEN or CLOSED).  For the purposes of this document, it is not
 necessary for 'basic' status to be included.  If, however,
 communications disposition is included in a PIDF document above and
 beyond geolocation, then 'basic' status may appear in a PIDF document
 that uses these extensions.
 PIDF also contains a 'tuple' umbrella element, which holds an "id"
 element used to uniquely identify a segment of presence information
 so that changes to this information can be tracked over time (as
 multiple notifications of presence are received).  'timestamp',
 'status', and 'contact' are composed under 'tuple'.

Peterson Standards Track [Page 4] RFC 4119 GEOPRIV Location Object December 2005

2.2. Extensions to PIDF for Location and Usage Rules

 This XML Schema extends the 'status' element of PIDF with a complex
 element called 'geopriv'.  There are two major subelements that are
 encapsulated within geopriv: one for location information, and one
 for usage rules.  Both of these subelements are mandatory, and are
 described in subsequent sections.  By composing these two subelements
 under 'geopriv', the usage rules are clearly and explicitly
 associated with the location information.
 For extensibility (see REQ 1.4), the schema allows any other
 subelements to appear under the 'geopriv' element.  Two other
 optional subelements are included in this document: one that
 indicates the method by which geographical location was determined,
 and one that allows an explicit designation of the entity that
 provided the information.

2.2.1. 'location-info' Element

 Each 'geopriv' element MUST contain one 'location-info' element.  A
 'location-info' element consists of one or more chunks of location
 information (per REQ 2.5).  The format of the location information
 (REQ 2.6) is identified by the imported XML Schema, which describes
 the namespace in question.  All PIDF documents that contain a
 'geopriv' element MUST contain one or more import directives
 indicating the XML Schema(s) that are used for geographic location
 formats.
 In order to ensure interoperability of GEOPRIV implementations, it is
 necessary to select a baseline location format that all compliant
 implementations support (see REQ 3.1).  Because it satisfies REQ
 2.5.1, this document works from the assumption that Geography Markup
 Language (GML) 3.0 [15] shall be this mandatory format (a MUST
 implement for all PIDF implementations supporting the 'geopriv'
 element).
 GML is an extraordinarily thorough and versatile system for modeling
 all manner of geographic object types, topologies, metadata,
 coordinate reference systems, and units of measurement.  The simplest
 package for GML supporting location
 information is the 'feature.xsd' schema.  Although 'feature.xsd' can
 express complicated geographical concepts, it requires very little
 markup to provide basic coordinate points for the most commonly used
 cases.  Various format descriptions (including latitude/longitude
 based location information) are supported by Feature (see section
 7.4.1.4 of [15] for examples), which resides here:

Peterson Standards Track [Page 5] RFC 4119 GEOPRIV Location Object December 2005

    urn:opengis:specification:gml:schema-xsd:feature:v3.0
 Note that by importing the Feature schema, necessary GML baseline
 schemas are transitively imported.
 Complex features (such as modeling topologies and polygons,
 directions and vectors, temporal indications of the time for which a
 particular location is valid for a target) are also available in GML,
 but require importing additional schemas.  For the purposes of
 baseline interoperability as defined by this document, only support
 for the 'feature.xsd' GML schema is REQUIRED.
 Implementations MAY support the civic location format (civicLoc)
 defined in Section 2.2.5.  civicLoc provides the following elements:
 +----------------------+----------------------+---------------------+
 | Label                | Description          | Example             |
 +----------------------+----------------------+---------------------+
 | country              | The country is       | US                  |
 |                      | identified by the    |                     |
 |                      | two-letter ISO 3166  |                     |
 |                      | code.                |                     |
 |                      |                      |                     |
 | A1                   | national             | New York            |
 |                      | subdivisions (state, |                     |
 |                      | region, province,    |                     |
 |                      | prefecture)          |                     |
 |                      |                      |                     |
 | A2                   | county, parish, gun  | King's County       |
 |                      | (JP), district (IN)  |                     |
 |                      |                      |                     |
 | A3                   | city, township, shi  | New York            |
 |                      | (JP)                 |                     |
 |                      |                      |                     |
 | A4                   | city division,       | Manhattan           |
 |                      | borough, city        |                     |
 |                      | district, ward, chou |                     |
 |                      | (JP)                 |                     |
 |                      |                      |                     |
 | A5                   | neighborhood, block  | Morningside Heights |
 |                      |                      |                     |
 | A6                   | street               | Broadway            |
 |                      |                      |                     |
 | PRD                  | Leading street       | N, W                |
 |                      | direction            |                     |
 |                      |                      |                     |
 | POD                  | Trailing street      | SW                  |
 |                      | suffix               |                     |

Peterson Standards Track [Page 6] RFC 4119 GEOPRIV Location Object December 2005

 |                      |                      |                     |
 | STS                  | Street suffix        | Avenue, Platz,      |
 |                      |                      | Street              |
 |                      |                      |                     |
 | HNO                  | House number,        | 123                 |
 |                      | numeric part only.   |                     |
 |                      |                      |                     |
 | HNS                  | House number suffix  | A, 1/2              |
 |                      |                      |                     |
 | LMK                  | Landmark or vanity   | Low Library         |
 |                      | address              |                     |
 |                      |                      |                     |
 | LOC                  | Additional location  | Room 543            |
 |                      | information          |                     |
 |                      |                      |                     |
 | FLR                  | Floor                | 5                   |
 |                      |                      |                     |
 | NAM                  | Name (residence,     | Joe's Barbershop    |
 |                      | business or office   |                     |
 |                      | occupant)            |                     |
 |                      |                      |                     |
 | PC                   | Postal code          | 10027-0401          |
 +----------------------+----------------------+---------------------+
 Either the GML 3.0 geographical information format element, or the
 location format element ('civicLoc') defined in this document, MAY
 appear in a 'location-info' element.  Both MAY also be used in the
 same 'location-info' element.  In summary, the feature.xsd schema of
 GML 3.0 MUST be supported by implementations compliant with this
 specification, and the civicLoc format MAY be supported by
 implementations compliant with this specification.

2.2.2. 'usage-rules' Element

 At the time this document was written, the policy requirements for
 GEOPRIV objects were not definitively completed.  However, the
 'usage-rules' element exists to satisfy REQ 2.8 and the requirements
 of the GEOPRIV policy requirements [11] document.  Each 'geopriv'
 element MUST contain one 'usage-rules' element, even if the Rule
 Maker has requested that all subelements be given their default
 values.
 Following the policy requirements document (Section 3.1), there are
 three fields that need to be expressible in Location Objects
 throughout their lifecycle (from Generator to Recipient):  one field
 that limits retransmission, one that limits retention, and one that
 contains a reference to external rulesets.  Those three fields are

Peterson Standards Track [Page 7] RFC 4119 GEOPRIV Location Object December 2005

 instantiated here by the first three elements.  The fourth element
 provides a generic space for human-readable policy directives.  Any
 of these fields MAY be present in a Location Object 'usage-rules'
 element; none are required to be.
 'retransmission-allowed': When the value of this element is 'no', the
    Recipient of this Location Object is not permitted to share the
    enclosed Location Information, or the object as a whole, with
    other parties.  When the value of this element is 'yes',
    distributing this Location is permitted (barring an existing out-
    of-band agreement or obligation to the contrary).  By default, the
    value MUST be assumed to be 'no'.  Implementations MUST include
    this field, with a value of 'no', if the Rule Maker specifies no
    preference.
 'retention-expires': This field specifies an absolute date at which
    time the Recipient is no longer permitted to possess the location
    information and its encapsulating Location Object; both may be
    retained only until the time specified by this field.  By default,
    the value MUST be assumed to be twenty-four hours from the
    'timestamp' element in the PIDF document, if present; if the
    'timestamp' element is also not present, then the value MUST be
    assumed to be twenty-four hours from the time at which the
    Location Object is received by the Location Recipient.  If the
    value in the 'retention-expires' element has already passed when
    the Location Recipient receives the Location Object, the Recipient
    MUST discard the Location Object immediately.
 'ruleset-reference': This field contains a URI that indicates where a
    fuller ruleset of policies, related to this object, can be found.
    This URI SHOULD use the HTTPS URI scheme; and if it does, the
    server that holds these rules MUST authenticate any attempt to
    access these rules.  Usage rules themselves may divulge private
    information about a Target or Rule Maker.  The URI MAY,
    alternatively, use the CID URI scheme [7], in which case it MUST
    denote a MIME body carried with the Location Object by the using
    protocol.  Rulesets carried as MIME bodies SHOULD be encrypted and
    signed by the Rule Maker; unsigned rulesets SHOULD NOT be honored
    by Location Servers or Location Recipients.  Note that in order to
    avoid network lookups that result in an authorization failure,
    creators of Location Objects MAY put HTTPS-based ruleset-
    references into an encrypted external MIME body referenced by a
    CID; in this way, recipients of the Location Object that are
    unable to decrypt the external MIME body will not learn the HTTPS
    URI unless they are able to decrypt the MIME body.

Peterson Standards Track [Page 8] RFC 4119 GEOPRIV Location Object December 2005

 'note-well': This field contains a block of text containing further
    generic privacy directives.  These directives are intended to be
    human-readable only, not to be processed by any automaton.

2.2.3. 'method' Element

 The optional 'method' element describes the way that the location
 information was derived or discovered.  An example of this element
 (for a geographical position system) is:
        <method>gps</method>
 The possible values of the 'method' element are enumerated within an
 IANA registry.  Implementations MUST limit the use of this method to
 the values shepherded by IANA.  This document pre-populates the IANA
 registry with seven possible values; see Section 6.1 for more
 information.
 The 'method' element is useful, for example, when multiple sources
 are reporting location information for a given user, and some means
 of determining location might be considered more authoritative than
 others (i.e., a dynamic, real-time position system versus static
 provisioning associated with a target device).  However, note that
 inclusion of 'method' might reveal sensitive information when the
 generator is providing intentionally coarsened location information.
 For example, when a LO is transmitted with 'DHCP' as the 'method',
 but the location information indicates only the city in which the
 generator is located, the sender has good justification to suspect
 that some location information is being withheld.

2.2.4. 'provided-by' Element

 The optional 'provided-by' element describes the entity or
 organization that supplied this location information (beyond the
 domain information that can be inferred from a signing certificate).
 An example of this element (for a made-up game system) might be:
        <provided-by>
           <test:game>
              West5
           </test:game>
        </provided-by>
 Values for the 'provided-by' element MUST be IANA-registered XML
 namespaces; see Section 6.2 for more information.

Peterson Standards Track [Page 9] RFC 4119 GEOPRIV Location Object December 2005

 The 'provided-by' element is not intended for use by most entities,
 but rather to meet special requirements for which overhead (IANA
 registration, location object size) and potential location
 information leakage are acceptable choices.
 In general cases, the entity that supplied location information is
 communicated by the subjectAltName of the certificate with which the
 location object is signed; thus, this element is unnecessary.
 'Provided-by' is meaningful in particular cases when the creator of a
 location object wants to designate a particular system or party
 within a complex administrative domain, including situations
 envisioned for providing emergency services in a diverse national
 context.  It might assist, for example, the recipient of a malformed
 or misleading location object in identifying the particular system
 that malfunctioned.
 Users should be aware that this information can inadvertently provide
 additional information to the receiver, increasing the effective
 resolution of the geospatial or civic information, or even revealing
 some location information, when it was meant to be entirely
 protected.  Consider if there were circumstances that influenced
 Columbia University to elect to register and use the provided-by
 element.  If an example LO includes only state-level information,
 then including the fact that the location information was provided by
 Columbia University provides a strong indication that the Target is
 actually located in a four-block area in Manhattan.  Accordingly,
 this element should be used only when organizational functions
 strongly would depend on it.  In all but such usages, the
 subjectAltName of the certificate will suffice, and 'provided-by'
 SHOULD NOT be used.

2.2.5. Schema Definitions

 Note that the XML namespace [4] for this extension to PIDF contains a
 version number 1.0 (as per REQ 2.10).
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema
   targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10"
   xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10"
   xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified" attributeFormDefault="unqualified">
 <xs:import namespace=
      "urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" />
    <!-- This import brings in the XML language attribute xml:lang-->

Peterson Standards Track [Page 10] RFC 4119 GEOPRIV Location Object December 2005

    <xs:import namespace="http://www.w3.org/XML/1998/namespace"
      schemaLocation="http://www.w3.org/2001/xml.xsd"/>
    <xs:element name="geopriv" type="tns:geopriv"/>
 <xs:complexType name="geopriv">
  <xs:sequence>
    <xs:element name="location-info" type="tns:locInfoType"
       minOccurs="1" maxOccurs="1"/>
    <xs:element name="usage-rules" type="gbp:locPolicyType"
       minOccurs="1" maxOccurs="1"/>
    <xs:element name="method" type="tns:locMethod"
       minOccurs="0" maxOccurs="1"/>
    <xs:element name="provided-by" type="tns:locProvidedBy"
       minOccurs="0" maxOccurs="1"/>
    <xs:any namespace="##other" processContents="lax" minOccurs="0"
       maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>
 <xs:complexType name="locInfoType">
  <xs:sequence>
    <xs:any namespace="##other" processContents="lax" minOccurs="0"
       maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>
 <xs:complexType name="locMethod">
   <xs:simpleContent>
     <xs:extension base="xs:string">
       <xs:attribute ref="xml:lang" />
     </xs:extension>
   </xs:simpleContent>
 </xs:complexType>
 <xs:complexType name="locProvidedBy">
  <xs:sequence>
    <xs:any namespace="##other" processContents="skip"
       minOccurs="1" maxOccurs="unbounded"/>
  </xs:sequence>
 </xs:complexType>
 </xs:schema>
 The 'geopriv10' schema imports, for the 'usage-rules' element, the
 following policy schema.  This schema has been broken out from the
 basic geolocation object in order to allow for its reuse.  The
 semantics associated with these elements, described in Section 2.2.2,

Peterson Standards Track [Page 11] RFC 4119 GEOPRIV Location Object December 2005

 apply only to the use of these elements to define policy for
 geolocation objects; any other use of 'usage-rules' must characterize
 its own semantics for all 'usage-rules' subelements.

<?xml version="1.0" encoding="UTF-8"?> <xs:schema

targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
  schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:complexType name="locPolicyType">
 <xs:sequence>
   <xs:element name="retransmission-allowed" type="xs:boolean"
      minOccurs="0" maxOccurs="1"/>
   <xs:element name="retention-expiry" type="xs:dateTime"
      minOccurs="0" maxOccurs="1"/>
   <xs:element name="external-ruleset" type="xs:anyURI"
      minOccurs="0" maxOccurs="1"/>
   <xs:element name="note-well" type="tns:notewell"
      minOccurs="0" maxOccurs="1"/>
   <xs:any namespace="##other" processContents="lax" minOccurs="0"
      maxOccurs="unbounded"/>
 </xs:sequence>
</xs:complexType>
  <xs:complexType name="notewell">
     <xs:simpleContent>
       <xs:extension base="xs:string">
         <xs:attribute ref="xml:lang" />
       </xs:extension>
     </xs:simpleContent>
  </xs:complexType>

</xs:schema>

 The following schema is a trivial representation of civic location
 that MAY be implemented by entities compliant with this
 specification.
 <?xml version="1.0" encoding="UTF-8"?>
 <xs:schema
   targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
   xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"

Peterson Standards Track [Page 12] RFC 4119 GEOPRIV Location Object December 2005

   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   elementFormDefault="qualified" attributeFormDefault="unqualified">
    <xs:complexType name="civicAddress">
     <xs:sequence>
       <xs:element name="country" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="A1" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="A2" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="A3" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="A4" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="A5" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="A6" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="PRD" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="POD" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="STS" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="HNO" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="HNS" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="LMK" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="LOC" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="FLR" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="NAM" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:element name="PC" type="xs:string"
          minOccurs="0" maxOccurs="1"/>
       <xs:any namespace="##other" processContents="lax" minOccurs="0"
          maxOccurs="unbounded"/>
     </xs:sequence>
    </xs:complexType>
    </xs:schema>

Peterson Standards Track [Page 13] RFC 4119 GEOPRIV Location Object December 2005

2.3. Example Location Objects

 Note that these examples show PIDF documents without any MIME headers
 or security applied to them (see Section 4 below).
 The following XML instance document is an example of the use of a
 simple GML 3.0 markup with a few of the policy directives specified
 above within a PIDF document.  The GPS coordinates given in the 'gml'
 element are for San Francisco, CA.

<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf"

  xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
  xmlns:gml="urn:opengis:specification:gml:schema-xsd:feature:v3.0"
  entity="pres:geotarget@example.com">
<tuple id="sg89ae">
 <status>
  <gp:geopriv>
    <gp:location-info>
      <gml:location>
        <gml:Point gml:id="point1" srsName="epsg:4326">
          <gml:coordinates>37:46:30N 122:25:10W</gml:coordinates>
        </gml:Point>
       </gml:location>
    </gp:location-info>
    <gp:usage-rules>
      <gp:retransmission-allowed>no</gp:retransmission-allowed>
      <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
    </gp:usage-rules>
  </gp:geopriv>
 </status>
 <timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>

</presence>

 The following XML instance document is an example of the use of the
 civicLoc object with a few of the policy directives specified above
 within a PIDF document.

<?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf"

  xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
  xmlns:cl=" urn:ietf:params:xml:ns:pidf:geopriv10:civicLoc"
  entity="pres:geotarget@example.com">
<tuple id="sg89ae">
 <status>
  <gp:geopriv>
    <gp:location-info>

Peterson Standards Track [Page 14] RFC 4119 GEOPRIV Location Object December 2005

      <cl:civicAddress>
        <cl:country>US</cl:country>
        <cl:A1>New York</cl:A1>
        <cl:A3>New York</cl:A3>
        <cl:A6>Broadway</cl:A6>
        <cl:HNO>123</cl:HNO>
        <cl:LOC>Suite 75</cl:LOC>
        <cl:PC>10027-0401</cl:PC>
      </cl:civicAddress>
    </gp:location-info>
    <gp:usage-rules>
      <gp:retransmission-allowed>yes</gp:retransmission-allowed>
      <gp:retention-expiry>2003-06-23T04:57:29Z</gp:retention-expiry>
    </gp:usage-rules>
  </gp:geopriv>
 </status>
 <timestamp>2003-06-22T20:57:29Z</timestamp>
</tuple>

</presence>

3. Carrying PIDF in a Using Protocol

 A PIDF document is an XML document; therefore, PIDF might be carried
 in any protocol capable of carrying XML.  A MIME type has also been
 registered for PIDF: 'application/pidf+xml'.  PIDF may therefore be
 carried as a MIME body in protocols that use MIME (such as SMTP,
 HTTP, or SIP) with an encapsulating set of MIME headers, including a
 Content-Type of 'application/pidf+xml'.
 Further specification of the behavior of using protocols (including
 subscribing to or requesting presence information) is outside the
 scope of this document.

4. Securing PIDF

 There are a number of ways in which XML documents can be secured.
 XML itself supports several ways of partially securing documents,
 including element-level encryption and digital signature properties.
 For the purposes of this document, only the securing of a PIDF
 document as a whole, rather than element-by-element security, is
 considered.  None of the requirements [10] suggest that only part of
 the information in a location object might need to be protected while
 other parts are unprotected; virtually any such configuration would
 introduce potentials for privacy leakage.  Consequently, the use of
 MIME-level security is appropriate.

Peterson Standards Track [Page 15] RFC 4119 GEOPRIV Location Object December 2005

 S/MIME [5] allows security properties (including confidentiality,
 integrity, and authentication properties) to be applied to the
 contents of a MIME body.  Therefore, all PIDF implementations that
 support the XML Schema extensions for location information described
 in this document MUST support S/MIME; in particular, they MUST
 support the CMS [6] EnvelopedData and SignedData content types, which
 are used for encryption and digital signatures, respectively.  It is
 believed that this mechanism meets REQs 2.10, 13, 14.1, 14.2, 14.3,
 and 14.4.
 Additionally, all compliant applications MUST implement the AES
 encryption algorithm for S/MIME, as specified in [8] (and per REQ
 15.1).  Of course, implementations MUST also support the baseline
 encryption and digital signature algorithms described in the S/MIME
 specification.
 S/MIME generally entails the use of X.509 [9] certificates.  In order
 to encrypt a request for a particular destination end-to-end (i.e.,
 to a Location Recipient), the Location Generator must possess
 credentials (typically an X.509 certificate) that have been issued to
 the Location Recipient.  Implementations of this specification SHOULD
 support X.509 certificates for S/MIME, and MUST support password-
 based CMS encryption (see [6]).  Any symmetric keying systems SHOULD
 derive high-entropy content encoding keys (CEKs).  When X.509
 certificates are used to sign PIDF Location Objects, the
 subjectAltName of the certificate SHOULD use the "pres" URI scheme.
 One envisioned deployment model for S/MIME in PIDF documents is the
 following.  Location Servers hold X.509 certificates and share
 secrets with Location Generators and Location Recipients.  When a
 Generator sends location information to a Server, it can be encrypted
 with S/MIME (or any lower-layer encryption specific to the using
 protocol).  When a Server forwards location information to a
 Recipient, location information can be encrypted with password-based
 CMS encryption.  This allows the use of encryption when the Location
 Recipient does not possess its own X.509 certificate.
 S/MIME was designed for end-to-end security between email peers that
 communicate through multiple servers (i.e mail transfer agents) that
 do not modify message bodies.  There is, however, at least one
 instance in which Location Servers modify Location Objects:  when
 Location Servers enforce policies on behalf of the Rule Maker.  For
 example, a Rule Maker may specify that Location Information should be
 coarsened (made less specific) before it is transmitted to particular
 recipients.  If the Location Server were unable to modify a Location
 Object, because it was encrypted, signed, or both, it would be unable
 to accomplish this function.  Consequently, when a Location Generator
 wants to allow a Location Server to modify such messages, they MAY

Peterson Standards Track [Page 16] RFC 4119 GEOPRIV Location Object December 2005

 encrypt such messages with a key that can be decrypted by the
 Location Server (the digital signature, of course, can still be
 created with keying material from the Location Generator's
 certificate).  After modifying the Location Object, the Location
 Server can re-sign the Object with its own credentials (encrypting it
 with any keys issued to the Location Recipient, if they are known to
 the Server).
 Note that policies for data collection and usage of location
 information, in so far as they are carried within a location object,
 are discussed in Section 2.2.2.

5. Security Considerations

 The threats facing an Internet protocol that carries geolocation
 information are detailed in [16].  The requirements that were
 identified in that analysis of the threat model were incorporated
 into [10], in particular within Section 7.4.  This document aims to
 be compliant with the security requirements derived from those two
 undertakings, in so far as they apply to the location object itself
 (as opposed to the using protocol).
 Security of the location object defined in this document, including
 normative requirements for implementations, is discussed in Section
 4.  This security focuses on end-to-end integrity and confidentiality
 properties that are applied to a location object for its lifetime via
 S/MIME.
 Security requirements associated with using protocols (including
 authentication of subscribers to geographical information, etc.)  are
 outside the scope of this document.

6. IANA Considerations

6.1. 'method' Tokens

 This document requests that the IANA create a new registry for
 'method' tokens associated with the PIDF-LO object.  'method' tokens
 are text strings designating the manner in which location information
 in a PIDF-LO object has been derived or discovered.  Any party may
 register new 'method' tokens with the IANA, as needed, on a first-
 come-first-serve basis.
 This section pre-registers 7 new 'method' tokens associated with the
 'method' element described above in Section 2.2.3:

Peterson Standards Track [Page 17] RFC 4119 GEOPRIV Location Object December 2005

    GPS: Global Positioning System
    A-GPS: GPS with assistance
    Manual: entered manually by an operator or user, e.g., based on
    subscriber billing or service location information
    DHCP: provided by DHCP (used for wireline access networks, see
    802.11 below)
    Triangulation: triangulated from time-of-arrival, signal strength,
    or similar measurements
    Cell: location of the cellular radio antenna
    802.11: 802.11 access point (used for DHCP-based provisioning over
    wireless access networks)

6.2. 'provided-by' Elements

 This document requests that IANA create a new registry of XML
 namespaces for 'provided-by' elements for use with PIDF-LO objects.
 Registrations of new XML namespaces that are used for 'provided-by'
 MUST be reviewed by an Expert Reviewer designated by the IESG.
 This document pre-registers a single XML namespace for 'provided-by',
 which is given in Appendix A.

6.3. URN Sub-Namespace Registration for

    urn:ietf:params:xml:ns:pidf:geopriv10
 This section registers a new XML namespace, as per the guidelines in
 [4].
    URI: The URI for this namespace is
    urn:ietf:params:xml:ns:pidf:geopriv10.
    Registrant Contact: IETF, GEOPRIV working group,
    (geopriv@ietf.org), Jon Peterson (jon.peterson@neustar.biz).
    XML:
 BEGIN
 <?xml version="1.0"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
      "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
   <meta http-equiv="content-type"
      content="text/html;charset=iso-8859-1"/>
   <title>GEOPRIV PIDF Extensions</title>
 </head>
 <body>
   <h1>PIDF Extensions of Geographical Information and Privacy</h1>
   <h2>urn:ietf:params:xml:ns:pidf:geopriv10</h2>
   <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">

Peterson Standards Track [Page 18] RFC 4119 GEOPRIV Location Object December 2005

      RFC4119</a>.</p>
 </body>
 </html>
 END

7. Acknowledgements

 This document was produced with the assistance of many members of the
 GEOPRIV IETF working group.  Special thanks to Carl Reed of OpenGIS
 for a close read of the document.
 The civic location format described in this document was proposed by
 Henning Schulzrinne for communicating location information in DHCP,
 and has been appropriated in its entirety for this document.
 James M.  Polk provided the text related to the 'method' element, and
 much of the text for the 'provided-by' element.  The text of Appendix
 A was written by Nadine Abbott.

Peterson Standards Track [Page 19] RFC 4119 GEOPRIV Location Object December 2005

A. Appendix: NENA Provided-By Schema

 The following registers the XML namespace
 urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider and the associated
 schema below, for usage within the 'provided-by' element of PIDF-LO.
 The dataProvider namespace was developed by the US National Emergency
 Number Administration (NENA) for next-generation emergency
 communications needs.
 This appendix is non-normative for implementers of PIDF-LO
 implementations and MAY support the dataProvider namespace.  Other
 registrants of 'provided-by' namespaces are invited to use the
 registration below as an informative example.
    URI: The URI for this namespace is
    urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider
    Registrant Contact: NENA, VoIP working group & IETF, GEOPRIV
    working group, (geopriv@ietf.org), Nadine Abbott
    (nabbott@telcordia.com).
    XML:
 BEGIN
 <?xml version="1.0"?>
 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
      "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
 <html xmlns="http://www.w3.org/1999/xhtml">
 <head>
   <meta http-equiv="content-type"
      content="text/html;charset=iso-8859-1"/>
   <title>NENA dataProvider Schema for PIDF-LO</title>
 </head>
 <body>
   <h1>NENA dataProvider Schema for 'provided-by' in PIDF-LO</h1>
   <h2>urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider</h2>
   <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4119.txt">
      RFC4119</a>.</p>
 </body>
 </html>
 END

Peterson Standards Track [Page 20] RFC 4119 GEOPRIV Location Object December 2005

A.1. dataProvider XML Schema

<?xml version="1.0" encoding="UTF-8"?> <!– edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by Patricia Bluhm (HBF Group) –> <xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider" xmlns:tns="urn:ietf:params:xml:ns:pidf:geopriv10:dataProvider" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

   <xs:element name="nena" type="tns:DataProviderIDType"/>
      <xs:complexType name="DataProviderIDType">
              <xs:annotation>
                      <xs:documentation>NENA registered Company ID

for Service Provider supplying location information</xs:documentation>

              </xs:annotation>
              <xs:all>
                      <xs:element name="DataProviderID"

type="tns:NENACompanyIDType" minOccurs="0"/>

                      <xs:element name="TelURI"

type="tns:TelURI_24x7Type" minOccurs="0"/>

                      <xs:element name="URL" type="xs:anyURI"

minOccurs="0"/>

              </xs:all>
      </xs:complexType>
      <xs:simpleType name="NENACompanyIDType">
              <xs:annotation>
                      <xs:documentation>NENA registered Company

ID.</xs:documentation>

              </xs:annotation>
              <xs:restriction base="xs:string">
                      <xs:maxLength value="5"/>
              </xs:restriction>
      </xs:simpleType>
      <xs:simpleType name="TelURI_24x7Type">
              <xs:annotation>
                      <xs:documentation>24x7 Tel URI for the

caller's [location data] service provider. To be used for contacting service provider to resolve problems with location data. Possible values TN number, enumerated values when not available.</xs:documentation>

              </xs:annotation>
              <xs:union memberTypes="xs:anyURI">
                      <xs:simpleType>
                             <xs:restriction base="xs:string">
                                 <xs:maxLength value="10"/>
                                 <xs:enumeration value="NOT FOUND"/>

Peterson Standards Track [Page 21] RFC 4119 GEOPRIV Location Object December 2005

                                 <xs:enumeration value="UNAVAILABLE"/>
                             </xs:restriction>
                      </xs:simpleType>
              </xs:union>
      </xs:simpleType>

</xs:schema>

Normative References

 [1]  Bradner, S., "Key words for use in RFCs to indicate requirement
      levels", BCP 14, RFC 2119, March 1997.
 [2]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
      J. Peterson, "Presence Information Data Format (PIDF)", RFC
      3863, August 2004.
 [3]  Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
      October 2003.
 [4]  Mealling, M., "The IETF XML Registry", RFC 3688, BCP 81, January
      2004.
 [5]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
      (S/MIME) Version 3.1 Message Specification", RFC 3851, July
      2004.
 [6]  Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852,
      July 2004.
 [7]  Levinson, E., "Content-ID and Message-ID Uniform Resource
      Locators", RFC 2392, August 1998.
 [8]  Schaad, J., "Use of the Advanced Encryption Standard (AES)
      Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC
      3565, July 2003.
 [9]  Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
      (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.

Informative References

 [10]  Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
       Polk, "Geopriv Requirements", RFC 3693, February 2004.
 [11]  Morris, J., Mulligan, D., and J. Cuellar, "Core Privacy
       Protections for Geopriv Location Object", Work in Progress,
       June 2003.

Peterson Standards Track [Page 22] RFC 4119 GEOPRIV Location Object December 2005

 [12]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
       and Instant Messaging", RFC 2778, February 2000.
 [13]  Peterson, J., "A Presence Architecture for the Distribution of
       Geopriv Location Objects", Work in Progress, February 20003.
 [14]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
       Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
       Session Initiation Protocol", RFC 3261, May 2002.
 [15]  OpenGIS, "Open Geography Markup Language (GML) Implementation
       Specification", OGC 02-023r4, January 2003,
       <http://www.opengeospatial.org/specs/?page=specs>.
 [16]  Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat
       Analysis of the Geopriv Protocol", RFC 3694, February 2004.

Author's Address

 Jon Peterson
 NeuStar, Inc.
 1800 Sutter St
 Suite 570
 Concord, CA  94520
 US
 Phone: +1 925/363-8720
 EMail: jon.peterson@neustar.biz
 URI:   http://www.neustar.biz/

Peterson Standards Track [Page 23] RFC 4119 GEOPRIV Location Object December 2005

Full Copyright Statement

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

Acknowledgement

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

Peterson Standards Track [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc4119.txt · Last modified: 2005/12/12 17:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki