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
