Issues for CORBA-FTAM/FTF Finalization Task Force mailing and discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 3820: FTAM/FTP Issue delete
Issue 3821: Accessing Server-side File Systems:
Issue 4047: beef up the discussion of how the Property Service is to be used
Issue 4048: We should clarify the roles of sender and receiver
Issue 4049: We need to discuss the protocols supported
Issue 4050: Type name & parameter name should differ by more than just case
Issue 4051: ProtocolSupport struct
Issue 4052: The NativeFileSystemType enumeration has to be changed
Issue 4053: CommandNotImplementedException
Issue 4054: 'delete' operation is C++ keyword
Issue 4055: Architecture issue
Issue 4056: Remove restrictions
Issue 4177: Transfer operation protocol negotiation unspecified
Issue 4178: FileTransferSesion:insert method signature mismatch
Issue 4179: Use of Directory in transfer/insert/append/delete operations
Issue 4180: set_directory effect unclear
Issue 4181: The Directory::list operation is underspecified
Issue 4182: FileIterator interface operations not defined in spec
Issue 4183: How does transfer operation determine FileTransferSession object identity
Issue 4184: Use of Istring in IDL
Issue 4208: ftam/ftp issue: binary vs text file transfer
Issue 4209: ftam/ftp issue: Setting up file transfers and transfer protocols
Issue 4227: Cannot transfer files if Files have same associated_session
Issue 4228: listening socket determination of source / destination File
Issue 4229: Active vs. passive connect for file transfer (Firewalls....)
Issue 4230: Exposure of Virtual File System implementation details
Issue 4272: ftam/ftp issue: lifecycle of FileTransferSession, Directory, and File
Issue 4389: 64 bit file systems
Issue 4390: Use of AccessLevel Struct
Issue 4391: Directory::list and FileWrapper
Issue 4409: Why does File derive from PropertySetDef?
Issue 4423: ftam-ftp FTF issue: FileSystemID
Issue 4424: ftam-ftp FTF issue: Missing transfer operations
Issue 4425: tam-ftp FTF issue: File::create_file does not create a file
Issue 4426: ftam-ftp FTF issue: file time attributes are strings
Issue 4427: ftam-ftp FTF issue: Exception definitions
Issue 4428: ftam-ftp FTF issue: login operation parameters

Issue 3820: FTAM/FTP Issue delete (ftamftp-ftf)

The FileTransferSession::delete (in File file) operation will have to be changed to accommodate the C++ keyword “delete”.  This should be changed to FileTransferSession::delete_file (in File trash).  This is in keeping with the style of other operations, e.g. get_file, create_file, etc.  The File parameter name should be changed in accordance with an earlier comment.

Resolution
Voted to change the operation to delete_file. After resolving other issues, the equivlent
operation in the revised idl is FileSystemEntry::remove.

 There is no operation in the IDL to allow for directly accessing a file’s contents.  However, this scenario has been considered.  In order for a CORBA application to access the contents of the files on a server-side file system, it would be necessary for that application to provide an object implementing the FileTransferSession interface.  Only the FileTransferSession::transfer (in File src, in File dest) operation and the FileTransferSession::protocols_supported attribute would have to be fully implemented.  The procedure for transferring the contents of a file would be as follows; 
 The reduced FileTransferSession would be instantiated. 
 A File object would be created, setting the associated_session attribute to point to the reduced FileTransferSession object.  The name, complete_file_name and parent attributes can be set to arbitrary values. 
 The FileTransferSession::transfer() operation would be called on the remote FileTransferSession, passing in the remote File as the src parameter, and the locally created File as the dest parameter. 
 The reduced FileTransferSession object would accept transport connections on the address’s specified by the FileTransferSession::protocols_supported attribute.  When the connections have been set up, the remote FileTransferSession will call the transfer() operation on the reduced FileTransferSession, and transfer will commence. 
 The reduced FileTransferSession object can then read the contents of the file from the transport connection. 
 Data may be written to a remote file in a similar fashion, however the reduced FileTransferSession will have to be able to set up transport connections.  The append() operation may also be implemented in the same way, if so desired. 

