Internet DRAFT - draft-thomson-geopriv-provided-by
draft-thomson-geopriv-provided-by
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ü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]
