> (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