Resolution
Allow corba interfaces to be used along with “ftam” and “ftp” to transfer a file. This allows
pure clients to use the service and removes the requirement that two services both speak
ftam or ftp to transfer a file.
The original IDL was under specified in regard to negotiating a transfer protocol or com-pleting
the required handshaking for file transfer. The IDL has been modified to negotiate
a transfer connection in a manner similar to the A/V streams specification. A mandatory
corba interface for file transfer has been defined: CosFileTransfer::OctetTransferIterator.
With the new IDL, clients and service implementations can negotiate the transfer protocol
at runtime. Clients can be written generically without concern for the actual transfer
mechanism.
The OctetTransferIterator interface itself is:
interface OctetTransferIterator {
FileOctetSeq get_octet_seq(in FileOffset from_octet, in FileCount
max_octets)
raises (FileSystemError);
void put_octet_seq(in FileOffset to_octet, in FileOctetSeq octetSeq)raises(FileSystemError);
void destroy()
raises(FileSystemError);
};

1.	We should beef up the discussion of how the Property Service is to be used, and remove duplications. For example, Name and CompleteName are both listed as attributes and as properties to be supported.

Resolution
Defined specific property names and types available. Made properties such as name
fixed_readonly so that there are not two paths to modify a File name.

2.	We should clarify the roles of sender and receiver, and make clearer which FTS actually initiates the transfer.

Resolution
The previous IDL was under specified and required use of is_equivalent to determine
sender or receiver identity, which also made it impossible to transfer files between a sin-gle FileSystem. The IDL has been changed to follow a transfer connection setup similar to
the A/V Streams specification.
Responsibility for the transfer of a file has been moved from the FileSession interface to
the File interface itself. Files now create TransferEndPoints that are used for a single file
transfer.

3.	We need to discuss the protocols supported, e.g., how are FTAM protocols 
registered? - stringified Application Entity Titles, or what?

Resolution
Defined a protocol syntax including specific protocol names for ftam, ftp, and the required
corba interface. Syntax accommodates future protocols and options. The file transfer
negotiation setup has been changed to allow the exchange of protocol specific informa-tion
such as addressing. This resolution applies to issue 4051 as well.

4.	Type name & parameter name should differ by more than just case, thus "void delete(in File file)" needs to be changed

Resolution
Voted to change the parameter name to de_file. After resolving other issues, the equivlent
operation in the revised idl is FileSystemEntry::remove().

5.	In the ProtocolSupport struct, the transport protocol used between FTS's is specified by the protocol_name member. It would be a good idea to specify values for more commonly used transport protocols, eg "TCP/IP" for TCP connections, "UDP/IP" for UDP, etc.

Resolution
The resolution to issue 4049 applies to this issue. This issue is somewhat unclear as nei-ther
“TCP” or “UDP” are usable file transfer protocols. TCP using ftp data connection
semantics is defined in the resolution as the “ftp” protocol.

6.	The NativeFileSystemType enumeration has to be changed. It currently takes the form:enum NativeFileSystemType { FTAM, FTP, NATIVE }; The keyword "native" is now used by CORBA, and the "NATIVE" element should therefore be changed to "LOCAL". A new element, "UNKNOWN", should also be added for drivers that do not fall into the three main categories.

Resolution
This issue is closed by the resolution of Issue 4230, which removes this enumeration from
the IDL.

7.	It might be a good idea to declare that the operations delete and create_directory can throw a CommandNotImplementedException

Resolution
It was previously voted by the FTF to add this exception to these operations. The resolu-tion
of issues 4272 for LifeCycle and 4427 concerning the number of exceptions that
could be raised has made this issue obsolete.

8.	There is an operation defined in FileTransferSession interface called "delete" which is to delete the file in file system. The "delete" is a C++ keyword so it cannot be mapped from IDL to C++.

