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
concerns:
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 4.5.3.2 could/should grow a paragraph mentioning these factors,
without upper case, and that they apply to all the client timeouts in principle,
but particularly 4.5.3.2.6 in practice.
I am actually hoping for normative language.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net