> Fair point on the pseudocode. My point wasn't so much that it's not useful
> as that it's hard and I have to carve out some time to sit down and try to
> do a better job of it. ;)
> Regarding 3.2, I think you're misinterpreting (due to, as I think Stephen
> pointed out, a misuse of the "MAY" terminology and general lack of clarity
> in this section). The point of 3.2. isn't that senders must be aware of the
> DNS TTL; it's that senders are only aware of the policy expiration
> ("max_age") and thus *receivers* should be cognizant of the fact that from
> a sender perspective, a policy may be valid for "ttl + max_age". Senders
> *don't* know the TTL in this formulation, but they (or their resolvers) do
> honor it.
> I believe this is clearer in the version in Github, however:
> Updating the policy requires that the owner make changes in two
> > places: the "_mta_sts" TXT record in the Policy Domain's DNS zone and
> > at the corresponding HTTPS endpoint. In the case where the HTTPS
> > endpoint has been updated but the TXT record has not been, senders
> > will not know there is a new policy released and may thus continue to
> > use old, previously cached versions. Recipients should thus expect a
> > policy will continue to be used by senders until both the HTTPS and
> > TXT endpoints are updated and the TXT record's TTL has passed.
> Let me know if that doesn't make it more clear. But tl;dr: senders do not
> need to know the DNS TTL.
This is much clearer, and addresses my concern.
Ned
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