9.	Another issue is related to the architecture. We would like to provide a customer with an IDL for accessing server side file systems. The most important operation is a file transmission. In current design of FTAM/FTP Interworking there is a "transfer" operation that copies file between two Virtual File Systems. In this case customer will have to implement his VFS and a driver (or we will have to implement for him) and we afraid that from his point of view it may be not acceptable. I would like to know if an operation of FileTransferSession which just returns file contents is considered for FTAM/FTP RFP (i.e. operation that returns sequence of octets). In this case customer will not have to implement his VFS - the file contents will be retrieved by simple IDL operation

10.	Currently, it is mandatory that the source and target File Transfer Sessions are using the same protocol, e.g., both FTAM or both FTP. It would be nice if this restriction were removed. If an implementation of the Gateway supports both protocols, the gateway could use one protocol to copy the file from the source file system to local storage, and then use the other protocol to copy it from local storage to the target file system.

Rationale for Rejection
There were 4 abstain and 5 to close without action (reject). The introduction of a corba
interface for file transfer to resolve issue 3821 addresses the concern of this issue.

In Section 3.2 File Transfer Session, the transfer operation is
described requires the source FileTransferSession and Target
FileTransferSession to negotiate the transfer protocol by inspecting
each other's protocols_supported attribute.

This is problematic if either FileTransferSession supports more than
one protocol as the protocol negotiation is not specified.

For example take two FileTransferSessions that list their supported
protocols in their preferred order:

FileTransferSession (A)            FileTransferSession (B)
----------------------             -----------------------
supported_protocols:               supported_protocols:
1. "TCP/IP:xxx.xxx.xx.xx:yyy"      1. "Other:adafadfasdfd"
2. "Other:adfadfasdfadfdf"         2. "TCP/IP:xxx.xxx.xx.xx:yyy"

Even though they both support the same protocols, if these two
FileTransferSessions attempt a transfer using the Code sample in
Section 4.5.2, A will select TCP/IP, B will select "Other" and the
transfer will never happen.

Action Requested: specify transfer protocol selection method.

Resolution
Define protocol negotiation in the specification, such that one transfer endpoint defines
the protocol to be used.

The `offset' parameter of the insert method is of type long but
in the Section 3.3 File properties table on page 3-7 the file size
property is unsigned long. The operation insert should work at
any offset up to file size, so the types should be the same.

Action Requested: The `offset' parameter and the file size attribute
should be of the same type.

Resolution
In the final text, the file size property and the offset parameter in the insert method are of
type unsigned long long. (Resolution of issue 4389 brought the type from unsigned long
to unsigned long long.)

The interface Directory derives from File and can therefore be used as
an argument in FileTransferSession::transfer/insert/append/delete calls.

Directories are only mentioned in the description of delete. Is the delete
of a directory recursive or must the directory be empty first?

And what is the behavior of transfer,insert,append when one or both of
the arguments are Directories? Is this legal at all?

Action Requested: Specify behavior when a Directory is used as src or dest
argument to transfer,insert, and append. Specify recursive behavior for
those operations and delete.

Resolution
Changed the IDL such that Directory no longer derives from File and cannot be used in
any of these operations due to the ambiguity. Both File and Directory derive from a base
interface FileSystemEntry that provides common operations for things such as get_name.

The specification states that Directory::set_directory is used to allow
a client to "update or populate the contents of a Directory object." so
that it mirrors the true contents of a remote server.

However, at any point in time after the call to set_directory, the
Directory can get out of sync with the remote server it represents.

Even after a call to list() is made, either the returned sequence or
FileIterator can return stale results. 

What I'm suggesting that the sync point is an implementation
detail. It may be appropriate for some implementations to sync on
every call to Directory::list or FileIterator::next_n. 

If an implementation did nothing in response to set_directory could a
client tell? If not, must a client call set_directory before it can
call list or get_property_value("num_children")?

I ask these questions because neither the Naming or Trader services,
which have similar iterators, have any kind of set or refresh
operation to sync with their datastore.

I'm also a bit confused because in Chapter 4 Section 4.3.2, you do
not have to call set_directory on the root directory returned from
log_in(), but then you do on any subsequent directories.

