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

["Peterson, Jon" <jon.peterson@neustar.biz>]

As I was doing this last pass on impp-im and impp-pres based on IESG
feedback, I reviewed again the technical failures cited by Marshall and Dave
in their LC comments. I am making no resulting changes in the specific areas
of the document they identify, but I wanted to record the justification for
not doing so.

- J

> 
> 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.
> 

For "split" I would read "compromise", of course. That compromise is built
into the concept of CPIM itself, yes.

> 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.

Unsubstantiated, for some reason. Surely they could supplied some examples
of requirements conceivably related to gateway behavior that were not met in
the impp-* family.

>     
> 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.
> 

The document has some very specific wording about the circumstances in which
the use of MSGFMT is required - namely, those cases in which e2e security is
desired. The statement above tells it like it is: if you don't want e2e
security, you'll never use MSGFMT, and interworking requires no e2e formats.
If you do want e2e security, you need an e2e format. The document does
require applications that send messages to gateways to support MSGFMT, so
that users will always have the opportunity to avail themselves of e2e
security, but I don't see how this is likely to impede interoperability.

> 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.
> 

I agree with this point, actually, but it's pretty specific to MSGFMT and
has no impact on impp-im. I also argued that we should use some pre-existing
message format if possible. Of course, MSGFMT Section 1.2 does contain some
lengthy justification for not using RFC822/2822 which Dave does not address
here. Other reasons why an XML format was not selected were provided on the
mailing list.

> 
> 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?
> 

There was significant discussion about uniqueness in the IMPP mailing list,
and one thing it quickly demonstrated was that different IM protocols had
different ways of guaranteeing transaction uniqueness, and specifying
anything in particular would put some protocols at a disadvantage.
Obviously, its use (in correlating operations to responses) speaks to the
scope of its uniqueness. The document also gives an upper bound to the size
of TransIDs. See the following:

<thread>

Document text:
   TransID is a unique
   identifier used to correlate message operations to response
   operations.  It is created by the originator and must be unique to the
   request.  That is, each request shall carry a different TransID.
   [[ What is the form of the TransID?  How is uniqueness guaranteed? What
   are the limits on it?  /d ]]


Jon> We opted not to specify this, actually - it is listed just as an
arbitrary
Jon> string. Different protocols will undoubtedly have different ways of
Jon> determining uniqueness that might be protocol-specific. I am kind of
Jon> surprised that you want to mandate some format, actually, since in the
past
Jon> you have vociferous opposed mandating any sort of common formats for IM
Jon> protocol fields.

Dave:
Oh.  Ok.

So, a megabyte string of random 8-bit values is a valid TransID and we
require IM nodes to properly support such a TransID?

</thread>

So, Dave's concern, in so far as it was articulated, was merely that the
TransID have some kind of sizing. Which it does. If he had articulated any
further constraints for the field, they would been considered for inclusion.

> 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.
> 

The alternative would be to impose a format on that attribute of the
operation, a strategy that Dave was not eager to endorse.

>     
> 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?

This (and other comments on the fuzziness of "service") ignore the
definition of "instant messaging service" given in the Terminology section.

> 
> 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.
> 

See RFC2779 4.2.1. The WG interpreted this as a requirement for a DSN-like
capability here. Dave does not explain what, in particular, makes this an
intolerable requirement.

Note that individual IM protocols may have their own internal hop-by-hop
reliability mechanisms to ensure message delivery. However, gateways need
not be aware of these, and the value of communicating anything about
hop-by-hop delivery across gateways was considered highly questionable (and
outside the scope of "minimal interoperability").

>     
> 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.

There was a significant thread about the use of absolute time versus
relative time in the duration attribute of subscribe operations. Some argued
that indeed, both an absolute and a relative time indicator were needed. The
consensus of the group was that clock skew was as considerable a factor as
Internet exchange latencies, that the two options were therefore roughly
commensurate, and that therefore using relative time would be adequate (and
easier to ensure minimal interoperability, since you would have to worry
about time-format conversions). The duration is clearly from the time that
the subscribe operation was received (this is in fact clearly stated in the
text, in the section titled "The Subscribe Operation"). I suppose we could
have documented all of this in the draft, but at the time I didn't see the
need.

> 
> 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.
> 

The sort of "address" you get by "resolving the destination domain name"
should hopefully be obvious to even the least technically savvy reader. Note
that the subsequent paragraph (which is elided above) contains more
normative language, and the descriptive text above does not - the fact that
this sentence is in a "normative section" is immaterial.

> Use of the term "identifier" suggests at least some confusion with the
> otherwise-used term "address".
> 

The "identifier" here is the URI (what does the "I" stand for again?), and I
don't believe it risks conflation with the "address". The more precise
variants of these terms are used in the subsequent paragraph.

> 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."

Um... actually, that suggested text is already in impp-srv-03, right after
the fragment cited above. Perhaps they missed it.

>     
> 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".
>     

Well, no, then the text would be saying that you have one RR for a transfer
protocol and a different RR for the domain, which would not be correct. The
text above, while probably not optimal, is better than the proposed change.
The "pair" is the binding between the transfer protocol and the domain.