Dave Crocker responds to my suggestion: >> rfc6376 has: [...] >> Would it be so awful to change that to: >> >> Note that Verifiers may treat unsigned header fields (or >> unsigned parts of header fields) with extreme skepticism, >> including refusing to display them to the end user, displaying >> them with an indication of unreliabiliy, or even ignoring the >> entire signature if it does not cover certain header fields. >> >> So, risking Dave's wrath once again by discussing possible UI >> approaches to verification information, if a header tag format >> were specified (for example) to be contained within square >> brackets, the UI could display the verified part one way, >> and the tagged-and-ignored part another way.
> To make any assertions about preferred or appropriate UI behavior is to > require establishing the basis that the behavior will be useful. I dispute the idea that the above text makes assertions about "preferred" UI behaviour - rather, it mentions what might be possible (and yes, implies that it could be appropriate), without excluding other approaches. > The problem here is that the empirical basis for efficacy is lacking. True, and I agree that it's not up to us to propose user interface designs. But our work will be used by UI designers; how can we best make sure that we give them the informational tools they need in order to display a given message "appropriately"? Do you propose that since the UI is outside our scope, that we give no consideration at all to the tools that might be needed in order to implement a UI? Anne. -- Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8 a...@encs.concordia.ca +1 514 848-2424 x2285 _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
