Hi Daniel, > On 12 Sep 2016, at 12:02, Daniel Margolis <[email protected]> wrote: > > Thanks to both of you for the feedback. > > Viktor, I certainly agree that that's a reasonable ballpark number, based on > my experience. But I still have a slightly odd feeling about specifying > specific numbers in the spec for the reasons I gave. > > Alexey, I like your idea. This seems more in line with what I had been > imagining, i.e. we say to implementors, "here be dragons; think twice!" > rather than telling them what specifically they should do. Though (to be > slightly pedantic) this seems slightly odd for a MUST, since configurability > isn't per se a protocol feature.
It is a manageability feature and such features can be described with RFC 2119 language. The main point I was trying to convey is that implementations shouldn't have hardcoded values, as these might need to be tweaked over time. > Could we just say, "Implementors should consider what values may be > reasonable for HTTPS request timeouts; in our initial implementation we > expect timeouts of 5 seconds to be sufficient?" That would be a fine thing to say, but, IMHO, it should be said in addition to the above. > > What do you think? There's a tiny touch of bike-shedding to my comment above, > I admit, but if we didn't bikeshed we'd never decide what color to paint the > damn thing, amiright? > > Dan > >> On Mon, Sep 12, 2016 at 9:18 AM Alexey Melnikov <[email protected]> >> wrote: >> 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