The name set_directory indicates a kind of change working directory
operation as in an ftp or ftam client app but it doesn't seem to
apply in this situation.

Action Requested: If set_directory is required, spec must state when
it needs to be called in Chapter 3. If its not required, remove it and
state that it is up to the Directory implementation when it takes a
"snapshot" of the remote server.

The parameters of the Directory::list method are underspecified which
makes interoperability a problem. (We just went through this with the
NamingContext::list operation in the Naming RTF/FTF.) 

A more rigorous definition of list (borrowed from Section 3.3.8 of 
the INS spec formal/00-08-07) is:

void list (in unsigned long how_many, 
        out FileList fl, 
        out FileIterator fi);

list returns the Files contained in a Directory in the parameter fl.
The fl parameter is a sequence where each element is a FileWrapper.

The how_many parameter determines the maximum number of Files to return
in the parameter fl, with any remaining bindings to be accessed
through the returned FileIterator fi.  

- A non-zero value of how_many guarantees that fl contains at most
how_many elements. The implementation is free to return fewer than the
number of Files requested by how_many. However, for a non-zero
value of how_many, it may not return a fl sequence with zero elements
unless the Directory contains no Files.

- If how_many is set to zero, the client is requesting to use only the
FileIterator fi to access the Files and list returns a zero
length sequence in fl.

- The parameter fi returns a reference to an iterator object.

- If the fi parameter returns a non-nil reference, this indicates that
the call to list may not have returned all of the bindings in the
Directory and that the remaining Files (if any) must be retrieved
using the iterator. This applies for all values of how_many.

- If the fi parameter returns a nil reference, this indicates that the
fl parameter contains all of the Files in the Directory. This applies
for all values of how_many.

Action Requested: Make description of list operation cover these 
interoperability points.

Resolution
The Directory::list operation has been made unambiguous. The IDL has been changed
so that it now simply returns a DirEntryIterator. (The original spec also failed to describe
the iterator.). The DirEntryIterator is a “recoverable iterator” interface that allows recovery
and continuation if a client or server tries to send/receive too many entries in a single
operation.

The FileIterator interface operations are not described in the spec.

Action Requested: Insert text similar to Naming Service BindingIterator
description.

From the description in Chapter 3, it is not clear how the
FileTransferSession::transfer method is actually accomplished.

Chapter 4 Section 4.5.1 describes the FileTransferSession examining
the File reference's attributes to determine whether it is to initiate
the transfer or receive the file. The initiator
FileTransferSession::transfer implementation must then call transfer
again on the target FileTransferSession.

How, in a portable fashion, is a FileTransferSession to determine if
it is the same FileTransferSession referred to in the src or dest File
associated_session attribute?

1. _is_equivalent cannot be used to compare FileTransferSession or other object
   references as a false return is inconclusive.
2. There are no object identity operations defined on the
   FileTransferSession interface.  
3. None of the other File attributes denote unique identity (name,complete_name,
   as the src and destination file names can be identical.)

Requested Action: Clarify how the File's attributes allow a FileTransferSession
implementation to determine File ownership.

Resolution
The transfer operation was overloaded and required use of is_equivalent. The IDL has
been changed to make the roles of sender and receiver unambiguous. In particular, to
transfer a file now, a SOURCE TransferEndPoint and a SINK TransferEndPoint are cre-ated.
The TransferEndPoint interface has been added to the IDL.

The CosFileTransfer module typedef's string to Istring. This was used
in the NamingService as a placeholder for an internationalized string
type. We would have removed it in the INS FTF if we could have. ;-).

Since CosFileTransfer is new the opportunity should be taken to remove
IDL constructs that are no longer useful.

ftam/ftp issue: binary vs text file transfer
--------------------------------------------

Both FTP and FTAM make distinctions between text and binary files and
use <CR><LF> newline encoding for text file transfer. FTAM has
provision for identifying text or binary files by the FTAM type
(FTAM1,FTAM2...)  whereas FTP requires the client and server to
somehow ascertain the file type before transfering as either text or
binary.

