Internet DRAFT - draft-ala-kurikka-simple-map2pidf
draft-ala-kurikka-simple-map2pidf
SIMPLE J. Ala-Kurikka
Internet-Draft M. Ylianttila
Expires: January 6, 2006 E. Harjula
Univ. of Oulu
July 5, 2005
Mapping non-URIs to contact element in Presence Information Data Format
draft-ala-kurikka-simple-map2pidf-00
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 January 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The Presence Information Data Format (PIDF) defines a basic XML
format for presence information. The contact element in PIDF is
understood as a URI. However, some existing Internet services do not
identify users (presentities) natively with a URI. Mapping non-URIs
to contact element in Presence Information Data Format (Map2PIDF)
specifies the mapping of addresses to a URI in the case of such
currently existing services.
Ala-Kurikka, et al. Expires January 6, 2006 [Page 1]
Internet-Draft Map2PIDF July 2005
1. Introduction
The Presence Information Data Format (PIDF) [1] defines a basic XML
format for presenting presence information of a presentity. Presence
tuples [2] have an optional <contact> element. The contents of the
<contact> element are understood to refer to a URI [3].
There are, however, services and applications in the Internet that do
not natively use URIs to identify users, and/or the mapping of users
to URIs is more or less cumbersome. Examples include Instant
Messaging, VoIP and peer-to-peer for file sharing. While PIDF seems
flexible enough to handle also such communication addresses, it would
be helpful if users' capability of communicating with such services
that do not share a common naming convention could also be announced
with PIDF. This document specifies how to map user names from a such
services to a presentity's <contact> element.
One goal of this specification is to be backwards compatible with
PIDF. This would ensure that existing non-Map2PIDF watchers and
gateways will continue to work properly, without access to the
functionality specified here. Old User Agents (later UAs) would not
know how to act with URIs with these new schemes. However, if the
contents of <contact> elements were to be shown in plain text form to
a user acting as a watcher, he/she could possibly understand the form
and follow the link manually (e.g. by opening a file sharing client
program and connecting to a hub that the presentity is connected to).
At this phase, no action has been taken to filter URIs with formerly
undefined schemes defined in this document from presence information
for watchers or gateways that do not conform to this specification.
It is assumed that URIs with these new schemes in the presence
information do not hinder UAs or gateways from reading the tuples
that have well-known schemes according to "Handling of Unrecognized
Element Names" in PIDF.
1.1 Motivation
The PIDF specification does not rule out the set of supported
communication means. The only requirement set is that the
communication address has to be expressed with a URI. However, some
application level protocols - of which some are proprietary - use
naming conventions other than URIs to define individual presentities.
While these are normally ruled out so that their addresses would
never be added to a presentity tuple, this is an excellent
opportunity for adding connectivity awareness for PIDF. Providing
listing of the ways that a presentity can communicate with would be a
major advantage for SIP [4] leveraging SIP's status as a necessity
for all interconnected IP devices, being the unifying factor.
Ala-Kurikka, et al. Expires January 6, 2006 [Page 2]
Internet-Draft Map2PIDF July 2005
Of course, details on supported application level protocols could
also be queried from remote UAs after establishing a session with
them. Having that information without a session initiation with the
remote UA could, however, prove an important feature. Queries such
as "who of my friends are using Skype" would probably be more
efficient with a centrally managed presence information service than
with having to establish sessions to all friends first.
Mapping the "non-URIs" to a URI without a standard way could also be
used. But this would limit the usefulness of the presence tuple to
what the user can do, and even this only if the mapped URI would be
shown to the user in plain text form. There are many useful
scenarios where an automata would benefit from being able to
understand all the different ways of interaction (i.e. communication
addresses) of a presentity, say, a user's friend. The UA could then
provide e.g. a list of different possible operations with the friend
to the user. Or it could suggest using less costly Skype URI to
establish a telephone call instead of using a more expensive tel URI,
if the friend had one in one of his presence tuples.
Such feature would probably prove especially useful in mobile devices
because of their limited resources, including processing
capabilities, memory and screen. Also user friendliness could be
substantially better with one UI to control actions in several
protocols instead of multiple separate applications, one for each
protocol. The need for such multiprotocol communication will be even
bigger in the future, as there seems to be no consensus on which
protocol to use for e.g. file sharing. This leads often to loss of
interoperability. A certain type of interoperability would be made
possible, though, with the proposed specification.
1.2 Terminology and Conventions
This memo makes use of the vocabulary defined in the IMPP Model
document [2]. Terms such as COMMUNICATION ADDRESS, COMMUNICATION
MEANS, CONTACT ADDRESS, and PRESENTITY in the memo are used in the
same meaning as defined therein.
The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT,
RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted
as described in BCP 14, RFC 2119 [5].
Ala-Kurikka, et al. Expires January 6, 2006 [Page 3]
Internet-Draft Map2PIDF July 2005
2. Mapping
Every protocol being mapped to a URI MUST have a well-defined,
individual URI scheme. Schemes do not exist for the protocols
specified in this document. Schemes for non-existing protocols MUST
be formulated through the following process (conforms with [5]):
The official name of the protocol is converted to lowercase,
removed of any special characters (including white space) other
than digits, plus ("+"), period (".") or hyphen ("-").
If the name's first character is a digit, replace the digit with
the first character of the written English form in lowercase (e.g.
1->one->o)
Ala-Kurikka, et al. Expires January 6, 2006 [Page 4]
Internet-Draft Map2PIDF July 2005
3. Example
Using a default XML namespace:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:Joe@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="0.8">skype:joe</contact>
</tuple>
</presence>
This would indicate to a WATCHER that the PRESENTITY Joe@example.com
is registered to Skype with a user name of "joe" and that his Skype
client is online, so Joe is able to receive VoIP calls.
Ala-Kurikka, et al. Expires January 6, 2006 [Page 5]
Internet-Draft Map2PIDF July 2005
4. Implementing Map2PIDF
Our specification would benefit from some way of exchanging presence
information between SIP UAs [4] providing PRESENCE INFORMATION and
other applications (possibly UAs) communicating with other protocols.
One way of doing this would be to enable the SIP UA itself to be able
to communicate with various other protocols as well as SIP. Another
possibility would be to have interfaces between applications (or UAs)
through which presence information for different protocols could be
exchanged.
If no such intercommunication of applications can be achieved,
presence information provided to other protocols might be harder to
obtain by the SIP UA. This would, on the other hand, restrict
functionality. The SIP UA would not know if the device was online
with other protocols, therefore suggestions of using other protocols
might lead to useless attempts. Operating system level application
search and start capabilities could still be used to e.g. invoke an
external application to establish a VoIP session.
Ala-Kurikka, et al. Expires January 6, 2006 [Page 6]
Internet-Draft Map2PIDF July 2005
5. Security Considerations
Exposing PIDF information to others requires security mechanisms
itself. However, they are already specified in the PIDF
specification. Map2PIDF reveals some more information, such as 3rd
party applications installed and/or running on a PRESENTITY's device.
Care has to be taken, and the developer should pay special attention
to all notes in the PIDF security considerations. The 3rd party
applications might have security vulnerabilities themselves, however,
addressing them is out of scope of this document.
If a password to a certain server (or similar) was to be included in
a PRESENTITY's PRESENCE INFORMATION to enable certain (perhaps
selected) set of WATCHERs to gain access to the server, S/MIME [6]
MUST be used for staging security at least for that PRESENCE TUPLE.
Otherwise the password is exposed almost certainly allowing
eavesdroppers to also gain access to the server using the WATCHER's
privileges.
6. 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] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
Instant Messaging", RFC 2778, February 2000.
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
August 1998.
[4] 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.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
Ala-Kurikka, et al. Expires January 6, 2006 [Page 7]
Internet-Draft Map2PIDF July 2005
Authors' Addresses
Jussi Ala-Kurikka
MediaTeam / University of Oulu
Department of Electrical and Information Engineering
Information Processing Laboratory
P.O.BOX 4500
University of Oulu 90014
FI
Phone: +358 44 304 0098
Email: jussi.ala-kurikka@oulu.fi
URI: http://www.mediateam.oulu.fi
Mika Ylianttila
MediaTeam / University of Oulu
Department of Electrical and Information Engineering
Information Processing Laboratory
P.O.BOX 4500
University of Oulu 90014
FI
Phone: +358 40 535 0505
Email: mika.ylianttila@oulu.fi
URI: http://www.ee.oulu.fi/~over
Erkki Harjula
MediaTeam / University of Oulu
Department of Electrical and Information Engineering
Information Processing Laboratory
P.O.BOX 4500
University of Oulu 90014
FI
Phone: +358 50 303 0478
Email: erkki.harjula@oulu.fi
URI: http://www.mediateam.oulu.fi
Ala-Kurikka, et al. Expires January 6, 2006 [Page 8]
Internet-Draft Map2PIDF July 2005
Appendix A. Acknowledgments
The authors would like to thank the Application Supernetworking
(All-IP) project partners: the National Technology Agency (TEKES),
Nokia, TeliaSonera Finland, Elektrobit Group, IBM and Serv-It for
their financial support and Henning Schulzrinne for his comments
during the early phases of sketching the idea.
Ala-Kurikka, et al. Expires January 6, 2006 [Page 9]
Internet-Draft Map2PIDF July 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.
Ala-Kurikka, et al. Expires January 6, 2006 [Page 10]
