Re: A future for the SSH File Transfer Protocol?

["Joseph Galbraith" <galb-list%vandyke.com@localhost>]

> "Joseph Galbraith" <galb-list%vandyke.com@localhost> wrote:
> 
> > I'm definitely interested in this.  Can you repost your proposal?
> 
> Certainly. It's available as a text file from
> 
>   http://www.tartarus.org/~simon/ssh/draft-sftp-userdb-00.txt

Whoops -- I didn't realize our conversation on this
had wandered off the list.

I've actually had a chance to read the proposed
extension now -- and realized I actually did read
it when you originally posted it :-)

Here are some comments (some of which you've seen
in the mail that wandered off the list.)

> The USER data type, encoding a user database entry,
> is defined here:
>
>   uint32   flags
>   uint32   uid            always present
>
> The `uid' field specifies the numeric user ID of the entry. It MUST
> have the same meaning as the numeric user IDs used in the ATTRS
> compound data type in the main SFTP protocol. The `uid' field has no
> corresponding flag and MUST be present.

As I mentioned in my previous mail, NT doesn't use
simple 4 byte user identifiers.  Given that the UID
field MUST be present, I couldn't implement this
under NT.

So I think we should use the opaque

  string identifier

here as well.  (See my previous email to the list
"uid & gid in sftp")

The same thing applies in the GROUP data type for
gid.

Also, I would suggest that the requests actually be
as follows:

     uint32   id
     string   sftp-userdb-getuserbyuid%sgt.greenend.org.uk@localhost
     uint32   count
     count occurrences of 
         uint32   uid

and the reply format be:

     uint32   id
     uint32   count
     count occurrences of
         USER     user

uid or usernames that don't occur in the
resultant list are assumed to have been
unresolvable.

What do you think?

- Joseph