NAM — Problems with step-wise resolution

The specification of the NamingContext interface distinguishes between
object and context bindings. It requires that when a multi-component
name is resolved, each name other than the last must designate a context
binding - an object binding to an object that happens to conform to the
NamingContext interface shall not be sufficient.

This restriction is easy for a name server to support, because it has
direct access to the binding information. (In fact, multi-component
resolution is easier for the server with this restriction because it
need not narrow an object reference to determine if it is a
NamingContext - a potentially expensive operation.)

However this restriction places an unacceptable burden on "an
application that chooses to do piecewise resolution". As things stand,
an application that wishes to do piecewise resolution in a conforming
way must first list each context in order to determine the binding type
of the component at the next level. (There are many reasons to do
step-wise resolution. For instance, some piece of code may have a
"working context" in which it stores bindings. A client of it may be
responsible for selecting the working context and providing it as an
object reference. Also, when federated naming contexts are used,
stepwise resolution can be a significant performance win.) The cost of
doing the list can be arbitrarily high, depending on the number of
bindings in the context.

Decided not to add extra operations to support this particular client case.