RE: Loops (RE: CPIM changes)

I think there is a reasonable risk that a CPIM architecture without loop
detection would be unsound. In the past, we have not refused to define
attributes (like, say, the TransID) on the grounds that some protocol we
conceivably would want to gateway might not support this concept. If some IM
protocol (and in the wide world there probably is one) has no concept
comparable to a TransID, it simply would not be able to be gatewayed by
CPIM, as CPIM is currently defined. I understand from previous mails, Dave,
that your view is:

> The problem of gatewaying is that the gateway does not get to dictate what
> the participating systems do. 

... but I think we already dictate quite a bit (all of the attributes and
operations in impp-im-00), and in fact we -must- guarantee a certain level
of commonality if any gatewaying is to be possible - this is really a
question of whether or not we consider loop detection to be a 'core'
function that we must dictate. Protocols that did not meet this requirement
would not be gateway-able without some modification.

The requirements of RFC2779 did not include loop detection, as far as I can
tell. This could argue that loop detection is not a 'core' capability.
However, if CPIM gateways (which also were not envisioned by RFC2779)
introduce the risk of loops, we do have an obligation to address (or at
least acknowledge) that deficiency. There are obvious cases (related to
forwarding) in which loops could occur. If we aren't going to dictate
support for a loop detection mechanism, I think we need a pretty good
excuse.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dave Crocker [mailto:[email protected]]
> Sent: Wednesday, November 13, 2002 10:47 AM
> To: Mark Day
> Cc: Dave Crocker; [email protected]; [email protected]
> Subject: Re: Loops (RE: CPIM changes)
> 
> 
> Mark,
> 
> 
> Wednesday, November 13, 2002, 10:16:49 AM, you wrote:
> Mark> It has been a long-standing principle of IMPP, endorsed 
> by the ADs, that the
> Mark> goal of the WG is to produce a sound architecture for 
> presence and instant
> Mark> messaging
> 
> Perhaps we can focus on the particulars?
> 
> Nothing being discussed here leads to an unsound 
> architecture. If you simply
> want me to shut up, please say so directly rather than trying 
> to promote a
> view that the issues I am raising involve unsound 
> architecture. I have been
> very careful to point out the considerable basis for each 
> suggestion I am
> making.
> 
> We have experience doing gatewaying.  We should attend to its lessons.
> 
> 
> Mark> It would be great to understand the impact of our 
> design choices on those
> Mark> deployed services, but to date we have not had a lot of 
> luck in getting
> Mark> credible analysis.
> 
> On the other hand, we certainly know that imposing end-to-end 
> requirements
> for non-core functions is likely -- for that matter, nearly 
> certain -- to
> require changes in existing end-systems.  At that point, this is not a
> gatewaying effort, it is a relaying effort.  That's not what CPIM was
> supposed to do.
> 
> d/
> -- 
>  Dave Crocker  <mailto:[email protected]>
>  TribalWise <http://www.tribalwise.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]