IESG issue with transport draft: version string termination.

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

An AD had one comment on the document which caused him to issue a
"discuss" vote:

> My major comment is on draft-ietf-secsh-transport-16.  See comment number 4 
> on this document.    It says:
>
>    Page 6, first paragraph. The SHOULD NOT conflicts with the MUST
>    at the bottom of page 4. Suggestion: change the MUST at the bottom
>    of page 4 to SHOULD.

The revised -17 rearranges page breaks somewhat, so I checked a copy
of -16.  This refers to the text regarding backwards compatibility,
and whether a CR/LF is needed or just an LF.

The context of the "bottom of page 4" MUST:

   3.2 Protocol Version Exchange

      When the connection has been established, both sides MUST send an
      identification string of the form "SSH-protoversion-
      softwareversion comments", followed by carriage return and newline
      characters (ASCII 13 and 10, respectively).  Both sides MUST be
      able to process identification strings without carriage return
      character.  No null character is sent.  The maximum length of the
      string is 255 characters, including the carriage return and
      newline.

The context of the "first paragraph of page 6" SHOULD NOT:

      Clients using protocol 2.0 MUST be able to identify this as
      identical to "2.0".  In this mode the server SHOULD NOT send the
      carriage return character (ASCII 13) after the version
      identification string.

Proposed resolution:

I believe the intent of the document here is pretty clear: you use CR
LF to terminate the version string, unless you're doing backwards
compatibility, in which case you just send LF.

So, we change the first quoted section to start:

      When the connection has been established, both sides MUST send an
      identification string of the form "SSH-protoversion-
      softwareversion comments", followed by a line-terminator.
      The line terminator is normally two characters: a carriage
      return followed by a linefeed character (ASCII 13 and 10,
      respectively).  Both sides MUST be able to process ...

and change the second quoted section to:

      Clients using protocol 2.0 MUST be able to identify this as
      identical to "2.0".  In this mode the server SHOULD use a
      line-terminator consisting of a single linefeed (ASCII 10).
      after the version identification string.
	
I'd like a sanity check on this from implementors.

						- Bill