Dave Crocker's & Marshall Rose's message

I and at least one other person did not receive this message via the IMPP
list, it had to be forwarded to me. I am (re)sending it to IMPP in case
others had likewise missed it.

--Mark

> > From: Dave Crocker [mailto:[email protected]]
> > Sent: Thursday, June 26, 2003 4:38 PM
> > To: [email protected]
> > Cc: [email protected]; ietf
> > Subject: Re: Last Call: A Model for Presence and Instant Messaging to
> > Proposed Standard
> >
> >
> >
> > 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




  [reminder: [email protected] for non-technical discussions, please]