8. Security Considerations
The presence information described by the model defined here is very
sensitive. It is for this reason that privacy filtering plays a key
role in the processing of presence data. Privacy filtering is the
act of applying permissions to a presence document for the purposes
of removing information that a watcher is not authorized to see. In
more general terms, privacy filtering is a form of authorization.
Privacy filtering can also ensure that a watcher cannot see any
presence data for a presentity, and indeed, it can even ensure that
the presentity doesn’t know that it is being blocked. The SIP
presence specifications (RFC 3856 [21]) require that such
authorization processing be performed before divulging presence
information. Specifications have also been defined for conveying
authorization policies to presence servers [26].
Integrity of presence information is also critical. Modification of
presence data by an attacker can lead to diverted communications, for
example. Protocols used to transport presence data, such as SIP for
presence, are used to provide necessary integrity functions.
9. Internationalization Considerations
This specification defines a data model that contains mostly tokens
that are meant for consumption by programs, not directly by humans.
Programs are expected to translate those tokens into language-
appropriate text strings according to the preferences of the watcher.
However, this specification defines a <note> element that can contain
free text. This element and other ones defined by extensions to PIDF
that can contain free text SHOULD be labeled with the ’xml:lang’
attribute to indicate their language and script. This specification
allows multiple occurrences of the <note> element so that the
presentity can convey the note in multiple scripts and languages. If
no ’xml:lang’ attribute is provided, the default value is "i-default"
[8].
Since the presence model is represented in XML, it provides native
support for encoding information using the Unicode character set and
its more compact representations including UTF-8. Conformant XML
processors recognize both UTF-8 and UTF-16. Though XML includes
provisions to identify and use other character encodings through use
of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
RECOMMENDED in environments where parser encoding support
incompatibility exists.
10. IANA Considerations
There are several IANA considerations associated with this
specification.
10.1. URN Sub-Namespace Registration
This section registers a new XML namespace, per the guidelines in [4]
URI: The URI for this namespace is
urn:ietf:params:xml:ns:pidf:data-model.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
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>A Data Model for Presence</title>
</head>
<body>
<h1>Namespace for Presence Data Model</h1>
<h2>urn:ietf:params:xml:ns:pidf:data-model</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4479.txt">
RFC4479</a>.</p>
</body>
</html>
END
10.2. XML Schema Registrations
This section registers two XML schemas per the procedures in [4].
10.2.1. Common Schema
URI: urn:ietf:params:xml:schema:pidf:common-schema.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of
Section 5.1.1.
10.2.2. Data Model
URI: urn:ietf:params:xml:schema:pidf:data-model.
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of
Section 5.1.2.
11. Acknowledgements
This document is really a distillation of many ideas discussed over a
long period of time. These ideas were contributed by many
participants in the SIMPLE working group. Aki Niemi, Paul Kyzivat,
Cullen Jennings, Ben Campbell, Robert Sparks, Dean Willis, Adam
Roach, Hisham Khartabil, and Jon Peterson contributed many of the
concepts that are described here. Example presence documents came
from Robert Sparks’ example presence documents specification, and
ideas on defining services through characteristics, rather than
enumeration, came from Adam Roach’s service features document. A
special thanks to Steve Donovan for discussions on the topics
discussed here, and to Elwyn Davies for his final review of the
document.
12. References
12.1. Normative References
[1] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and
J. Peterson, "Presence Information Data Format (PIDF)", RFC
3863, August 2004.
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
Preferences for the Session Initiation Protocol (SIP)", RFC
3841, August 2004.
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[5] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E.
Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C REC REC-xml-20040204, February 2004.
[6] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML
Schema Part 1: Structures Second Edition", W3C REC REC-
xmlschema-1-20041028, October 2004.
[7] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second
Edition", W3C REC REC-xmlschema-2-20041028, October 2004.
[8] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
12.2. Informative References
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
[11] 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.
[12] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859,
August 2004.
[13] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs)
and Uniform Resource Identifiers (URIs) for the Extensible
Messaging and Presence Protocol (XMPP)", Work in Progress,
December 2005.
[14] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message
Service", Work in Progress, February 2006.
[15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
December 2004.
[16] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999.
[17] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[18] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource
Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)", RFC 3761, April 2004.
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", Work in Progress, March 2006.
[20] Leach, P., Mealling, M., and R. Salz, "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[21] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[22] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", Work in Progress, October 2005.
[23] Schulzrinne, H., "RPID: Rich Presence Extensions to the
Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[24] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP)
User Agent Capability Extension to Presence Information Data
Format (PIDF)", Work in Progress, January 2006.
[25] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[26] Rosenberg, J., "Presence Authorization Rules", Work in
Progress, March 2006.
[27] Jennings C. and R. Mahy, "Managing Client Initiated Connections
in the Session Initiation Protocol (SIP)", Work in Progress,
March 2006.
Author’s Address
Jonathan Rosenberg
Cisco Systems
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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 provided by the IETF
Administrative Support Activity (IASA).