latest drafts

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

I just fetched the latest drafts and looked over the diffs from my
previous latest set (and in the process discovered that I skipped a
set; a new set must have come out while I was busy with other things).

Looking at the diffs between architecture-18 and -20,

(about line 112)
   The major original contributors of this set of documents have been:
   Tatu Ylonen, Tero Kivinen, Timo J.  Rinne, Sami Lehtinen (all of SSH

s/J. /J./ surely?  Looks to me as though something is mistaking the
initial-marking dot for a sentence-ending dot.

Somewhere around line 495,


      identifiers (see Section 6 below), or a list of [RFC3066] language
      tags.  The order of the names in a name-list may, or may not be
      significant.  Again, this depends on the context where the list is
      used.  Terminating null characters MUST NOT be used; neither for

I'd rather see "may or may not be" or "may, or may not, be" - but to
put in one comma but not the other looks broken in a "half of one and
half of the other" sort of way.  (Personally I'd prefer the comma-free
version, but I'd much rather see the two-comma version than what's
there now.)

About line 1321:

    display forwarding in SSH (or other, secure protocols), combined with

s/other,/other/ surely?

In assignednumbers-10, as diffed against -08:

Around line 176, the same "Timo J. [ ]Rinne" issue as above.

In sections 4.2 and 4.2.2, the table headings make it appear that the
SSH_DISCONNECT_* names *are* the "description" strings appearing in an
SSH_MSG_DISCONNECT packet, which I assume is false - if that were true,
the "description" would carry no information not already present in the
"reason code".  Specifically, the (new) first two lines of text in
4.2.2 comes very close to stating that the table shows the strings as
they must appear in a DISCONNECT packet.  The text around line 425
further implies that the "description" strings are standardized, which
I had thought was not the case - and which makes no sense because they
then carry no information and might as well be skipped.

Similar remarks apply to the like-named fields mentioned in 4.3 (lines
432 ff) and 4.3.2 (lines 445 ff).

In 4.5.2, most of the symbolic names are missing TTY_OP_ prefixes.  Is
this deliberate?

In any case, I have to question why PENDIN has an assignment.  It is
really dynamic tty driver internal state (exposed so, I suspect, a user
program can force a reprint by setting it); it is not the sort of state
bit that it makes any sense at all to push across the network.

I very much like the text in 4.10 about the diffie-hellman-groupN-sha1
name debacle; I think the wording there is an excellent resolution
given the mess that discussion turned into here.

In connect-23, diffed against -21:

The same "Timo J. [ ]Rinne" issue again.

The remarks about TTY_OP_ values, above, also apply to the versions
appearing here (starting around line 970).

In transport-22, diffed against -20:

"Timo J. [ ]Rinne" again.

In userauth-25, diffed against -23:

"Timo J. [ ]Rinne" again.

All the same UTF-8 issues I've raised repeatedly, but apparently that
is a lost cause; ssh implementations for traditional Unix systems, and
others that use octet sequences rather than character sequences for the
"version that matters", will just have to reject non-ASCII usernames,
passwords, and file names out of hand.

/~\ 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