One document matched: draft-rosenberg-impp-differences-00.txt
Internet Engineering Task Force IMPP WG
Internet Draft Dave Crocker
Brandenburg Consulting
Athanassios Diacakis
Network Projects Inc.
Christian Huitema
Microsoft Corporation
Graham Klyne
Content Technologies Limited
Florencio Mazzoldi
Network Projects Inc.
Marshall T. Rose
Invisible Worlds, Inc.
Jonathan Rosenberg
dynamicsoft
Robert Sparks
dynamicsoft
Hiroyasu Sugano
Fujitsu Laboratories Ltd.
draft-rosenberg-impp-differences-00.txt
August 18, 2000
Expires: February 2001
A Framework for Moving IMPP Forward
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.
Abstract
This document presents the summary of the findings of the IMPP group
of nine that were selected to study the common components and
fundamental differences among the three proposals.
1 Introduction
At the conclusion of the IMPP working group meeting in Pittsburgh in
August of 2000, it was agreed that a team of nine individuals, three
from each of the three protocol camps, would spend two weeks coming
up with a set of commonalities and differences amongst the various
protocol proposals. This document represents the output of that work.
It presents a high level overview of what we agreed was common, and
then describes the different approaches taken by the three proposals
and how they fundamentally differ. A companion document describes the
The Nine [Page 1]
Internet Draft IM August 18, 2000
details of the common components.
2 Commonalities
There was agreement that it must be possible to build gateways
between IMPP protocol islands such that the services required by RFC
2779 [1] can, at a mimimum, be interworked between islands. To
accomplish this, an abstract protocol, conformant to rfc2779, was
defined. It was agreed that all IMPP protocols would need to define a
mapping to this abstract protocol, as proof that interworking between
islands would be possible. This abstract protocol is described in
[2].
The abstract protocol provides subscription, notification, and
instant messaging capabilities. It defines protocol parameters that
are needed, at a minimum, for successful interworking.
There was also agreement on a common addressing format. An IM URL and
presence URL formats were defined. It was agreed that all IMPP
protocols would be required to carry these URL formats as the
identifications for the various entities in the system (presentities,
watcher addresses, etc.). It was also agreed that each protocol could
define its own native URL formats (i.e., the SIP proposal would also
use sip URLs). When communicating with a foreign domain, the foreign
domain would be required to list an SRV or A record for its domain
listing a gateway server. This gateway would be required to
understand protocol messages from all other islands, convert them to
its own protocol, and additionally know how to convert the global URL
to a native URL format. Details were defined and are described in
[2].
There was agreement that all IMPP protocols would be required to use
MIME for transport of instant messages and presence data.
Furthermore, it was agreed that a common format for presence data
would be defined. This format, based on XML, represents the minimal
presence format compliant to RFC 2779, and is based on the data model
described in RFC 2778 [3]. This allows gateways to simply copy the
content from one protocol to another with zero loss of information.
The presence format is defined in [2].
There was agreement that end to end authentication and encryption
would be supported through gateways using MIME security techniques,
including PGP-MIME [4] and S/MIME [5].
3 Differences
Despite these common components, it was clear that the three groups
represent fundamentally different approaches to solving the problems
The Nine [Page 2]
Internet Draft IM August 18, 2000
of IMPP, and that these approaches are not easily reconciled. The
subsections which follow describe the differing approaches in more
detail.
Each section is written by a representative from the respective view.
This draft is not an endorsement from the nine for any one, or all,
approaches.
3.1 The Session Initiation Protocol
The primary advantage that we see with the SIP proposal is the way in
which it can integrate voice, video, and other interactive
communications services with instant messaging and presence. There
are three aspects of this integration - integration of
infrastructure, integration of services, and integration of software.
The result are benefits to service providers, users, and
implementors, respectively.
Integration of infrastructure is about reuse. We believe service
providers will want to have a single network used to provide the
communications services of its customers - voice, video, IM or
presence. By basing the IMPP standard on SIP, this becomes
achievable. The same proxy servers used in SIP to route calls can
route IMs, and they can route presence data. The same data
repositories used for storing users' location for calls, can also be
used for storing users' locations for IMs, and also their location
for presence services. It is not mearly a reuse of the databases, but
the data itself. The same SIP phones used to receive calls can
instantly become publishers of presence information.
This kind of integration of infrastructure results in significant
benefits for the service provider. The management and operational
costs of running a communications service are vastly reduced, since
the addition of presence and IM to an existing SIP network is nowhere
close to the costs of building and running a completely separate,
parallel network. The equipment costs themselves are reduced, since
only one set of proxy and location servers are needed, rather than
two. System capacity is improved, since resources can be shared
across many services. Infrastructure investments in firewalls,
mobility services, etc. that have been put in place for supporting
SIP can also be reused. Service providers have also invested a
serious amount of intellectual capital in SIP; reusing SIP means
these providers have a much shorter learning curve.
From the users perspective, the primary benefit is integration of
services. Voice, video, IM and presence are all simply different
aspects of the general problem of interpersonal interactive
communications. Many features and services used in one domain make a
The Nine [Page 3]
Internet Draft IM August 18, 2000
lot of sense in the other. Take, for example, call screening, which
can prevent incoming calls from specific users. A very desirable
service would be to extend this to IM - that person can neither call,
send an IM, or subscribe to the user of this feature. Development,
provisioning, and deployment of these kinds of integrated features is
vastly simplified by a single network that provides them. If IM and
presence and voice where each separate protocol clouds, it would
require separate code, running on separate networks, maintained
separately, and kept synchronized. However, if these services all ran
on the same network, providing such integrated services would be
simple, if not for free (the above service is for free in a SIP
proxy, as these provide such services on a method independent basis).
As another example, the IP Telephony working group in IETF (iptel)
has nearly completed specification of the Call Processing Language
(cpl), and XML based scripting language that allows users to define
their own services for SIP. CPL enables screening, forwarding,
filtering, and notification types of services. For example, a CPL can
be written which specifies that calls from Joe are forwarded to a
unified messaging server after 5pm, all other calls are routing to a
mobile PDA. The specification of the service is method independent;
this means this CPL and all the related CPL infrastructure in the
network would allow this service to be extended to instant messaging
with no additional work. This would allow users to customize their
own IM, presence and multimedia services with the same tools.
By using a different protocol, or even by modifying SIP in some way
for this application, the above benefits are lost. Service providers
will not be able to run IM and presence on their deployed SIP
networks. Therefore, for service providers deploying SIP networks,
there is but a single realistic choice. Choosing a different
protocol, or even a modified SIP, results in such substantially
higher costs that it acts as a barrier to entering the market.
From the implementors perspective, the primary issue is cost and time
to market. By using SIP, implementors can readily obtain one of the
many existing software development kits and libraries, and build upon
that. Both open source and commercial code is available. For
implementors who already have their own SIP code, building ontop of
that instead of building from scratch is a clear win. There are
nearly one hundred seperate implementations of SIP; many from groups
which wish to build IM and presence solutions as well as multimedia
communications solutions. There are also numerous testing and load
generation tools available for SIP; these too can be reused for
building IM and presence systems.
For this reason, we believe that choosing a single, non-SIP based
solution for presence and IM is a non-starter. There is a significant
The Nine [Page 4]
Internet Draft IM August 18, 2000
community of interest, among both service providers and software
manufacturers, for a SIP based solution.
3.2 The IMXP
The basic philosophy of IMXP is:
o The core mechanism is kept to a minimum: Anything that can be
built using the core mechanism is excluded from the core.
o Design is based on familiar Internet mail architecture:
Applies a wealth of related experience, making the
architecture choices extremely safe.
The IMXP relay mesh uses lightweight, near-real-time application
datagram transfer nodes, analogous to email MTAs:
o Relay processing is kept simple: Essential intelligence is
kept at or near the network edge to enhance scalability;
relays are not required to maintain state concerning message
transfer.
o Addressing and routing follow the classic email model: This
is safely scalable, providing hierarchical addresses (domain
names) that can be understood by the entire relay mesh.
o Hop-by-hop security framework: Authentication, privacy, and
authorization rely on domains "keeping their own houses in
order", in line with current Internet infrastructure. End to
end security (OpenPGP or S/MIME) may be added to provide
better security, but require (pending) PKI deployment.
o Transport independence: A convergence layer (BEEP) carries
IMXP identically over variety of transports.
o Other applications may use the same service: Asynchronous
near-real-time message exchange with accessible, predictable
behaviour for loosely-coupled applications.
In summary, we require than each part of solution must carry its full
weight in the overall scheme. It is not enough that the parts of the
solution are individually good: all core elements are needed to
fulfill essential IM functions, or to provide hooks for building such
functions. The design re-applies the lessons of Internet scaling to
application design, aiming for minimum processing performed in the
network, unimpeded end-to-end transfer of information, and services
added at the network edge.
The Nine [Page 5]
Internet Draft IM August 18, 2000
3.3 PRIM: Presence and Instant Messaging
The authors of several IMPP proposals, namely PePP, PITP/IMTP, OneIM,
and SIMP, have agreed and actually started working to make a joint
proposal based on our existing drafts. Our protocols have extended
architectural similarities, and we believe that those are attributed
to the fact that our design is based on RFC2778-2779 and consensus
formed in the IMPP community so far. In summary, our aim is to
develop a minimal specification, which satisfies the IMPP
requirements.
3.3.1 PRIM Design
Transfer protocol directly atop of TCP: We assume TCP as basic
transport mechanism for instant messages and presence
information. TCP provides sufficiently reliable transport
infrastructure and we think instant messaging (IM) and
presence services require this level of reliability. In
addition, we design both IM and presence protocols directly
atop of TCP. Although these are tightly related services,
their characteristics are different in several points. This
decision makes the protocols quite simple and lightweight.
Long-lived Client/Server connections: Our protocols use long-
lived client/server connections in order for clients to
receive instant messages and presence notifications. This
brings the following advantages. As we adopt TCP as IM and
presence transport, use of existing connections reduce much
overhead of re-establishing connections and per-connection
authentication. This feature is fairly important in the
case of some uses where presence notifications are
frequent. Once the connection peer (the home domain server)
is authenticated, additional authentication for IMs and
notification messages may be omitted in the case the home
domain servers and the inter-domain relation is considered
fully trustworthy. When clients are behind firewalls and
connect to the servers outside, using long-lived TCP
connections to receive messages from the servers is a
practical solution. This situation is quite common at
present to utilize the existing IM service providers.
Selective Presence Publication: RFC2779 stipulates various
requirements for access control; 2.3.x and some of section
5. Among them, we consider the feature of "Polite Blocking"
(5.1.15, 5.2.3) very important for presence services. Our
proposal contains the mechanism of such selective presence
The Nine [Page 6]
Internet Draft IM August 18, 2000
publication and the in-band access control mechanism.
3.3.2 Our Perspective
We believe that the authors of the various proposals (as grouped by
the WG chairs) have different expectations from an IMP protocol. We
expect a Presence and IM protocol to have the following
characteristics (in no particular order):
o It does not carry unnecessary features. The WG was given the
task to produce a protocol with a certain feature-set
(RFC2779). Extra features can be nice, but should not exist in
this protocol, or should be built elsewhere.
o It maps well on existing Presence and IM offerings. The
migration to the standard should be as painless and seamless
as possible. This would remove barriers to adoption.
o Existing Presence and IM offerings use architectures that map
well on Group 2 proposals. As a result there is a lot of
experience on how those architectures perform in solving the
Presence and IM requirements.
o It is simple and easily understood by developers who will need
to implement it. There are a lot of people on the WG that
perceive non-Group 2 proposals to be unnecessarily
complicated.
o It is independent from the work currently being done in other
WGs. There is a sense of urgency in producing an IMP protocol,
and introducing unnecessary links (that might turn into
critical dependencies) to other WG does not help. Work
currently being done in other WGs should be used, if
applicable, when it is complete.
o It does not rely on non-existing technology and
implementations. Again, there is a sense of urgency and the
IMP protocol should not require an implementation of server X
(which currently does not exist) unless that is absolutely
necessary.
4 Conclusion
In conclusion, the group of nine have agreed on a common set of
components for IM and presence that will allow interworking with
delivery of services compliant to rfc 2779. This is accomplished
through the definition of an abstract protocol, a common addressing
format, a common presence data format, a common content format, a and
The Nine [Page 7]
Internet Draft IM August 18, 2000
a common end to end security format. We have also outlined the
differences between the protocols, focusing on what is fundamentally
different and not easily reconcilable.
Our hope is that this work will serve as a solid foundation for
moving IMPP forward.
5 Author's Addresses
David H. Crocker
Brandenburg Consulting
675 Spruce Drive
Sunnyvale, CA 94086
US
Phone:
+1 408 246 8253
EMail:
DCROCKER@BRANDENBURG.COM
URI:
HTTP://WWW.BRANDENBURG.COM/
Athanassios Diacakis
Network Projects Inc.
4516 Henry Street
Suite 113
Pittsburgh, PA 15213
US
Phone:
+1 412 681 6950
EMail:
THANOS@NETWORKPROJECTS.COM
Christian Huitema
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
US
EMail:
HUITEMA@MICROSOFT.COM
Graham Klyne
Content Technologies Limited
1220 Parkview
Arlington Business Park
Theale, Reading RG7 4SA
UK
The Nine [Page 8]
Internet Draft IM August 18, 2000
Phone:
+44 118 930 1300
EMail:
GK@ACM.ORG
Florencio Mazzoldi
Network Projects Inc.
4516 Henry Street
Suite 113
Pittsburgh, PA 15213
US
Phone:
+1 412 681 6950
EMail:
FLO@NETWORKPROJECTS.COM
Marshall T. Rose
Invisible Worlds, Inc.
1179 North McDowell Boulevard
Petaluma, CA 94954-6559
US
Phone:
+1 707 789 3700
EMail:
MROSE@INVISIBLE.NET
URI:
HTTP://INVISIBLE.NET/
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Robert Sparks
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: rsparks@dynamicsoft.com
Hiroyasu Sugano
Fujitsu Laboratories Ltd.
64 Nishiwaki, Ohkubo-cho
Akashi 674-8555
JP
EMail:
The Nine [Page 9]
Internet Draft IM August 18, 2000
SUGA@FLAB.FUJITSU.CO.JP
6 Bibliography
[1] M. Day, S. Aggarwal, G. Mohr, and J. Vincent, "Instant messaging
/ presence protocol requirements," Request for Comments 2779,
Internet Engineering Task Force, Feb. 2000.
[2] D. Crocker, M. Rose, G. Klyne, J. Rosenberg, R. Sparks, C.
Huitema, F. Mazzoldi, H. Sugano, and A. Diacakis, "A common profile
for instant messaging," Internet Draft, Internet Engineering Task
Force, Aug. 2000. Work in progress.
[3] M. Day, J. Rosenberg, and H. Sugano, "A model for presence and
instant messaging," Request for Comments 2778, Internet Engineering
Task Force, Feb. 2000.
[4] M. Elkins, D. D. Torto, R. Levien, and T. Roessler, "MIME
security with OpenPGP," Internet Draft, Internet Engineering Task
Force, Apr. 2000. Work in progress.
[5] B. Ramsdell and Ed, "S/MIME version 3 message specification,"
Request for Comments 2633, Internet Engineering Task Force, June
1999.
The Nine [Page 10]
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:26 |