Re: Bruce Schneier's Proposal to dedicate November meeting to savingthe Internet from the NSA

[John C Klensin <[e-mail]>]

--On Friday, September 06, 2013 08:41 -0700 Pete Resnick
<[e-mail]> 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