draft-ietf-impp-im-01 (was: Re: WG Last Call on multiple documents (deadline Jan 12))

Detailed comments are below.

The general comment is that the current version of the specification does
not contain nearly enough detail to permit unambiguous, interoperable
implementation.  Too much is assumed.

Much of this derives from the earliest CPIM specification text, but was
never discussed and resolved.

d/

Detail (compressed to skip text for which there are no comments):


                   Common Profile: Instant Messaging

<<
                   Common Profile: Instant Messaging (CPIM)
>>





3.1 Overview of Instant Messaging Service

...
   The message operation has the following attributes: source,
   destination, MaxForwards and TransID.  'source' and 'destination'
   identity the originator and destination of an instant message,

<<
   identity -> identify

   destination -> recipient
   [[ let's use comparable terms for sender and receiver, and we might as
   well use the same terminology as is used for email. At the least, we
   should be consistent. I'm taking the above usage to mean that
   source/destination refer to CPIM service 'target' fields and
   originator/recipient    refer to the sending mailbox and the receiving
   mailbox. /d]
>>


   respectively, and consist of an INSTANT INBOX identifier (as
   described in Section 3.2).  The MaxForwards is a hop counter used in
   order to avoid loops through gateways.  The TransID is a unique
   identifier used to correlate message operations to response
   operations.

<<
   The MaxForwards is a hop counter used in
   order to avoid loops through gateways.  The TransID is a unique
   identifier used to correlate message operations to response
   operations.
   ->
   MaxForwards is MaxForwards used as is a hop counter, to avoid loops
   through gateways, with usage details defined in Section 3.4.2. Its
   initial value is set by the originator.
   [[ What is the maximum value?  Minimum?  Integer?  /d]]

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

>>


   The message operation also has some content, the instant message
   itself, which may be textual, or which may consist of other data.
   Some further information on content is provided in Section 3.3.

<<
   Some further information on content is provided in Section 3.3.
   ->
   Content details are specified in Section 3.3
>>

   Upon receiving a message operation, the service immediately responds
   by invoking the response operation containing the same transaction-
   identifier, e.g.,


   The response operation contains the following attributes: TransID and
   status.  The TransID is used to correlate the response to a
   particular instant message.  Status indicates whether the delivery of
   the message succeeded or failed.
<<
   Add:
   Valid status values are defined in Section 3.4.1.
>>


3.2.1 Address Resolution

   A client determines the address of an appropriate system running a
   server by resolving the destination domain name that is part of the
   identifier to either an intermediate relay system or a final target
   system.
<<
   A client determines the address of an appropriate system running a
   server by resolving the destination domain name that is part of the
   ->
   An IM service client determines the next hop to forward the IM to
   by resolving the domain name portion of the service destination.
>>


<<
   The formal semantics of IM domain processing are defined in [2].
   Therefore,
>>
   Compliant implementations SHOULD follow the guidelines for
   dereferencing URIs given in [2].

3.3 Format of Instant Messages

   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
<<
   [[ sorry, but this is no longer true.  this spec now defines mandatory
   content syntax, in order to enable end-to-end security.  I suggest simply
   removing "; the message content definition given
   here pertains to semantics rather than syntax.  However,"  /d]]
>>

   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.  Implementations
   therefore SHOULD support the format defined in MSGFMT [4].
<<
   [[ "should" made sense when this was a spec for translating among
   heterogeneous systems.  The spec now is for relaying among systems that
   use the same end-to-end content (and addressing) syntax and semantics.
   Therefore, the requirement now must be a MUST.  /d]]
>>

3.4 The Messaging Service

   Note that the transaction-identifier parameters used with the instant
   messaging service are potentially long-lived.  Accordingly, the
<<
   [[ why are they potentially long-lived?  They are for the
   request-response transaction only.  Perhaps this is being confused with a
   content "message" identifier?  /d]]
>>

   values generated for this parameter should be unique across a
   significant duration of time.

3.4.1 The Message Operation

   When an application wants to send an INSTANT MESSAGE, it invokes the
   message operation.

   When the service is informed of the message operation, it performs
   these steps:
<<
   [[ What does "When the service is informed of the message operation?
   mean?  /d]]
>>

   1.  If the source or destination does not refer to a valid INSTANT
       INBOX, a response operation having status "failure" is invoked.
<<
   [[ every node along a path must determine the complete validity of both
   source and destination fields?  This is not viable.  What is the real
   requirement?  /d ]]
>>

   3.  Otherwise:

          If the 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, and
          if the delegation will not result in a future authoritative
          indication to the service, a response operation having status
          "indeterminate" is invoked.

          If the service must delegate responsibility for delivery, and
          if the delegation will result in a future authoritative
          indication to the service, then a response operation is
          invoked immediately after the indication is received.
<<
   [[ The implication of this "Otherwise" sub-section has just sunk in, for
   me.  It means 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
   -- ie, 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.  /d]]
>>

   When the service invokes the response operation, the transID
   parameter is identical to the value found in the message operation
   invoked by the application.

3.4.2 Looping


   If a CPIM gateway handles an instant message operation that has a
   MaxForwards attribute of 0, it discards the message and invokes a
   failure operation.
<<
   [[ Hop-count loop control requires specification of the precise
   place/time the decrement occurs and the precise place/time the zero-value
   causes a bounce.  That is, where in the state-diagram of a node are these
   things done?

   I propose that we keep the current language for decrementing, which means
   that it can occur at any time within a node's processing, but that we
   change "If a CPIM gateway handles" to be "If a CPIM gateway receives". /d ]]
>>


-- 
 Dave <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 t +1.408.246.8253; f +1.408.850.1850




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