included in draft-08

Checked into cvs.

I'm not following Dave's counter proposal. I'm
re-assigning to Dave (for now at least) to
get clarifications.

It seems to me that the complexity of this is wildly out of proportion to
the requirement, especially when you start talking about adding knowledge
of specific attributes and the client "searching" for matching attributes.

How about the following approach.  When a path component returned by
fs_location_info is of a certain form (e.g. begins with three dollar signs)
then the rest of it is the to be interpreted as the name of a client-specific
string which is expected to be different for different clients (e.g. CPU).
We give some suggestion but the list is up to clients and servers.  If the
client has no value for the attribute, he substitutes "unknown".  I'd prefer
not to allow $$$CPU$$$OS or xyz$$$CPU but I could tolerate that.

So the /usr/bin would be a referral to /usr/bin/$$$CPU which would then be
looked up by the client and turned into another referral.  The server would
know nothing about CPU or any other such attributes.  Does that meet the
requirement?

The NFSv4 global namespace entry for /nfsv4/eisler.org/docs/notes might note
that it needs to look for a version of this file system that has the CPU attribute
set to CPU attribute defined on the client.

This is a requirement that came directly from a customer. So on the
theory that customers matter, I'm setting the priority to required.

The problem is that a customer might have defined a set of replicas that
such that each replica is the same logically, but subsets are attributes that
are useful only to certain classes of clients. An example to make this crystal
clear is that a filesystem replica might contain a copy of /usr/bin with
compiled exetuables. There are Linux clients that access these replicas but
some are on an i86-32 bit platform and others are on a sparc-64 bit platform.
Both classes of clients want to see /usr/bin/ls, /usr/bin/cat, but of course
the binary bits are different for each class. So if the client can search for
replicas by say a string attribute called CPU, it can match the replicas
for x86 chip set with the clients running that chip set, and the replicas for
the sparc chip set with the clients running the sparc set.

An analogy is the NFS automounter's builtin variables, such as $CPU.
NFS automounters also allow arbitrary variables to be defined. In either
case, an automounter map entry might have:

   notes- rw srcsev:/source/notes.$CPU