Hi Daniel, > On 11 Sep 2016, at 14:56, Daniel Margolis <[email protected]> wrote: > > There was some discussion of this at IETF96: Should we be specifying timeouts > on the HTTPS GET during policy fetch? > > I was looking at RFC 2821's timeouts for comparison (section 4.5.3.2): > > "Based on extensive experience with busy mail-relay hosts, the minimum > per-command timeout values SHOULD be as follows..." > > The initial 220 timeout is recommended to be 5 minutes. But then I took a > look at qmail and postfix, and if I am reading the docs correctly their > default timeouts on connect are 60 and 30 seconds respectively. > > So this sort of makes me think that we should not bother to suggest specific > timeouts in the RFC, as I am not sure how useful they will be. (Now, granted, > the world has changed since RFC 2821 was written; it's hardly a sign of > failure if 15 years later your timeouts aren't quite the norm!) > > Any contrary opinions on this? And if so, any specific thoughts on what those > timeouts should be?
I am on the fence about specific timeouts, but I think saying something like "HTTP timeouts MUST be configurable" would be a good thing, in order to draw implementors attention to this. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
