IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

RE: New draft-draft of sftp...



I don't recall seeing any discussion on the proposed "file is hidden" flag.

I have no problems with it, though it will not be used in a VMS
implementation.

No problems with the rest of the changes below either.

-----Original Message-----
From: Joseph Galbraith [mailto:galb-list%vandyke.com@localhost]
Sent: Monday, November 25, 2002 4:40 PM
To: ietf-ssh%netbsd.org@localhost
Subject: New draft-draft of sftp...


Greetings,

Here, is a new draft-draft of the sftp draft.

Changes are a little bit more extensive than
I remembered at the meeting:

o Copied more NFS to clarify ACLs and reserved
  identifiers for the ACL who field.  Thanks
  Richard.

  (I may need to do one more round of this--
  in the context of normative vs. non-normative,
  I would prefer our NFS references to be non-normative,
  which means we have to included sufficient
  information to stand alone.  Probably a good
  idea anyway.)

o Change times to be 64 bit + 32 bit nanosecond
  field (as per decision at meeting and NFS.)

o Added additional optional extension to allow the
  server to tell the client that it compares files
  in a case insensitive way, or that files are stored
  in a case insensitive way.  Since globbing is done
  on the client, the client needs this information
  to "get it right".  In the absence of the extension,
  client is to assume 'case sensitive'.

I would like to make one more change that I know of:

o add a bit to the type field to flag whether the
  file should be hidden.  Under most unixes files
  beginning with a '.' should be hidden.  Windows
  represents this with an attribute bit.  So, only
  the server can really tell whether a given file
  should be hidden (by default) or not.

If people are okay with this I will make this change
and submit.

We are in a hurry here because we want to get this
out before we have implementers so that we don't
have to rev the version field again.

Are any of the unix implementers out there looking
at this revision any time soon?  As I mentioned at
the working group meeting, I would like to have a 
unix implementation to make sure we have made things
onerous for unix / posixish systems.

Thanks,

Joseph



Home | Main Index | Thread Index | Old Index