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.
On Wed, Sep 28, 2016 at 7:30 PM, Ned Freed <[email protected]> wrote:
> > (Sorry for the late reply. I was on vacation.)
>
> > As Janet said, thanks for the feedback. A few specific points:
>
> > 1. Agreed on the psuedocode. I had actually removed it entirely from the
> > latest draft in the Git repo (github.com/mrisher/smtp-sts) because I
> also
> > didn't find it to be of much value.
>
> Actually, there's no agreement here whatsoever since I regard simply
> removing
> the pseudocode as the worst thing you could possibly do.
>
> > I do agree with you and Viktor that
> > fleshing out a hypothetical implementation can make things a lot easier
> for
> > implementors, but doing so in a way that is sufficiently specific to be a
> > useful guide yet sufficiently generic as to be applicable in most cases
> > isn't trivial.
>
> Did you take a look at the code I came up with? I don't believe there
> was anything in it that made it specific to any particular implementation.
>
> > I had punted on this in the current version in head because
> > I didn't have a great idea of how to express this--as Viktor notes,
> > diagramming the state machine may in some form be helpful; I'm not 100%
> > sure pseudocode is in fact the right way to do it. Thoughts?
>
> I could not care less about the format you use. But the fact is right now
> you
> have a document that defines a process consisting of a precise series of
> steps
> which presents those steps out of order and which, without some
> psuedocode, a
> flowchart, an outline, whatever to tie it all together is pretty much
> guaranteed not to be implemented correctly.
>
> > 2. In what case is DNS TTL information needed?
>
> Section 3.2, first paragraph. There's also been discussion of making more
> use of DNS TTL info on the list.
>
> Ned
>
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
