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

Some responses inline. Most of the suggested revisions below are fine. These
will be incorporated in an -02 that will appear after last call concludes.

The one issue here that took me by surprise was your sudden recommendation
to upgrade the normative SHOULD for support of MSGFMT to MUST, on the
grounds that CPIM is no longer a system intended to interwork between
heterogenous systems. This suggested change has a few other ramifications
throughout your notes on this document set. 

We spent some time discussing this previously, and I thought we had agreed
to bring this issue before the IESG as a SHOULD, not a MUST. I have
suspected that since this would not constitute mandatory end-to-end
security, the IESG might have a problem with it - but, we could try to make
a case for a SHOULD, and I had thought that was our direction. Do I
understand correctly that we now want to take this to the IESG as a MUST?
Any other opinions in the group on that?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Monday, January 06, 2003 3:29 PM
> To: [email protected]
> Subject: draft-ietf-impp-im-01 (was: Re: WG Last Call on multiple
> documents (deadline Jan 12))
> 
[snip]
> 
> 
>                    Common Profile: Instant Messaging
> 
> <<
>                    Common Profile: Instant Messaging (CPIM)
> >>
> 

Done.

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

Done.

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

I'm okay with that, I guess.

> 
>    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.
>    ->
>    MaxForwards is used as 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]]
> 

That's fine. I think we should specify the minimum value in Section 3.4.2
(there is already some text there about that).

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

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

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

Sure, that's more concise and less cumbersome.

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

Sure thing.

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

Better, I agree. It is possible that the next hop will be the final
destination in some systems, no doubt, but I don't think this would be
unclear from the text above.

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

Okay.

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

It isn't mandatory - the test below says "SHOULD".

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

Um... this is a somewhat major reversal philosophically... do you really
want to do this? I wasn't aware that we had changed the direction of the
spec, as you state above. When did we introduce this change?

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

Hmm. I suspect that this text was a hold-over from CPP, actually, where
subscription transactions are potentially long-lived. I agree that IM
transactions are likely to be short-lived. Does anyone have a reason why we
shouldn't relax this restriction in the IM draft?

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

Yes, that is awkward. I think it means, 'When an endpoint receives a message
operation". The term 'service' here is the problematic one.

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

I think it means that an endpoint/gateway may receive a messages for a
destination that plainly not semantically or syntactically valid (say, a
domain name in the URI that is unresolvable, or the username is not valid
for the endpoint). 

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

Again, I think this really depends on how we read the term 'service'. Does
it mean endpoints? Does it mean gateways? Does it mean intermediaries other
than gateways (proxies)?

I think this last paragraph suggests that it can mean gateways. I agree with
your analysis; this does create a dependency chain, effectively. I think
this is appropriate, however, in so far as the group in the past has wanted
end-to-end delivery confirmation for instant messages, not hop-by-hop
confirmation.

We discussed, for example, whether or not we could assume underlying
reliability of message delivery hop-by-hop, and decided that we could and
should assume it to be in place. The purpose of the response operation is to
indicate, from an authoritative source (the endpoint or the endpoint's
service provider, if the endpoint is unavailable) whether or not the message
has been delivered. Gateways should only generate response operations
themselves in error cases, when for whatever reason the message is
undeliverable.

I agree that this is effectively like a DSN. Again, I thought this was what
we wanted.

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

I think "if a CPIM gateway receives" is indeed better than "handles" for the
reasons you describe.

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



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