Re: Last Call: A Model for Presence and Instant Messaging to Proposed Standard

[[e-mail]]

Dave, Marshall,
	Given a previous exchange with Marshall on his proposed actions,
I'd like to be absolutely clear here on the intent of the message:

	Is this message your joint response to the Last Call?

	(If so, it and any subsequent discussion will be considered
                by the full IESG during its discussion of these documents)

	Is this message an appeal of one or more decisions?

               (If so, clarifications of exactly which decisions are 
being appealed
                and specifications of on which grounds will be needed.  This is
                necessary because one or more members of the IESG might have
                to recuse themselves from the discussion of an appeal of their
                own decisions.)

	Thanks for clarifying this point.
					Ted Hardie


At 4:37 PM -0700 6/26/03, Dave Crocker <[e-mail]>, Marshall Rose wrote:
>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 <[e-mail]> (Brandenburg InternetWorking)
>Marshall Rose  <[e-mail]> (Dover Beach Consulting)