Folks,
This note cites substantive process and technical problems with the
candidate specifications being submitted from the Instant Messaging and
Presence (IMPP) working group. The group's charter specifies the scope
to be to "define protocols and data formats necessary to build an
Internet-scale end-user presence awareness, notification and instant
messaging system".
IMPP discussions began January, 1997 -- 5 1/2 years ago. It took one
year to get chartered and another year to develop requirements, which
were finally issued on February, 2000 (RFCs 2778-9). There have been no
RFCs issued in the 3 1/2 years since then.
Protocol development efforts were thwarted by the existence of several
different technical constituencies and much effort, but no progress, at
reconciling them. Two and a half years ago, the area directors
acknowledged that a single, homogeneous protocol was not going to be
developed, so they called for development of a "gatewaying"
specification -- CPIM. They hoped to permit interconnection among the
heterogeneous protocols being proposed, with the possibility of also
interconnecting the various and popular services already in use.
Unfortunately, this fundamental change in working group direction was
never formally documented or approved through a charter revision.
The issues discussed below have previously been raised in the working
group, over the last year. The concerns raised were not resolved.
The working group's output suffers from:
1. PROCESS FAILURES
1.1. Lack of participation and constituency
1.2. Out of scope with charter
1.3. Failure to resolve issues raised in the working group
2. TECHNICAL FAILURES
2.1. Confused and conflicting goals
2.2. Incomplete and unclear specifications.
IMPP has a long and erratic history. It has incurred multiple changes in
direction and multiple changes in its staff and oversight. The proffered
work reflects this.
Let's consider each of these points:
1. PROCESS FAILURES
1.1. Lack of participation and constituency
Who is the audience for this work and what is the basis for believing
the work will be used? The documents claim a goal of interoperability
among heterogeneous IM and Presence services, but the normative content
of the work precludes that goal.
In fact the normative work is for an end-to-end, homogeneous service.
Who will implement and use such work, and why?
A strong indication that the work is not relevant to the Internet
technical and operations community has been a dramatic drop-off in
participation.
The working group has been essentially inactive for the 6 months of
2003, except for a post hoc exercise to write a "charter".
During the 12 months before that, no more than 15 people made regular
contributions (using roughly one posting per month as the threshold.)
Only 10 of these participants posted 2 or more messages per month during
that time.
In reality, for the last 18 months, the real working group activity has
been a dialogue among 4-5 people, with very few other participants.
This does not bode well at all for industry interest in -- and use of --
this work product.
1.2. Out of scope with charter
For the last 2.5 years, the working group has been operating without a
meaningful charter. All of the work done during that time is out of
scope with the text of the original charter.
The lack of a concrete, updated charter has allowed the WG to behave in
an arbitrary fashion with respect to its choice of technical goals and
the soundness of the engineering decisions it has made. This explains,
for example, why there is no rationale for honoring some IMPP
requirements, but not others.
Recently, at the request of an Area Director, the co-chairs authored
draft-day-atkins-impp-defacto-00 as a "de facto" charter. Several
participants have objected to this contribution, but its authors have
not responded to the issues raised.
Although proposing a "de facto" charter is one way of appearing to
legitimize the WG's behavior, the ADs would be well served by returning
to first principles and asking themselves whether the WG has adhered to
architectural and engineering principles that are sound, and whether
there is a reasonable basis for believing that this work will get
serious use on the Internet.
Equally importantly, we either believe in the rules or we don't. The
rules say that work-product has to conform to charter. The rules do not
say "do some work, then write a charter to reflect the work-product".
Even if the proffered work was a marvel of architectural soundness and
engineering quality (which, as we'll discuss below, it clearly isn't),
this "ex post facto" approach would raise the hackles of anyone who
considers consistent IETF process to be a mandatory thing.
1.3. Failure to resolve issues raised in the working group
The issues listed in the Section 2 below (Technical Failures) were all
raised carefully during the working group process. They remain
unresolved and some received no response.
The problem with the group's dichotomy between end-to-end vs. gateway
goals was discussed repeatedly. Only towards the end of the working
group's effort did this appear to become resolved -- in the direction of
an end-to-end content standard. However, even then it was clear that the
few remaining participants in the group continued to hold very different
understandings of the goal. Consequently, the confusion in the working
group documents, on this point, is a regrettable, though accurate,
rendition of the unresolved problem within the group.
2. TECHNICAL FAILURES
2.1. Confused and conflicting goals
The nature and the detail of these specifications are incomplete and
often unclear. The work shows a split between the claimed goal of
interconnecting heterogeneous IM and Presence services, versus the
actual goal of specifying homogeneous, end-to-end IM and Presence
services.
The specifications call for features that go beyond what is required for
a minimal functional core of interoperability. These added features
serve to severely reduce the likelihood that the specifications will be
used for interconnecting heterogeneous services.
As noted in a curious discussion within the working group, recently, the
IMPP Requirements documents were used arbitrarily for justifying some
design decisions, but not others. There is no basis for knowing why
those requirements sometimes applied to the IM and Presence "gatewaying"
work but at other times did not.
Consider this fragment from Section 3.3 (Format of Instant Messages) of
draft-ietf-impp-im-03:
This specification defines an abstract interoperability mechanism for
instant messaging protocols; the message content definition given
here pertains to semantics rather than syntax. However, some
important properties for interoperability can only be provided if a
common end-to-end format for instant messaging is employed by the
interoperating instant messaging protocols, especially with respect
In other words, this specifies (and requires implementation of support
for) an end-to-end syntax as well as semantics.
It should be noted that the message format, defined by the working
group, is new and will require a new suite of parsers, generators, and
editors. Although it purports to be a sub-set of RFC822, the format has
notable requirements -- such as Unicode -- that are not in RFC822. While
the desire to improve on existing practise is laudable, it defeats the
goal of gatewaying heterogeneous systems.
2.2. Incomplete and unclear specifications.
(Lest there be any misunderstanding about this title of this
sub-section, it is meant to cover the reasons that -- independent of
process and goal debates -- the specifications "won't work".)
Simply put, the specification suffer key omissions and ambiguities which
make development of interoperable implementations highly unlikely.
Consider this fragment Section 3.1 (Overview of Instant Messaging
Service) of draft-ietf-impp-im-03:
its initial value is set by the originator. The TransID is a unique
identifier used to correlate message operations to response
"Unique" is not specified in any of the documents. The obvious
question is: unique with what scope?
Ensuring uniqueness in transaction identifiers is a well-known
challenge, with well-known resolutions -- notably from the transport
arena. Yet the specification does not mention it. This makes it likely
that some implementations will create ambiguous TransIDs.
Alternatively, consider this fragment from Section 3.4.1 (The Message
Operation) of draft-ietf-impp-im-03:
When an application wants to send an INSTANT MESSAGE, it invokes the
message operation.
When an instant messaging service receives the message operation, it
performs the following preliminary checks:
Does this refer to the application/im-client interaction, the
im-client/im-server interaction, or what?
Or consider this other fragment from draft-ietf-impp-im-03:
4. Provided these checks are successful:
If the instant messaging service is able to successfully
deliver the message, a response operation having status
"success" is invoked.
If the service is unable to successfully deliver the message,
a response operation having status "failure" is invoked.
If the service must delegate responsibility for delivery (i.e.
if it is acting as a gateway or proxying the operation), and
if the delegation will not result in a future authoritative
indication to the service, a response operation having status
This demonstrates a very serious effect from using the fuzzy term
'service' rather than citing specific component-component interactions:
It appears to mean that there is an end-to-end, real-time dependency
chain for generating a response to a request. Each node along a relay
path must withhold generating a response until the next node gives it
the delivery -- i.e., the final -- status result.
Note that this is fundamentally different from Email. In effect, it uses
the equivalent to the Email SMTP Delivery Status Notification as the
*sole* operations response mechanisms, with no intermediate (hop-by-hop)
relaying report.
Similarly, consider Section 3.1 (3.1 Overview of the Presence Service)
of draft-ietf-impp-pres-03:
The duration specifies the
maximum number of seconds that the SUBSCRIPTION should be active
(which may be zero, in which case this is a one-time request for
presence information).
...
If the duration parameter is non-zero, then for up to the specified
duration, the service invokes the notify operation whenever there are
any changes to the PRESENTITY's presence information.
How can "duration" have any useful meaning when there is no baseline
reference for the starting point or ending point of the duration and
when Internet exchange latencies are completely unpredictable? In other
words, when a participant receives a duration value from another
participant, what does it mean? Duration relative to what point of time?
We do not know how many seconds it took for the service data to reach
the receiving participant.
But wait! Here are three more examples:
This fragment is from Section 3 (Address Resolution) of
draft-ietf-impp-srv-03:
A client determines the address of an appropriate system running a
server, on behalf of the system referenced by the domain, by
resolving the destination domain name that is part of the identifier
to either an intermediate relay system or a final target system.
This is the first, normative section in the document. Yet it does not
define 'address' nor refer to URI or URLs. There is no sense of what
"appropriate' means, nor what "system referenced by the domain" means.
Use of the term "identifier" suggests at least some confusion with the
otherwise-used term "address".
Or consider this fragment from Section 5 (Processing SRV RRs), ibid:
...
The choice of IM transfer protocol is a local configuration option
for each system.
Besides not indicating *whose* choice is being cited, this text leaves
quite a bit unspecified. The change that was previously suggested was
intended to make the roles and actions of participating parties
explicitly clear:
"Receiving systems that are registered for this DNS-based SRV resolution
service list the transfer protocols by which they can be reached, either
directly or through a translating gateway. The transfer-time choice of
the IM transfer protocol to be used (and, therefore, to be resolved) is
a local configuration option for each sending system."
Or consider this fine gem from from Section 5 (Processing SRV RRs), ibid:
Using this mechanism, seamless routing of IM traffic is possible,
regardless of whether a gateway is necessary for interoperation. To
achieve this transparency, a separate RR for a gateway must be
present for each transfer protocol and domain pair that it serves.
"domain <<pair>> that it serves"?
I suspect that this should be "transfer protocol and target domain that
it serves".
Let's face it: the proffered work has no realistic chance of meaningful
interoperable implementation.
CONCLUSIONS:
The proffered specifications represent many person-hours of
well-intentioned effort. However the documents suffer fatally from
delay, lack of focus, and lack of a clear charter. In their current
form, they represent a fundamental violation of IETF process; they have
no obvious user community to embrace them; and they would not work if
there were one.
/Dave
/Marshall
-----
Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com> (Brandenburg InternetWorking)
Marshall Rose <mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us> (Dover Beach
Consulting)