RE: filexfer draft ready for last call?

["Richard Whalen" <Whalenr%process.com@localhost>]

> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost [mailto:ietf-ssh-owner%NetBSD.org@localhost]On
> Behalf Of Joseph Galbraith
> Sent: Monday, July 10, 2006 5:41 PM
> To: der Mouse
> Cc: ietf-ssh%NetBSD.org@localhost
> Subject: Re: filexfer draft ready for last call?
> 
> 
> der Mouse wrote:
: 
> >> 7.6.  Permissions
> > 
> >>    This protocol uses the following values for the symbols 
> declared in
> >>    the POSIX standard.
> > 
> >> [...]
> > 
> >>    Implementations MUST NOT send bits that are not defined.
> > 
> > This makes it impossible to send, for example, VMS "delete 
> permission"
> > bits.  Is this really desired, or is this being left up to
> > implementation experimentation before standardization?
> 
> But no one would know how to interpret those bits-- a client
> including those bits to a server that expected posix modes
> could / would cause problems.  (And in fact we had a case
> like this as AIX uses addition bits which we were sending
> on the wire which caused problems when the server on a
> non-aix system tried to set them.)
> 
> I'd be happy to add the VMS bits.  I'd probably need at least
> some rough description of what needs to be added (if I remember
> correctly, doesn't VMS also have a SYSTEM field -- four fields
> of four bits each?)
>

VMS has four groups of four bits: System, Owner, Group and World
and the bits defined Read, Write, Execute and Delete permission.
VMS Execute permission is different from Unix eXecute permission;
VMS Execute permission can be considered to be a subset of Read,
because it allows a program to be loaded into memory and run. 
It also allows a command file to be run, or lookup of a specific
file in a directory.

As for implementations sending attributes other than what are
defined, there are always the private extended attributes.  There
are no rules stated as which should take precedence when there
are conflicts between the defined attributes and private extended
attributes, but I think that a safe assumption would be that an
implementation that uses private extended attributes would be
using them to communicate more file information than can be done
via the attributes that are defined by the specification and hence
private extended attributes should supercede defined attributes.
In general I would expect few actual conflicts as the defined
attributes would be derived from the actual attributes of the
file.