In your previous mail you wrote: > > => unfortunately this is a change in the protocol the document is > > not supposed to do here even it both makes sense and follows the real > > world situation. > > I disagree that this is a change. > > RFC 1035 allows the server to close the connection at any time to reclaim > resources. It specifies a generous idle time, but clients cannot assume > that this is guaranteed - the server might be restarted, etc.
=> the RFC 1035 problem is it doesn't use the now standard MUST/SHOULD/MAY keywords so it has to be interpreted. In this particular case the cases where the idle time is not granted are clearly exceptions so IMHO the right interpretation is a server SHOULD accept some idle. This is confirmed by Paul Vixie's post and by a private conversation with Mark Andrews: - me - A server should be allowed to use the (idle) timeout it wants, even a zero one. - marka - This will break the SOA + xXFR case. So I am afraid it is both a change and a good topic for a discussion. > RFC 1035 also specifies that TCP connections can be closed abruptly, e.g. > with a RST. Clients must cope with this. => it doesn't change things (and BTW I believe most programmers even have no idea about how to abort (vs close) a TCP connection :-). > A client is buggy if it does not have a mechanism to retry queries that > failed because of a broken TCP connection. => I agree but if clients consider a broken TCP connection as an exception, e.g., marking the server as temporary unavailable, we are in trouble with the current proposed text (or mine :-). Thanks francis.dup...@fdupont.fr _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