It also appears that depending on the real filestore implementation,
an FTAM responder may not always be able to authoritatively determine
a file's type unless it has been explicitly set by a user.


Having said that, does the ftam/ftp idl need to allow for text/binary
transfer in the transfer, append, and insert operations? Or for the
purposes of this specification are all transfers to be considered
binary?

Requested Action: Some words in the specification about text vs.
binary files.

ftam/ftp issue: Setting up file transfers and transfer protocols
----------------------------------------------------------------

In addition to the previous issues 4177, 4183 I've raised about file
transfer and protocols I would like to recommend that a somewhat more
complete approach be taken to managing the transfer operations
(transfer, append, and insert).

The current approach doesn't allow the virtual file systems to perform
any kind of real protocol negotiation, resource/socket init, set-up
acknowledge, or resource release. 

For instance, when speaking "TCP" as illustrated in Chapter 4, the
port numbers are fixed by the supported_protocols attributes. A file
system cannot change the port it would like to use on a per transfer
request basis. This can be restrictive to allowing multiple transfers
to happen in parallel or determining what file's data just came in on
a socket.

I am suggesting that an approach similar to the one used in the
Audio/Video Stream specification be used. In this case an endpoint
object would be established to represent each end of the file
transfer. There is the opportunity for simple negotiation, such as
picking protocols and port numbers.

The IDL in the A/V Stream spec is far too heavy-weight for ftam/ftp
but the concepts used for connection set-up and management are
relevant. Just using a few of the A/V flow/end-point operations like
set_peer, go_to_listen, and connect_to_peer would be sufficient.

At OOC, we have begun experimenting with IDL that supports the notion
of transfer `endpoints.' A different type of endpoint is created for
each type of protocol, so matched protocol (such as TCP) endpoints
talk to each other. And a CORBA endpoint is defined so two file
systems can always transfer if they share no other common protocols.

Resolution
Changed the IDL to adopt an approach similar to the A/V streams spec where one end-point
starts a “listen”, the other end point “connects”. The interface TransferEndPoint was
added. The File interface has a new operation: create_end_point.

This issue concerns the operation:
      FileTransferSession::transfer(in File src, in File dest)

and the associated operations append and insert.

As described in section 4.5.2, in the transfer implementation, the
FileTransferSession must first determine whether it is associated with
the src or dest File in order to set up an active or passive
connection.

If it is the source, it sets up an active connection and then calls
`transfer' again on the destination File's associated_session.
Unfortunately, when both the src and dest files have the same_session,
a FileTransferSession will always consider itself the source and
unwanted recursion will result.

The spec could say its forbidden to transfer files associated with the
same FileTransferSession but this is extreme. 

It is also problematic to guarantee an implementation can detect this
situation, as the FileTransferSession interface has no identity
operations and a false return from is_equivalent is inconclusive. (The
is_equivalent problem is also raised in Issue 4183).

As with issue 4183, this issue could be resolved by not using the same
transfer method to both initiate sending and receiving of data.

In general (exception noted below) it is not possible for a receiving
FileTransferSession to know what is the destination File for the data
coming in over a socket. The receiver is never made aware of the
sender's connection host and port, so it cannot distinguish multiple
connections to the listening socket.

The exception is that the transfer mechanism described in Chapter 4
will work reliably as long as the following limitations apply: 

1. A FileTransferSession is involved in only one file transfer at a
time so there is no ambiguity as to the data source and destination.

AND

2. A server process implementation makes each FileTransferSession
listen on a different port or allow only one FileTransferSession to
take part in a transfer at a time. This guarantees there is no
ambiguity as to which FileTransferSession is involved in a file
transfer.

These are rather severe restrictions. Simultaneous transfers and reuse
of server sockets can be accomplished if the transfer negotiation is
augmented to exchange details such as host and port (somewhat like the
ftp PORT command does to establish a data connection.) Such an approach
is outlined in issue 4209.

n Section 4.5.2, the specification provides a sample skeleton of the
transfer operation where the protocol information available for the
destination FileTransferSession is "TCP/IP" with a listening address
of "255.255.25.1:8001"

The specification is requiring that the receiver of a file must allow
incoming connections.

Forcing the sender to always connect() and the receiver to always
listen() will cause unnecessary trouble with firewalls.

Since any file transfer could also be accomplished by allowing the
sender to listen and the receiver to make the active connection the
protocol specification should allow for active, passive (or either)
connections.

(A similar issue was raised against the A/V streams spec: issue #2053)

Resolution
Protocol syntax changed to allow for the specification of protocol options. The protocol
syntax definition accommodates the specification of “active” or “passive”.

The FTAM RFP suggested implementations take a CORBA-centric approach
and hide FTAM and FTP specific details.

The VirtualFileSystem interface has an attribute file_system_type that
can be: FTAM, FTP, or _NATIVE. There is also a supported_content_types
attribute that returns a list of FTAM file type identifiers.

This seems to be exposing implementation detail a client cannot
directly use. If a client cannot make use of these they should be
removed from the IDL.

Resolution
Voted to remove the following file transfer protocol specific elements from the IDL:
typedef long ContentType;
const ContentType FTAM_1 = 1;
const ContentType FTAM_2 = 2;
const ContentType FTAM_3 = 3;
const ContentType FTAM_4 = 4;
const ContentType FTAM_5 = 5;
const ContentType NBS_9 = 6;
const ContentType INTAP_1 = 7;
enum NativeFileSystemType {
FTAM,
FTP,
_NATIVE
};
typedef sequence<ContentType> ContentList;
readonly attribute ContentList supported_content_types;

Once a FileTransferSession object is created on behalf of a client a
large number of Directory and File objects can be created by calls to
list and get_file. The specification does not address reclaiming
server side resources when these objects are no longer required by the
client.

Once FileTransferSession::logout is called it can be inferred that all
of the associated Directory and File objects should no longer be valid
and can be reaped. The specification should state that they must no
longer be valid, as you should not have access to a file or directory
after you have logged out.

If after using a number of file and directories a client has no
further use for them, there should be a way for the client to inform
the server. This requires a destroy() method on the File interface.

Also, a robust virtual file system implementation must be allowed to
reap FileTransferSession, Directory, and File objects at any time in
order to reclaim resources from ill-behaved clients that acquire but
do not release objects. The spec should mention that all clients, but
particularly those that don't actively use File and Directory
references for long periods, can expect OBJECT_NOT_EXIST exceptions.

Resolution
destroy methods added to the FileSystemEntry interface, base interface for Directory and
File interfaces. destroy methods provided on other interfaces introduced by the FTF.

Given the appearance of 64 bit file systems, consider changing the
types used to represent file length and insertion offsets to unsigned
long long so this specification can be used on large files.

Resolution
IDL: change the typedefs of all types representing file offsets, length, or counts to
unsigned long long. Directory iterator count and offsets are also unsigned long long.

The access_rights property is defined as an AccessLevel struct. A
client is able to query this property from a File or
Directory. AccessLevel is defined as:

     struct AccessLevel {
            boolean read;
            boolean insert;
            boolean replace;
            boolean extend;
            boolean erase;
            boolean read_attr;
            boolean change_attr;
            boolean delete;
     };

and represents the permissions granted to a user.  In practice it is
not always possible for a service implementation to know the values of
all of these attributes. Unfortunately there is no way for a service
to report if any of these values cannot be determined.

The ftam spec should provide some means to determine the validity of
the boolean values in this struct, or at the very least specify the
default values for unknown members.

The Directory::list & FileIterator operations return sequences of 
FileWrappers defined as:

             struct FileWrapper {
                    File the_file;
                    FileType file_type;
             };


This has the unforunate side effect of creating large numbers of
unnecessary File object references.

For example, to query a directory with 10,000 Files. The server must
return 10,000 separate usable file references. If I then want the
names of the files, that's 10,000 more calls to File::get_name().

Even if the server implementation is clever and is only generating
references for these files and not directly backing them with
servants, the server must maintain some context about them.

Considering a client will probably only transfer a minority of the
references it receives from list it would be advantageous to structure
the list operation to return the relative names of the entries to the
enclosing directory:

   struct DirEntry {
   wstring relative_name;
   FileType file_type;
   };

Then, the client has immediate access to what is arguably the most
frequently accessed File attribute (the name), and the File object can
then be gotten by adding a get_file operation on the Directory itself.

Further to making the list call more useful and not having to make
mutiple calls on each File object to query attributes, the list
signature could be:

          Directory::list(in CosPropertyService::PropertyNames listProps)

          struct DirEntry { 
             RelativeName name;
             CosPropertyService::Properties props;
             DirEntryType type;
          };

Now it is easy for a client, to obtain a directory listing with file
names, size, owner, etc... without forcing the server to create *any*
File references and eliminating any client calls to these references.

Only if the client wants to transfer or delete a file will it have to
ask for a reference.

Resolution
IDL changes similar to those described in the summary. The Directory::list operation
returns an iterator for DirEntry structs which contain the simple name and requested
properties of FileSystemEntries. The Directory interface has a get_file operation that
takes a multi-component path name argument relative to that Directory. This is similar to
a CosNaming::Name.

The spec states the File interface derives from
CosProperty::PropertySetDef and lists the properties that can be
associated with a file: is_directory, creator, size, mod_time,
create_time, access_rights, name, complete_file_name and num_children.

Under what circumstances could a client validly change the property
mode of one of these? A client could certainly change the values of
some of these but not the modes of the properties themselves.

Unless an example can be provided that shows a need to modify the
property mode, File should derive from PropertySet not PropertySetDef.

It would be very useful for generic clients if the FileSystem would
identify itself somehow with a get_system_id() that returned an id
string. This would be similar to the string that is returned to
identify an FTP server.

There is no need for this string to be globally unique.

Resolution
Added the operation:
wstring FileSystem::get_system_id()

With FTP and FTAM it is possible to monitor the progress of data transfers
and to abort them. The current spec provides no way to terminate or determine
the progress of a transfer. Consider adding some way to obtain the status /
progress of a file transfer and to abort an in progress transfer.

Resolution
The TransferEndPoint interface has an abort() and get_transfer_status() methods. The
abort() terminates the current transfer and get_transfer_status() returns a struct with
information about the current and maximum transfer octet counts. An implementation
may raise an exception indicating these operations are unsupported.

The operation create_file doesn't create a file, unlike
create_directory which does create a directory. create_file creates a
target proxy for a file transfer.

Consider removing create_file and adding a boolean flag to the very
similar get_file operation to indicate whether underlying file
existence is required.

Resolution
Directory::get_file operation now has the signature:
File get_file(in EntryPath fpath, in boolean must_exist)

The File attributes for creation_time and mod_time are defined as strings.
Without better specification, this is not useful. The types of these 
attributes should be TimeBase::UtcT.

The spec defines six exceptions that carry no information other than a
text string to describe the error. This leads to cumbersome coding on
the client side.

Consider a single exception with a reason code. This conveys the same
information without requiring 5 or 6 catch blocks in some languages.

Resolution
Exception types changed to FileSystemError with an ErrorCode and TransferError which
is like a FileSystemError but can identify whether the problem is at the source or sink end
of the connection. The ErrorCodes are defined as const values to allow for future addi-tions.

The login operation allows for specification of a user, password, and
account. The spec notes that account is optional. There are any number
of other login properties that affect client access to a file system
but no way to specify them.

Consider adding a property sequence to the login argument so that
optional properties can be specified. The `optional' account argument
can then be removed.

chang signature from:

	FileSession login(in string user,
                          in string password,
                          in string account,
                          out Directory dir);

to:
                          
        FileSession login(in string user,
                          in string password, 
                          in CosPropertyService::Properties props,
                          out Directory dir);

.