--On Friday, September 06, 2013 08:41 -0700 Pete Resnick <presnick@xxxxxxxxxxxxxxxx> wrote: >... > Absolutely. There is clearly a good motivation: A particular > UI choice should not *constrain* a protocol, so it is > essential that we make sure that the protocol is not > *dependent* on the UI. But that doesn't mean that UI issues > should not *inform* protocol design. If we design a protocol > such that it makes assumptions about what the UI will be able > to provide without verifying those assumptions are realistic, > we're in serious trouble. I think we've done that quite a bit > in the security/application protocol space. Yes. It also has another implication that goes to Dave's point about how the IETF should interact with UI designers. In my youth I worked with some very good early generation HCI/ UI design folks. Their main and most consistent message was that, from a UI functionality standpoint, the single most important consideration for a protocol, API, or similar interface was to be sure that one had done a thorough analysis of the possible error and failure conditions and that sufficient information about those conditions could get to the outside to permit the UI to report things and take action in an appropriate way. From that point of view, any flavor of a "you lose" -> "ok" message, including blue screens and "I got irritated and disconnected you" is a symptom of bad design and much more commonly bad design in the protocols and interfaces than in the UI. Leaving the UI designs to the UI designers is fine but, if we don't give them the tools and information they need, most of the inevitable problems are ours. > OK, one last nostalgic anecdote about Eudora before I go back > to finishing my spfbis Last Call writeup: >... > Working for Steve was a hoot. I can only imagine, but the story is not a great surprise. john