Subject: Re: I-D ACTION:draft-ietf-secsh-scp-sftp-ssh-uri-03.txt

From: Jacob Nevins <[email-masked]>
Date: Fri, 2 Sep 2005 14:14:41 +0100

Thanks for removing SCP.

There is no text tying words like MAY and MUST to RFC2119.

| 3.1   SSH connection parameters
| 
|    The following parameters are associated with an SSH connection and
|    are applicable to SSH and SFTP.  All parameters are optional and MUST
|    NOT overwrite configured defaults.
  [...]
|       The fingerprint parameter contains the fingerprint of the host key
|       for the host specified in the URL.
  [...]
|                        This parameter MUST NOT overwrite a key that is
|       already configured for the host.

There is an ambiguity here over whether the prohibition is of
overriding any cached host key for this session, or merely of
permanently replacing the cached host key.

Assuming both should be disallowed, "overwrite" should be changed to
"override" throughout.

| 6.  Security Considerations
  [...]
|                          If a locally configured key exists for the
|    server already it MUST NOT be automatically overwritten with
|    information from the URI.

Same comment.

| 3.2  SFTP Parameters
  [...]
|    typecode
| 
|       The typecode identifies the type of file which determines how it
|       will be treated.  [...]

No default behaviour is specified for the case where the typecode is
not present. This could lead to interoperability problems similar to
those which FTP has, where some clients default to ASCII mode, and
others to binary.

I think that "i" (no conversion) is an appropriate default in the
absence of further information; it's supported by all filexfer
implementations, and in any case is the "safe" thing to do if nothing
is known about the file.

I hesitate to mandate this as a default, however; implementations
should probably be free to use the "text-hint" attribute to determine
an appropriate transfer mode for the file, and also to open
directories in "d" mode.

How about the following text (new paragraph after the one above)?:

      In the absence of this parameter, files SHOULD be transmitted as
      if "i" had been specified.  However, information from the server
      (such as the "text-hint" attribute) MAY be used to select an
      alternative mode.

---

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 2 Sep 2005 09:14:19 -0700

> Assuming both should be disallowed, "overwrite" should be 
> changed to "override" throughout.
> 

[Joe] Yes. The intent is not to automatically "override".  I think this
change should be made 

> No default behaviour is specified for the case where the 
> typecode is not present. This could lead to interoperability 
> problems similar to those which FTP has, where some clients 
> default to ASCII mode, and others to binary.
> 
> I think that "i" (no conversion) is an appropriate default in 
> the absence of further information; it's supported by all 
> filexfer implementations, and in any case is the "safe" thing 
> to do if nothing is known about the file.
> 
> I hesitate to mandate this as a default, however; 
> implementations should probably be free to use the 
> "text-hint" attribute to determine an appropriate transfer 
> mode for the file, and also to open directories in "d" mode.
> 

[Joe] Thanks for the text, I think it looks good.