Re: Open Issues from Recent Comments

[der Mouse <mouse%Rodents.Montreal.QC.CA@localhost>]

>> 6)  PENDIN opcode
>> Issue:  Why does PENDIN have an assignment.  It is really a dynamic
>> tty driver internal state.  It may not be the sort of state bit that
>> it makes any sense at all to push across the network.
>> Proposed Resolution:  I need someone to verify that.

> It's not entirely clear to me in which way it is an "internal state
> bit".  It's documented as

>   PENDIN    If PENDIN is set, any input that has not yet been read is
>             reprinted when the next character arrives as input.

Documented where?

I just had a look through the manpages I have at most ready hand
(NetBSD/sparc 1.4T) and the only documentation I find on it is in
termios(4) and reads

 PENDIN      /* XXX retype pending input (state) */

The string "PENDIN" occurs in only two of the drafts I have at hand,
assignednumbers-10 and connect-23.  Both document it the same way:

          62    PENDIN      Retype pending input.

> Is the difference that it is reset automatically by the tty driver
> after the requested action is completed?

Not only that, it is *set and* reset by the tty driver when
appropriate, at least in the kernel code I looked at - it really is
exposing the internal state bit the tty driver uses, not just allowing
userland to request retyping.  Since it controls retyping of input
received but still buffered in the kernel, it makes no sense to push it
across the network, since there is no way to push that unread input
with it.

Indeed, I'm not sure why it is exposed to userland at all.  Providing a
way for userland to request retyping of pending input is not
unreasonable, but making it a state bit like this is a bizarre way of
doing that.  But that's not an issue for us.

> Compare for example to

>   NOFLSH    If NOFLSH is set, the normal flush of the input and output
>             queues associated with the INTR, QUIT, and SUSP characters
>             will not be done.

> which is not an "internal state bit".

...and which is never changed except by userland (or by wholesale
resetting of tty state to whatever the kernel's idea of a clean tty
state is, upon something like revoke() or last close).

> The way I see it, the recent discussion has made clear that the
> benefit of requiring usernames and passwords to be normalized when
> sent as utf8 on the wire, is very questionable.

I see the value of specifying the charset on the wire at all as
questionable, since it demands that they be character strings; an
encoding-agnostic system has no way to convert its octet strings to
character strings.

As long as these things are specified as character strings on the wire,
I can't see anything sensible for an encoding-agnostic OS to do,
regardless of what encoding is chosen, regardless of normalization (if
applicable to the encoding), regardless of almost everything else in
this area.

> I intentionally wrote "should apply normalization" rather than
> "SHOULD apply normalization" in the last-but-one sentence, because
> it's a recommendation that must be applied consistently to all
> programs that access the user database.

*Exactly*.  It seems my choices as an implementer are to give up trying
to conform to the spec, or rework the entire OS and all third-party
software to use a character-string paradigm instead of the
encoding-agnostic octet-string paradigm it currently uses.

Is that really what we want?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse%rodents.montreal.qc.ca@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B