RE: CPIM changes

It makes me kind of uncomfortable as well - the real issue is whether or not
the gateway specification should be capable of mandating that any
CPIM-compliant protocol carries particular attributes with particular
syntactic properties (like an integer that is decremented on a per-hop
basis). Presuming we can't levy these sorts of mandates, it might be better
to abandon the loop-detection idea for CPIM entirely, rather than inserting
the somewhat spineless text I put in the current draft... but it would be
nice for gateways to be able to take advantage of mappable loop detection
mechanisms where they exist.

I expect we'll have the opportunity to discuss this further in Atlanta.

Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: Ben Campbell [mailto:[email protected]]
Sent: Tuesday, October 29, 2002 12:27 PM
To: Peterson, Jon
Cc: '[email protected]'
Subject: Re: CPIM changes


Peterson, Jon wrote:

[...]

> draft-ietf-impp-im-00 has a concept of a hop-count that is used for loop
> detection. Obviously, when a gateway interworks two IM protocols, loop
> detection is a very difficult quality to achieve, since we cannot
guarantee
> that any given mechanism for loop detection (such as a ttl-like
decrementing
> integer attribute vs. a Received-header-like way for servers to tell that
a
> message has reached them before) will be used by an IM protocol. So, the
> text in the current document says that gateways should if possible gateway
> between mechanisms used for loop detection, but loop detection itself is
not
> specified as an attribute for the messaging operation. Is that all right
> with everyone?
> 

[...]

This makes me vaguely uncomfortable. It seems to me that you are saying 
that, while we would like to gateway loop detection information, we 
cannot specify a common semantic. I think we really need to either 
specify semantic content for loop detection, or just assume the 
information will not pass a gateway.



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