[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

GEOPRIV Working Group                                         M. Thomson
Internet-Draft                                                    Andrew
Expires: April 14, 2006                                          J. Polk
                                                                   Cisco
                                                        October 11, 2005


            Using URIs for the PIDF-LO 'provided-by' element
                draft-thomson-geopriv-provided-by-00.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 14, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   The "provided-by" element in PIDF-LO is a container designed to carry
   information about the source of location information.  This document
   defines an XML structure that can be used within the "provided-by"
   element to convey basic information about the information provider in
   the form of a URI.





Thomson & Polk           Expires April 14, 2006                 [Page 1]


Internet-Draft               provided-by URI                October 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  provided-by URI  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  URI Usage  . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  provided-by URI Schema . . . . . . . . . . . . . . . . . . . .  5
   4.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
     6.1.  URN sub-namespace registration for
           'urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri' . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
   Intellectual Property and Copyright Statements . . . . . . . . . . 11


































Thomson & Polk           Expires April 14, 2006                 [Page 2]


Internet-Draft               provided-by URI                October 2005


1.  Introduction

   The PIDF-LO document [I-D.ietf-geopriv-pidf-lo] defines the
   "provided-by" element, which is to be used to identify the
   organization that provided the location information to the endsystem.
   The "provided-by" element is designed to either augment provider
   identity information contained in a digital signature, or provide
   some information in the absence of a signature.  The "provided-by"
   element can also be used to identify an original provider in the case
   where information is made available by a third party.

   The PIDF-LO specification [I-D.ietf-geopriv-pidf-lo] includes a
   definition for a "provided-by" element, that is, for the National
   Emergency Number Association (NENA), which is North America specific.
   This document includes a lightweight definition that is more widely
   applicable.

   The URI form specified in this document provides a loose means of
   identifying the provider of location information to the endsystem.
   It is characterized as "loose" since it the information can only be
   used as a hint, see Section 5 for details.

1.1.  Terminology

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
























Thomson & Polk           Expires April 14, 2006                 [Page 3]


Internet-Draft               provided-by URI                October 2005


2.  provided-by URI

   This document defines "provided-by" content, the "uri" element, that
   can be used to convey URIs.

   A URI provides a very flexible means of conveying information.  To
   that end, this document does not mandate specific processing for the
   "provided-by" element.  A User Agent MAY interpret the "provided-by"
   element in any fashion it considers appropriate, which could simply
   be to ignore the field entirely.  Where URIs are made available, a
   User Agent SHOULD only use any URI on explicit user direction.

   It is RECOMMENDED that, where applicable, any URI included in the
   "provided-by" element be accessible from the public internet without
   requiring authentication.

   There MAY be more than one "uri" element in a PIDF-LO so that
   multiple URIs can be present.  It MAY also be used in combination
   with other "provided-by" content.

2.1.  URI Usage

   URIs included in the "provided-by" element can be used for many
   purposes.  The "type" attribute MAY be included to provide a hint to
   a User Agent about how a URI could be used if it isn't evident from
   the URI scheme.  The following values are defined:

   contact: The URI can be used to contact the providing organization.
      This is similar to the "contact" element defined in PIDF
      [RFC3863].  It is RECOMMENDED that this field include a URI in a
      scheme that can be used for establishing a media session, such as
      sip, sips or tel.

   location: The URI references location information pertaining to the
      organization or the specific campus, which should be in the form
      of a PIDF-LO document.

   info: The URI references general information, which might include
      information on the privacy policy of the organization; an
      explanation of how location information is determined by the
      organization; or any other information.

   No guidance is provided on how URIs are used, however it is expected
   that a User Agent use default handling behavior for each scheme.  For
   instance, an http URI might be passed to a web browser or a sips URI
   might be passed to a SIP UA.





Thomson & Polk           Expires April 14, 2006                 [Page 4]


Internet-Draft               provided-by URI                October 2005


3.  provided-by URI Schema

   The following schema defines a "uri" element that can be used for
   "provided-by" URIs.

   <?xml version="1.0"?>
   <xs:schema
     targetNamespace="urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri"
     xmlns:xs="http://www.w3.org/2001/XMLSchema"
     xmlns:uri="urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri"
     elementFormDefault="qualified" attributeFormDefault="unqualified">

     <xs:element name="uri" type="uri:pb-uri"/>
     <xs:complexType name="pb-uri">
       <xs:simpleContent>
         <xs:extension base="xs:anyURI">
           <xs:attribute name="type" use="optional">
             <xs:simpleType>
               <xs:restriction base="xs:token">
                 <xs:enumeration value="info"/>
                 <xs:enumeration value="contact"/>
                 <xs:enumeration value="location"/>
               </xs:restriction>
             </xs:simpleType>
           </xs:attribute>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>
   </xs:schema>






















Thomson & Polk           Expires April 14, 2006                 [Page 5]


Internet-Draft               provided-by URI                October 2005


4.  Example

   The following example demonstrates the inclusion of multiple URIs in
   the "provided-by" element.


   <?xml version="1.0"?>
   <presence xmlns="urn:ietf:params:xml:ns:pidf"
             xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
             xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
             xmlns:uri="urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri"
             entity="pres:user@example.com">
     <tuple id="example">
       <status>
         <gp:geopriv>
           <gp:location-info>
             <ca:civicAddress xml:lang="de">
               <ca:country>DE</ca:country>
               <ca:A1>Bayern</ca:A1><ca:A2>Oberbayern</ca:A2>
               <ca:A3>M&#252;nchen</ca:A3>
               <ca:A6>Marienplatz</ca:A6><ca:HNO>8</ca:HNO>
               <ca:PC>80331</ca:PC>
             </ca:civicAddress>
           </gp:location-info>
           <gp:usage-rules>
             <gp:retransmission-allowed>no</gp:retransmission-allowed>
           </gp:usage-rules>
           <gp:provided-by>
             <uri:uri>http://www.example.com/info/pidf-lo/</uri:uri>
             <uri:uri type="contact">sips:location@example.com</uri:uri>
             <uri:uri type="contact">
               mailto:location@example.com?subject=PIDF-LO
             </uri:uri>
           </gp:provided-by>
         </gp:geopriv>
       </status>
     </tuple>
   </presence>













Thomson & Polk           Expires April 14, 2006                 [Page 6]


Internet-Draft               provided-by URI                October 2005


5.  Security Considerations

   The information in the "provided-by" element does not provide any
   assurance that the entity referred to is actually the provider of the
   location information.  Specifically, the contents of a "provided-by"
   element do not provide a cryptographic assertion of identity of any
   nature.

   Unless location information is digitally signed, it is very easy to
   provide fraudulent information within this field.  For example, a
   PIDF-LO from "example.cracker.com" might include a URI to the well-
   known and trusted "example.com" web site.  This attack could be used
   to trick users into thinking that the location information was
   provided by "example.com".

   When a PIDF-LO is not digitally signed by an authenticated and
   sufficiently authorized entity the following restrictions apply:

   o  Users of the information MUST NOT represent any authentication
      information provided when dereferencing the URI as the provider of
      location information.

   o  Users of this information MUST NOT use the information for any
      purpose beyond informational.

   It is RECOMMENDED that a User Agent observe these restrictions even
   when a digital signature is present.
























Thomson & Polk           Expires April 14, 2006                 [Page 7]


Internet-Draft               provided-by URI                October 2005


6.  IANA Considerations

   This document calls for IANA to register a new XML namespace, as per
   the guidelines in [RFC3688].

6.1.  URN sub-namespace registration for
      'urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri'


   URI
     urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri

   Registrant Contact
     IETF, GEOPRIV working group <geopriv@ietf.org>
     Martin Thomson <martin.thomson@andrew.com>

   XML
     BEGIN
       <?xml version="1.0"?>
       <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
       <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
         <head>
           <title>GEOPRIV provided-by URI</title>
         </head>
         <body>
           <h1>URI element for the provided-by element in PIDF-LO</h1>
           <h2>urn:ietf:params:xml:ns:pidf:geopriv10:pb-uri</h2>
           <p>See <a href="URL of published RFC">RFCXXXX</a>.</p>
         </body>
       </html>
     END



















Thomson & Polk           Expires April 14, 2006                 [Page 8]


Internet-Draft               provided-by URI                October 2005


7.  References

7.1.  Normative References

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

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

7.2.  Informative References

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

   [RFC3863]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
              W., and J. Peterson, "Presence Information Data Format
              (PIDF)", RFC 3863, August 2004.































Thomson & Polk           Expires April 14, 2006                 [Page 9]


Internet-Draft               provided-by URI                October 2005


Authors' Addresses

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

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


   James M. Polk
   Cisco
   3913 Treemont Circle
   Colleyville, Texas  76034
   USA

   Phone: +1-817-271-3552
   Email: jmpolk@cisco.com






























Thomson & Polk           Expires April 14, 2006                [Page 10]


Internet-Draft               provided-by URI                October 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

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


Acknowledgment

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




Thomson & Polk           Expires April 14, 2006                [Page 11]


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