Network Working Group A. B. Roach
Internet-Draft dynamicsoft
Expires: August 6, 2004 February 6, 2004
Identification of Services in RPID (Rich Presence Information Data)
draft-roach-simple-service-features-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 August 6, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes a system by which one can identify certain
classes of service using the capabilities published in presence
documents. By identifying the probable presence of such services,
the chances of a succesful rendezvous are increased.
Roach Expires August 6, 2004 [Page 1]
Internet-Draft SIMPLE Service Features February 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problems with Service Enumeration . . . . . . . . . . . . . 3
3. Benefits of Service Deduction . . . . . . . . . . . . . . . 4
4. Reminder on the Nature of Presence Information . . . . . . . 5
5. Services . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1 Audio Call . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.2 Videophone . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3 Whiteboarding . . . . . . . . . . . . . . . . . . . . . . . 6
5.4 Application Sharing . . . . . . . . . . . . . . . . . . . . 7
5.5 Instant Messaging . . . . . . . . . . . . . . . . . . . . . 7
5.5.1 Page Mode Instant Messaging . . . . . . . . . . . . . . . . 7
5.5.2 Session Mode Instant Messaging . . . . . . . . . . . . . . . 8
5.6 Walkie-talkie . . . . . . . . . . . . . . . . . . . . . . . 9
5.7 Video walkie-talkie . . . . . . . . . . . . . . . . . . . . 9
5.8 Voice Instant Messaging . . . . . . . . . . . . . . . . . . 9
5.9 Remote Printer . . . . . . . . . . . . . . . . . . . . . . . 10
5.10 Email . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Normative References . . . . . . . . . . . . . . . . . . . . 10
Non-Normative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . 12
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . 13
Roach Expires August 6, 2004 [Page 2]
Internet-Draft SIMPLE Service Features February 2004
1. Introduction
Previous discussions of presence document usage [13] have considered
several different views of presence information. In particular, one
major open question has been whether to indicate service names
explicitly in presence information, or to infer the ability of a user
to use a particular service based on the combination of attributes
that a presentity publishes in its presence document.
The following discussion demonstrates why enumeration of services is
undesirable, and proposes that a proper interpretation of
capabilities published in presence documents is sufficient for
consumers of such documents to deduce the likely presence of
particular services.
The types of services under consideration in this document are those
which require support by both parties for successful rendezvous.
Many classes of services do not require such bilateral support to
work (e.g. call-waiting). This document does not concern itself
with such services.
2. Problems with Service Enumeration
The approach of enumerating services falls prey to several problems
that make such an approach difficult to adopt.
One key problem with enumerating services is that doing so results in
a combinatorial explosion over time. Consider a universe in which
three services exist: IM, voice, and IM with voice. When a new
capability is introduced into this system -- for example, video --
the number of potential services doubles in size: IM, Voice, Video,
IM with Video, IM with Voice, IM with Voice and Video, Voice with
Video. Each additional capability added to the system has a similar
explosive effect, such that the number of services that can be
identified becomes unmanagable in size. Such a problem extends
beyond the size of the database of service names that must be
maintained; any device that supports all three capabilities would
want to indicate support for all six services. This explosion of
service names has a very real impact on the size of presence
documents.
A second major issue with such enumeration of services is that it
requires either (a) a central repository of standardized service
names, or (b) use of a namespacing scheme that allows different
organizations to specify their own service names. Of course, a
hybrid approach would also be possible, but doing so would merely be
the worst of both worlds.
Roach Expires August 6, 2004 [Page 3]
Internet-Draft SIMPLE Service Features February 2004
Enumeration of standardized service names requires a standardization
of services. As the general direction that has been conciously taken
by the SIP and related working groups has been selection of
generality over efficiency -- defining building blocks that can be
combined to create services instead of defining services themselves -
- such standardization would be a dramatic change of direction, and
would unwind untold years of work on the general toolkit that we have
built.
Allowing other organizations to specify such services suffers from
the same problem, but exhibits at least one additional property:
doing so allows parallel development of services that may well be
compatible, but known by different names. To give a concrete
example, the company "example.com" may define a service that uses
half-duplex, floor controlled audio and name it "com.example.walkie-
talkie". Separately, an industry consortium may define a
functionally identical service, and name it "org.example.wt". Since
both are based on standard protocols, they actually interoperate --
however, because of the differing names, the ability to rendezvous
with a user based on the presence of such a service would be
hindered.
3. Benefits of Service Deduction
Many of the benefits of deducing services instead of enumerating them
can be derived from the preceding section by simply reversing the
negative aspects associated with service enumeration: linear
expansion as capabilities are added; no need for standardized
services; and enhanced interoperability. The final point, however,
is more nuanced than may be immediately obvious.
Using our previous example of a half-duplex, floor-controlled audio
service, consider a wireless service provider that has deployed such
a service, which they market as "depress to pester (tm)". A user of
this service is monitoring the presence of several associates. One
such associate, although not actually using a "depress to pester
(tm)" branded wireless terminal, happens to be running a client on
his PC which supports all of the capabilities that were used to
implement the "depress to pester (tm)" service. Based on these
advertised capabilities, the wireless user is presented with an
interface that indicates that such a user is available for a "depress
to pester (tm)" session. So, he selects that particular associate,
and attempts to begin a session. Because the associate's PC client
happens to support all of the protocols necessary for the service,
the call completes just fine; both users communicate using the
service that the caller expected.
Of particular interest is not only the fact that the called
Roach Expires August 6, 2004 [Page 4]
Internet-Draft SIMPLE Service Features February 2004
associate's client wasn't a "depress to pester (tm)" branded client,
but that it may have well participated in a service that its creators
hadn't even imagined. Simply because it had the proper capabilites
and advertised them appropriately, communication was facilitated.
4. Reminder on the Nature of Presence Information
One key aspect inherent in published presence information is the
following:
Presence information is never a guarantee of reachability.
Presence information is always only a hint.
Using as an example the type of presence information with which most
readers should be familiar: when a users status in your favorite
instant messaging application is indicated as "available," is that a
guarantee that anything you send will be received by that user? Of
course not. The user may be logged in, but away from the keyboard.
There may be a communications error that prevents delivery of your
message. Someone else may have powered up that users' computer.
There are myriad reasons that reachability may not be accurately
reflected by presence information.
The value in presence information is increasing the probabilty of
success in contacting a user via a particular mechanism, not
guaranteeing that a particular mechanism will be successful. This
fundamental property of presence information is key in understanding
why deduction of the presence of services is acceptable: even in the
corner cases that such deductions are not completely accurate, they
cause no more harm to the ability to communicate than other
situations in which presence information fails to guarantee an
outcome.
5. Services
The discussions about presence documents have identified a reasonably
small set of bilateral services that are of interest. To demonstrate
the points made in the preceding text, the following sections provide
examples of how service capabilities can be used to deduce support
for these services. A brief description of each service is provided,
along with capabilities that consumers of presence information can
use to deduce probable support for the service.
The examples that follow are not meant to be normative. Developers
of applications that consume presence information are free to choose
to look for whatever set of capabilities they wish before deciding
that a given presentity supports a paritcular service. Publishers of
presence information, however, would be well advised to include at
Roach Expires August 6, 2004 [Page 5]
Internet-Draft SIMPLE Service Features February 2004
least the minimal set of capabilites described below for each of the
services they beleive they have implemented.
The capabilites used below are taken from the document "User agent
capability presence status extension" [1]
Many of the services described below can be detected using multiple
mechanisms. Most such cases arise when the service can be provided
by a contact using a service-specific URI scheme (e.g. tel: [2][3] )
and also using a multi-service URI scheme (e.g. sip: [4]) along with
appropriate capabilities. In such cases, both mechanisms for
identification of the service are described.
5.1 Audio Call
This service provides the equivalent of a traditional voice phone
call. Participants can speak to and hear the other party
simultaneously.
Support for the Audio Call service can be deduced by observing either
of the following:
o The presence of a contact URI with a scheme of "tel:"
o The presence of a contact URI with a scheme of "sip:", associated
with the following minimal set of capabilities: <audio>true</
audio> <duplex>full</duplex> <methods>INVITE,ACK,BYE,CANCEL</
methods>
5.2 Videophone
This service is similar to the Audio Call service, with the
additional feature that participants can see each other.
Participants can speak to and hear the other party simultaneously.
Support for the Videophone service can be deduced by observing the
presence of a contact URI with a scheme of "sip:", associated with
the following minimal set of capabilities: <audio>true</audio>
<video>true</video> <duplex>full</duplex>
<methods>INVITE,ACK,BYE,CANCEL</methods>
5.3 Whiteboarding
A whiteboarding service allows users to share a virtual drawing
service. When either user "marks" on the drawing surface, both
participants can see the resulting images.
Roach Expires August 6, 2004 [Page 6]
Internet-Draft SIMPLE Service Features February 2004
The mechanisms for supporting whiteboarding have not yet been
standardized within the IETF. The session desription protocol
[14][15] posits the future definition of a whiteboard protocol, which
(in its example) is given a media type of "application/wb".
Borrowing from their example, were such a service to be defined by
the IETF, it would be identifiable by observing the presence of a
contact URI with a scheme of "sip:", associated with the following
minimal set of capabilities: <application>true</application>
<type>application/wb</type> <methods>INVITE,ACK,BYE,CANCEL</methods>
5.4 Application Sharing
An application sharing allows users to share complex applications,
such as word-processing applications. The precise behavior of an
application sharing service have no bearing on the conversation that
follows, and such details are intentionally omitted.
Like whiteboarding, no concrete mechanisms for application sharing
have been defined within the IETF. When such mechanisms are defined,
the method of identification will be very similar to that for
whiteboarding. In a parallel example to that given in the preceding
section, one can imagine an application/t120 mime type (or something
similar) that could be used for application sharing.
With this example, were such a service to be defined by the IETF, it
would be identifiable by observing the presence of a contact URI with
a scheme of "sip:", associated with the following minimal set of
capabilities: <application>true</application> <type>application/
t120</type> <methods>INVITE,ACK,BYE,CANCEL</methods>
5.5 Instant Messaging
At a high level, Instant Messaging services allow users to send
(typically short) messages to each other in near-real-time. Instant
Messaging services can be broken down into two different modes of
operation: Page Mode and Session mode (defined below).
It should be noted that CPIM [5] does not distinguish between these
modes of operation; consequently, it will occasionally be possible to
deduce the presence of an instant messaging service but not to tell
whether it supports page-mode, session-mode, or both. In particular,
such support can be detected by observing the presence of a contact
URI with a scheme of "im:". [5]
5.5.1 Page Mode Instant Messaging
The page mode instant messaging service allows sending of short
Roach Expires August 6, 2004 [Page 7]
Internet-Draft SIMPLE Service Features February 2004
messages using a metaphor similar to that of a two-way pager or SMS
enabled handset. That is, although recipients of such messages can
send new message back, there is no explicit association between
messages.
Support for the Page Mode Instant Messaging service can be deduced by
observing the presence of a contact URI with a scheme of "sip:" or
"im:", associated with the following minimal set of capabilities:
<methods>MESSAGE</methods>
See reference [6] for further information about the MESSAGE method.
5.5.1.1 SMS (Short Messaging Service)
The SMS service allows sending of page-mode short messages to mobile
phones. Originally introduced as part of the GSM service, it is now
available on almost all digital mobile phone services. Generally,
such messages are limited to approximately 100 to 200 characters
(depending on the underlying technology), often using a restricted
character set.
Support for the SMS service can be deduced by observing the presence
of a contact URI with a scheme of "sms:" [7]
5.5.1.2 MMS (Multimedia Messaging Service)
The MMS service, similar to the SMS service, allows sending page-mode
messages to mobile terminals. Unlike SMS, however, MMS allows
sending of large messages that are not necessarily text (e.g.
images, animations, etc.). A more complete description of the MMS
service can be found in [16][17] and [18].
Support for the MMS service can be deduced by observing the presence
of a contact URI with a scheme of "mmsto:" [8]
5.5.2 Session Mode Instant Messaging
Session mode instant messaging provides a mechanism by which users
can send (typically short) messages to each other in near-real time,
and provides an experience in which replies to such messages are
explicitly grouped with preceding messages. Most current PC-based
instant messaging software provides this type of service.
Support for the Session Mode Instant Messaging service can be deduced
by observing the presence of a contact URI with a scheme of "sip:" or
"im:", associated with the following minimal set of capabilities:
<methods>INVITE,ACK,BYE,CANCEL</methods> <schemes>msrp:,msrps:</
schemes>
Roach Expires August 6, 2004 [Page 8]
Internet-Draft SIMPLE Service Features February 2004
See reference [9] for further information about the MSRP URI.
5.6 Walkie-talkie
The walkie-talkie service allows real-time voice communication
between participants. Only one participant can speak at a time; that
is, communication is half-duplex. Typically, participants press a
button to indicate that they are ready to speak, although other
mechanism (e.g. voice activation) are occasionally used.
Support for the Walkie-Talkie service can be deduced by observing the
presence of a contact URI with a scheme of "sip:", associated with
the following minimal set of capabilities: <audio>true</audio>
<duplex>half</duplex> <methods>INVITE,ACK,BYE,CANCEL</methods>
5.7 Video walkie-talkie
Video walkie-talkie is a service that is very similar to the Walkie-
Talkie service, except that the user who is currently speaking also
can be seen by the other participant. (This service is primarily
included to demonstrate how the addition of a new capability can be
used to form a new service).
Support for the Video Walkie-Talkie service can be deduced by
observing the presence of a contact URI with a scheme of "sip:",
associated with the following minimal set of capabilities:
<audio>true</audio> <video>true</video> <duplex>half</duplex>
<methods>INVITE,ACK,BYE,CANCEL</methods>
5.8 Voice Instant Messaging
The Voice Instant Messaging service allows *near* real-time voice
communication between participants. Instead of streaming media as it
is being generated, this service typically spools the media and sends
it as an instant message to the receiver once it is completed.
Voice instant messaging is possible over both page-mode and session-
mode instant messaging, so there are several ways in which support
for it may be deduced:
o The presence of a contact URI with a scheme of "im:", associated
with the following minimal set of capabilities: <audio>true</
audio>
o The presence of a contact URI with a scheme of "sip:", associated
with the following minimal set of capabilities: <audio>true</
audio> <methods>MESSAGE</methods>
Roach Expires August 6, 2004 [Page 9]
Internet-Draft SIMPLE Service Features February 2004
o The presence of a contact URI with a scheme of "sip:", associated
with the following minimal set of capabilities: <audio>true</
audio> <methods>INVITE,ACK,BYE,CANCEL</methods>
<schemes>msrp:,msrps:</schemes>
5.9 Remote Printer
The Remote Printer service allows a user to print at the site of a
remote user for the purposes of communication with that user. In the
same way that the Audio Call service is analogous to traditional
telephony service, the Remote Printer service is roughly analogous to
traditional telefax services.
Remote printing can be effected using a variety of means, so there
are several ways in which support for it may be deduced:
o The presence of a contact URI with a scheme of "fax:" [2]
o The presence of a contact URI with a scheme of "ipp:" [10]
o Any of the preceding methods for detecting instant messaging that
also include the capability: <type>image/g3fax</type> [11]
5.10 Email
The Email service provides a non-realtime mechanism by which messages
can be sent from one user to another. Typical email systems use a
store-and-forward model of message delivery, which can result in
nontrivial delays between the time a message is sent and the time it
is received.
Support for the Email service can be deduced by observing the
presence of a contact URI with a scheme of "mailto:" [12]
6. Examples
This section will be completed in a future version of the document.
Normative References
[1] Lonnfors, M. and K. Kiss, "SIMPLE PIDF presence capabilities
extension", draft-lonnfors-simple-prescaps-ext-02 (work in
progress), October 2003.
[2] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April
2000.
Roach Expires August 6, 2004 [Page 10]
Internet-Draft SIMPLE Service Features February 2004
[3] Schulzrinne, H. and A. Vaha-Sipila, "The tel URI for Telephone
Calls", draft-ietf-iptel-rfc2806bis-02 (work in progress), July
2003.
[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] Peterson, J., "Common Profile for Instant Messaging (CPIM)",
draft-ietf-impp-im-04 (work in progress), October 2003.
[6] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C. and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[7] Vaha-Sipila, A. and E. Wilde, "URI scheme for GSM Short Message
Service", draft-wilde-sms-uri-03 (work in progress), April
2002.
[8] Wugofski, T., "MMS URI Schemes", draft-wugofski-mms-uri-scheme-
00 (work in progress), September 2003.
[9] Campbell, B., "Instant Message Sessions in SIMPLE", draft-ietf-
simple-message-sessions-03 (work in progress), January 2004.
[10] Herriot, R. and I. McDonald, "Internet Printing Protocol/1.1:
IPP URL Scheme", RFC 3510, April 2003.
[11] Alvestrand, H., "A MIME Body Part for FAX", RFC 2159, January
1998.
[12] Hoffman, P., Masinter, L. and J. Zawinski, "The mailto URL
scheme", RFC 2368, July 1998.
Non-Normative References
[13] Sparks, R., "SIMPLE Presence Document Usage Examples", draft-
sparks-simple-pdoc-usage-00 (work in progress), October 2003.
[14] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[15] Jacobson, V., Perkins, C. and M. Handley, "SDP: Session
Description Protocol", draft-ietf-mmusic-sdp-new-10 (work in
progress), May 2002.
[16] 3GPP, "Multimedia Messaging Service (MMS); Stage 1", 3GPP TS
22.140, September 2003.
Roach Expires August 6, 2004 [Page 11]
Internet-Draft SIMPLE Service Features February 2004
[17] 3GPP, "Multimedia Messaging Service (MMS); Functional
description; Stage 2", 3GPP TS 23.140, October 2003.
[18] 3GPP, "Multimedia Messaging Service (MMS); Media formats and
codes", 3GPP TS 26.140, January 2003.
Author's Address
Adam Roach
dynamicsoft
5100 Tennyson Pkwy
Suite 1200
Plano, TX 75024
US
EMail: adam@dynamicsoft.com
Appendix A. Acknowledgements
This work is the result of extensive discussions with members of the
Presence Document Team, composed of Aki Niemi, Ben Campbell, Brian
Rosen, Cullen Jennings, Henning Schulzrinne, Jon Peterson, Jonathan
Rosenberg, Paul Kyzivat, Robert Sparks, and Rohan Mahy.
Roach Expires August 6, 2004 [Page 12]
Internet-Draft SIMPLE Service Features February 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Roach Expires August 6, 2004 [Page 13]