Hello Osamu,

Now, all input to the service becomes a full path.

Actually it always has been, however it has been presented in such a way that describes the use of an absolute path in all cases; this was done in an attempt to reduce complexity, potential confusion in a federated namespace, and present a consistent globally unique identifier for all namespace objects. (In Section

1.3.3.1 "move", there still "the absolute path" remains in the second table.)

Right, I was originally thinking of allowing "moves" to occur between RNS providers, however this is simply not facilitated by the specification; a provider-to-provider interface would have to be described and that is out of scope for this revision. It is now changed, thanks!

This means the absolute path is only handled by a client library not by a service itself. A service does not care about the absolute path. Root directory is only known by a client. I do not think there is any problem about this.

If "handled" means that the client is the only party that maintains a comprehensive view of the overall federated namespace. The first sentence in section 2.2.1.1 clearly states that "all service operations [MUST] accommodate the use of absolute pathnames." This section goes on to describe how the referral message mechanism is employed to allow dynamic redirection to the appropriate RNS service providers if the path provided is not served by the current provider.

(In Section 1.4.6 "RNSJunctionFault", and in the first paragraph of Section 2.2.1.1 "Referral Messages", "absolute" path should be "full" path?)

Please see the comments above, these two cases are correct and still valid.

Can we have a teleconference on Friday afternoon (3pm or 4pm) in California time?

This is a good idea and the time should work for me. Best regards, Manuel Pereira ------------------------------------------------------ IBM Almaden Research Center 1-408-927-1935 [Tieline: 457] mpereira@us.ibm.com ------------------------------------------------------