On Wed, Sep 07, 2016 at 11:27:00PM +0200, Daniel Margolis wrote:
> I would be inclined to make a suggestion that implementors think about this
> possibility and that careful implementors may reasonably want to limit
> attempts to less than once every n minutes. If my previous observations
> about RFC mandated timeouts are any guide, implementors will sort of go do
> their own thing anyway, so I don't think we should bother to *mandate*
> anything
> specific; conversely, it doesn't seem to me that recipients really benefit
> from having a knob to turn on the retry frequency, so this doesn't really
> need to be specified per-policy.
>
> "A careful implementation may wish to limit the number of refresh attempts
> in the case that the TXT record indicates a refreshed policy is available
> but the HTTPS fetch fails for any reason. We suggest implementations may
> limit these attempts to a period of five minutes or longer per version ID."
>
> Or something. Reasonable?
Likely close enough, unless others feel that recipient policy should
give receiving sites the flexibility to signal preferred
refresh/retry/expire timers (the current spec already specifies
expire, and refresh is signalled out of band via DNS, so perhaps
an implementation selected retry is good enough.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
