protocol vs. UI

At 10:43 AM 5/24/2002 +0200, Erik Nordmark wrote:
>No implicit change to the protocols i.e. an authoriative body needs to
>make an explicit decision to change the protocol, but user-interfaces
>are changed so that the user sees the friendlier name.

Erik, et al,

A fun topic, though perhaps academic for this working group.  But since the 
thread has cropped up:

Strictly speaking, IDNA very much involves a protocol 
change.  Specifically, it invents a new protocol.  One that is layered on 
top of the existing DNS (and still below the application layer.)

That it does not call for a change to the installed DNS base is, of course, 
fundamental, but IDNA is far more than a UI change.

It specifies rules for interaction between independent Internet 
systems.  It's difficult to imagine a better operational definition for 
"protocol".


>It turns out that there isn't such a strict line - one can debate
>forever e.g. whether the output of a Unix command line tool that can be piped
>to another tool is a protocol or a user interface; same for the cut&paste
>buffer.

One can define a UI to be sufficiently limited -- and the API between 
processes to be sufficiently textual -- so that, yes, an interprocess 
communication convention can be the same as a UI.

That trick has served Internet protocols well, but we should not carry it 
too far.

(FTP was expected to be a direct UI.  Didn't work, very well, did it?)

In reality, the model of Unix piping being a UI is not much of a UI.

That style of Unix use a classic batch system:  specify the job.  Hope it 
works right.  If it doesn't, specify the job all over again.  As we have 
come to expect in the world of GUI's, a UI that pays attention to the needs 
and capabilities of the U(ser) is pretty poor for interprocess 
communication.  At its best, a good IPC has truly terrible human factors.

So let's not get confused.  Protocols that use textual strings and 
human-typable commands are still protocols, not UI's.

There is enormous benefit in engineering the protocol to have certain 
human-friendly characteristics, but that is a long way from being 
realistically useful as a complete user interface.


>So I don't see how the document can provide any more useful advise to
>developpers with user-interface issues than it does by e.g. saying:
>...
>Any more informative advise would have to try to enumerate places (such
>as cut&paste, Unix commands using stdout, etc) where implementors should 
>think
>more carefully about this issue.

Might be useful for some industrious folk to write a document to assist 
implementors.   It would not be a normative specification of the protocol, 
but could look at the various choices and implications.  This would 
probably expedite deployment and successful interoperability of IDNA.

d/

----------
Dave Crocker <mailto:[email protected]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850