Re: Loops (RE: CPIM changes)

Tuesday, November 12, 2002, 2:03:55 AM, you wrote:
>>> From: Dave Crocker [mailto:[email protected]]
>>> The answer is yes.  Email has worked without a standardized mechanism for
>> 30 years.

Harald> Email has worked with Received: header counting for 30 years;

1. A number of different mechanisms have been used over the years. Counting
the number of Received headers has been only one of them. (The one I used to
use was to count the received headers actually produced by the system doing
the counting. That is, it did not intuit looping, as counting the total
number of loops requires. It detected actual looping.)

2. I said standardized.  What I missed was that RFC 2822 added this to the
email format standard.  RFC 822 did not have it.  So, yes, Internet mail
does have a standard for loop control.  It was added a year and a half ago.

3. RFC822 is a format standard, not a gateway service standard. The topic
being discussed hear is about requiring loop control in a gateway for any
instant messaging system.

4. Received headers were not in RFC 733.  They were added in RFC 822.  So
loop detection with Received headers could be done for a mere 20 years...


Harald> we've even gatewayed them into X.400 and back out

No doubt you are not using a single example to prove the general case?


Harald> Technical note: Any transport that can carry an arbitrary piece of
Harald> "envelope" information Harald> between a gateway and the next
Harald> gateway without munging it is capable of supporting a hopcount.

That is a demanding requirement. Since the topic, here, is gatewaying among
instant messaging services, it suggests that you believe that it ok to
expect this extensibility among typical instant messaging services.

Does it already exist for the significant, existing ones?

(This is almost a trick question, given that IETF email work usually
presumes that header munging will occur.)

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]