Subject: latest drafts

From: der Mouse <[email-masked]>
Date: Thu, 23 Dec 2004 00:10:32 -0500 (EST)

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	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Sam Hartman <[email-masked]>
Date: Fri, 24 Dec 2004 17:37:23 -0500

>>>>> "der" == der Mouse <[email-masked]> writes:

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

My requirement as an IESG member is that it be possible to have a
properly internationalized ssh.  Among other things that means the
characters in usernames and passwords need to belong to some character
set.  IETF character set policy requires one of the character sets we
support be UTF8.

Personally, I'd be delighted if you could work within this requirement
and figure out implementation advice or language that made it
possible/easier for people on Unix and other systems where local
characters are not tagged with a character set.  I believe the
documents are acceptable if you don't manage to solve this problem;
only accepting ASCII is one way to implement the protocol.  I suspect
people who find better solutions will have an advantage in certain markets.  

Naturally, it's Bill/the working group's decision how much time should
be spent trying to solve this problem.  Bill may well believe the
problem has already been discussed to death and decide that it's not
worth any more of the WG's time.

--Sam

---

From: der Mouse <[email-masked]>
Date: Fri, 24 Dec 2004 17:39:21 -0500 (EST)

>> All the same UTF-8 issues I've raised repeatedly,
> characters in usernames and passwords need to belong to some
> character set.

Why?  Perhaps this is the fundamental part I'm missing.  What does
"properly internationalized" mean - or perhaps more precisely, what is
there about being "properly internationalized" that demands that
usernames, passwords, and filenames consist of character sequences
rather than octet sequences?

> Personally, I'd be delighted if you could work within this
> requirement and figure out implementation advice or language that
> made it possible/easier for people on Unix and other systems where
> local characters are not tagged with a character set.

I doubt that's possible, because the characters, if any, those octet
sequences are intended to correspond to are not stored anywhere
accessible to ssh (and indeed may not exist - the octet sequences may
correspond to characters only coincidentally, by someone insisting on
interpreting them as character codes, such as for display).

> I believe the documents are acceptable if you don't manage to solve
> this problem; only accepting ASCII is one way to implement the
> protocol.

I find that...well, unacceptable, really.  There is no reason except
administrative fiat that the various octet strings in question can't be
real transparent octet strings, to be interpreted as characters, if at
all, by mutual agreement between the entities doing so.  For example,
I, on a charset-blind system, may name some files with octet sequences
that make sense in 8859-1 and others with octet sequences that make
sense in KOI-8, relying on other information (stored nowhere but my
wetware) to disambiguate which is which.  There is no technical reason
I couldn't sftp them to another, similarly charset-blind, system; it is
purely fiat that would prevent it.

Of course, it breaks when trying to sftp to a charset-aware filesystem,
unless I choose to use UTF-8 on the charset-blind side.  That's
unavoidable, no matter what the standard says; interoperability between
charset-string filesystems and octet-string filesystems without human
help cannot be expected in any case.

Similar remarks apply to usernames and passwords, though the examples
I've come up with are more contrived.

> I suspect people who find better solutions will have an advantage in
> certain markets.

I think my implementation, being for charset-blind systems, will treat
such things as pure octet sequences.  I may add an option to disallow
non-ASCII (or perhaps just disallow anything that's not well-formed
UTF-8), but if so it will be to satisfy protocol conformance pedants,
and be documented as such.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign