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)

see above

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

;

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.

Remove the struct from the IDL.

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.

see above

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.

Removed the operation from the IDL. There is no concept of a “current directory”.

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.

rejected

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.

see above

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.

see above

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);

Change IDL for login as suggested.

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.

see above

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 property types have been changed to TimeBase::UtcT.

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.

see above

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.

see above

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.

see above

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.

Change FileSystemEntry Interface to derive from PropertySet.

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

struct FileWrapper

;

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

;

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

;

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.

see above

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.

see above

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.

see above

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.

see above

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.

The resolution for issues 4177, 4209, and 4227 applies to this issue.

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.

The resolution for issues 4177, and 4209 resolves this issue.

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.

see above

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.

Treat all file transfers as binary.

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.

All string references in the IDL have been changed to wstring.

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.

see above

The FileIterator interface operations are not described in the spec.

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

The DirEnryIterator is now defined in the specification.

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.

see above

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.

see above

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.

see above

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

duplicate of issue 3821 – close issue

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++.

duplicate of issue 3820 - close issue

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

see above

6. The NativeFileSystemType enumeration has to be changed. It currently takes the form:enum NativeFileSystemType

; 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.

see above

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.

see above

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

see above

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.

see above

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

see above

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

see above

13.6.7 of the CORBA 2.3 specification states: "The context data for a particular service will be encoded as specified for its service-specific OMG IDL definition, and that encoded representation will be encapsulated in the context_data member of IOP::ServiceContext. (See Section 15.3.3, Encapsulation, on page 15-13)."

The descriptions of service contexts in the FT spec are missing an explicit statement of the encoding of the service context data.

Proposed Resolution:

Add the following sentence in all appropriate sections: "When encoded in a request or reply message header, the <code>context_data</code> component of the <code>ServiceContext</code> struct will contain a CDR encapsulation of the xxxxxx struct."

see below

Motivation: The Notifier will be easier to replicate if it is a single
object. At present, all Filters created by the Notifier must also be
replicated. Furthermore, there is no requirement that a Filter be destroyed
by the client that created it (once it is done using it), raising a garbage
collection issue. FOr a connected consumer, if the consumer no longer
exists the Notifier can discard the connection. There is no analagous test
for Filters.

The Notifier interface is already a collapsed version of multiple
CosNotification APIs to get rid of the channel/admin/proxy objects in favor
of one object, so I am just proposing we carry through on that approach.

Óne proposal:

First, remove method create_subscription_filter.

Second, change the 2 connect_foo_fault_consumer methods
(connect_structured_fault_consumer + connect_sequence_fault_consumer) to
take just a consumer and a grammar:
ConsumerId connect_foo_fault_consumer (in CosNotifyComm::FooPushConsumer,
in string constraint_grammar)
raises (ÏnvalidGrammar, AlreadyConnected)

One or more event forwarding constraints is associated with each connected
consumer, with the default being a constraint that matches all events. The
ConsumerID returned from a call can be passed into methods that modify
these constraints. When a consumer is disconnected, the associated
constraints are discarded.

Third add methods for manipulating constraints associated with a ConsumeID:

string constraint_grammar(in ConsumerID)
void add_constraints(in ConsumerID, ...)
void remove_constraints(in ConsumerID, ...)
void remove_all_constraints(in ConsumerID)
void modify_constraints(in ConsumerID, ...)
ConstraintExpSeq get_constraints(in ConsumerID)

where ... means the normal arguments that are in the corresponding methods
in the Filter spec.

The above methods correspond to the Filter methdos that are required in the
current version of the spec, except I left out 2 of them, match_structured
and destroy. I do not think we need to support match_structured – only the
Notifier needs to be able to do matching. destroy is not needed because
there is no filter object to be destroyed. (disconnect is sufficient.)

ALTERNATE PROPOSAL

A simpler scheme is to associate a single constraint with each consumer.
This is not very restrictive, especially when you consider that there is
currently only one event type in use in the FT spec. The default would
still be a constraint that matched all events. In this case the only method
needed to modify this constraint is:

void replace_constraint(in ConsumerID,
in EventTypeSeq event_types,
in string constraint_expression)

Further, if we are willing to stick to the default constraint grammar, no
grammar needs to be specified, which simplifies connect_foo_consumer – not
only by removing the constraint_grammar argument but also by removing the
InvalidGrammar exception, which comes from CosNotifyFilter. I believe one
could simplify things enough to get rid of any dependencies on
CosNotifyFilter. It is not clear how important this is, but I thought I
should mention the possibility.

see below

The Fault Tolerant CORBA specification contains the following struct.

struct FactoryInfo

;

This causes a problem for the IDL compilers of some vendors, because
"factory" is a keyword in CORBA V2.3. See CORBA V2.3, page 3-8, Lexical
Conventions, June 1999.

We need to change "factory" in this struct to "fact", "fctry",
"generic_factory", or whatever. What is your preference?

see below

The Fault Tolerant CORBA specification defines the State used by the
get_state(), set_state(), get_update(), set_update() methods, as

typedef sequence<octet> State

Those methods must be implemented by the application programmers.
They will find their task easier if we define the State as:

typedef any State

rejected

Basically, the Failure OBJ_ADAPTER is considered a failover condition in the
document that was sent out. In most cases OBJ_ADAPTER exception may be thrown
when there is an internal ORB error. In case of an internal ORB error, the
retry on the TAG_ALTERNATE_IIOP_ADDRESS may still yield the same exception. This
may be inefficient. Do you see situations where doing a failover on this
particular exception is useful.

Remove OBJ_ADAPTER from this list.

On page 27-9 of the FT CORBA spec, under "Application-Controlled Membership",

"The application-controlled (MEMB_INF_CTRL) Membership Style"

should be corrected to read

"The application-controlled (MEMB_APP_CTRL) Membership Style"

Correct the above statement with the revised text given below.

Throughout the document, the authors use the term "method" several times where they should be talking about "operations" instead. This violates the general understanding of the OMG terminology, where IDL interfaces contain "operations", not "methods". The term "method" is usually reserved as a concept of oo programming languages.

I recommend that for the next revision, the authors run a global search&replace and identify where they want to talk about methods and where of operations.

No Data Available

Earlier this year, the interop FTF deprecated the LOCATE_FORWARD_PERM
exception because of several reasons :

• it was badly specified
• it made the implementation of hash() difficult, and broke most of the
  existing ones.

It turns out that the Fault Tolerance specification published a little
earlier crucially requires a similar mechanism.
In normal life, most applications can rely on plain LOCATE_FORWARD because
there is no reason to expect the death of the originally pointed component.
In the case of Fault Tolerant CORBA, this is entirely different: it is
precisely when we issue a LOCATE_FORWARD_PERM that we know for sure that
the original component is dead, and might never return. If all the backup
profiles of an IOR enjoy the same death, all hope is gone.

This means that without a mechanism similar to LOCATE_FORWARD_PERM, the
Fault Tolerant CORBA spec cannot address the requirements of real
fault-tolerant systems.

This is why the Fault-Tolerant CORBA FTF would like to see LOCATE_FORWARD_PERM
re-introduced in some way. Here are a few ideas that might help :

Issue of scope:
The scope of LOCATE_FORWARD_PERM is ORB lifetime.

Issue of hash() :
Let us be reminded that the Fault-Tolerant CORBA spec defines teh concept of
an Interoperable Object Group Reference (IOGR). The IOGR contains a specific
profile that contains a group identifier.

• When an ORB receives and IOGR, it should compute the value of hash() based
  on the GroupID contained in the IOGR, and performs LOCATE_FORWARD_PERMs if
  requested.
• When an ORB receives a normal IOR (i.e. an IOR lacking a group profile) it
  computes hash() in the customary way, and doesn't have to respond to
  LOCATE_FORWARD_PERMs.

see below

One additional issue I have is that the
ReplicationStyleValue, MembershipStyleValue, ConsistencyStyleValue,
FaultMonitoringStyleValue, FaultMonitoringGranularityValue
are typedefed to long, whereas the
InitialNumberReplicasValue and MinimumNumberReplicasValue
are typedefed to unsigned short. It might be more appropriate
to typedef all of these to unsigned short.

see below