> On 1 Aug 2023, at 17:00, Dave Crocker <d...@dcrocker.net> wrote: > > On 8/1/2023 8:56 AM, Barry Leiba wrote: >> The eventual product should point back to the problem statement for >> the background information. > > That is certainly a valid approach. However I suggest it's less efficient > for this topic and possibly will lose some casual readers of the spec, by > virtue of the indirection. (Extra clicks cost usability.)
I’m not sure this is a problem, actually. It’s likely we’ll lose those casual readers anyway, if they’re bogged down in background information. > I suggest, instead, whatever spec is produced have a statement of the > problem. This is a relatively simple problem to explain. No doubt the text > will be drawn from this draft. Of course the spec will have a statement of the problem. The question here is: how much does the spec focus on the spec vs. how much does it discuss all the examples and data about why we got to this as the spec. I think that the why, condensed down in a supporting document, is valuable. I think, though, that as part of the spec it’s a distraction. laura (participating) -- The Delivery Expert Laura Atkins Word to the Wise la...@wordtothewise.com Delivery hints and commentary: http://wordtothewise.com/blog
_______________________________________________ Ietf-dkim mailing list Ietf-dkim@ietf.org https://www.ietf.org/mailman/listinfo/ietf-dkim
