Minor comments on draft-ietf-secsh-filexfer-04

[Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost>]

Section 5.5 "Permissions": "...as defined by POSIX [1]": [1] isn't
POSIX. It would also be nice to have the relevant bit quoted so the
draft stands without POSIX.


Section 5.6 "Times": "A negative value..." [for atime etc]: atime and
friends are defined as `uint64' in sec 5.

>From draft-ietf-secsh-architecture-14, `uint64' "represents a 64-bit
unsigned integer", so can't go negative.

The architecture draft doesn't define signed types, so some words
indicating that that the putative "uint64" is to be treated as 2's
complement signed yadda yadda are probably needed.


Section 6.11 "Canonicalizing the Server-Side Path Name" (SSH_FXP_REALPATH):
It's not too clear how much of the path needs to exist at the time
REALPATH is invoked. This may cause interoperability problems.

At least one implementation (psftp) contains workarounds to handle
variant server responses to REALPATH("../path/to/nonexistent") where
"../path/to" exists but the path component "nonexistent" doesn't (for
instance when the client is planning to create a file or directory).

Some servers will apparently complain because "nonexistent" doesn't
exist, whereas others don't mind.

Not sure what the right fix is - it's probably more important that it's
defined than how it's defined. A conservative one would be to require
the path to exist in its entirety (so in the above case, clients would
ask about the destination directory, and then splice the filename on the
end). This would remove ambiguity about how it's intended to be used;
however, there are a few cases where 
   realname(path) + "/" + leaf  !=  realname(path + "/" + leaf)
for instance, if the client plans to mkdir(".."). This probably doesn't
matter.