[Top] [All Lists]

Re: Processing after the end of DATA

2010-08-11 10:38:13

On 8/11/2010 8:10 AM, Arnt Gulbrandsen wrote:
True. Sorry about contributing to topic drift.

oh, the excursion was fairly brief and well-indulged, IMO. Small rounds of this sort of review are probably good for the community collective...

I think my answer is that the receiver's permissible delay is governed by three

1. Doing as much as possible so as not to provoke blowback. Wasting an SMTP
client's time is not so bad, wasting a human reader's time is very bad.

I certainly took a community consensus that SMTP-time rejection is FAR better than a later DSN. And it might make sense to have some text that highlights this preference.

2. Staying within the client's specified time limit, ie. n minutes minus RTT,
and noting that RTT can still be high: "The client is not required to wait
longer than n minutes, and while the network is less temperamental now than it
the past, RTTs of 1-2 minutes may still be observed". (In the nineties an Indian
friend of mine suffered RTTs up to half an hour. I'm just guessing that two
minutes may be possible now, since people do use VPN over TCP and such horrors.)

There's a famous story of Bob Braden, from ISI, having a sabbatical in England and having his connection back to Los Angeles hang. He went for dinner and came back some hours later. The connection resumed...

My guess is that the RTT factor needs a multiple, to account for spikes in delay. Besides deciding on what the multiple should be, I'm a bit skittish about our playing with that number at all, rather than something more simplistic. This just doesn't seem like an activity that should entail a sophisticated calculation and RTT counts as sophisticated, IMO.

3. Accommodating standards-violating clients and NATboxes that drop connections
much too quickly. "Implementers should keep in mind that in the past, some NAT
implementations and clients have been observed to drop connections after less
than a minute" or whatever.

As specification language goes, I don't know what directives like "should keep in mind" means in practical terms. (This is the second time this week I've seen language like this creep into specification discussions; clearly it's a common issue.) I think we the purpose of a specification is to specify and that the question, in this case, is whether to recommend a different timeout and/or to recommend how the other side should handle a shorter timeout. (I think the latter has no solution.)

I think that could/should grow a paragraph mentioning these factors,
without upper case, and that they apply to all the client timeouts in principle,
but particularly in practice.

I am actually hoping for normative language.



  Dave Crocker
  Brandenburg InternetWorking