A group entry consists essentially of multiple independent other entries whose names are also associated under the group name. These other entries can be simple (single-name) entries, or they may themselves be group entries. Doing an import from the group entry will return the contents (the binding handles) of its included entries (which are called members), but the selection is made by the DCE RPC runtime, and from the client's point of view is undefined and implementation dependent.
In practice, the way this works with the usual binding import operations is as follows. Clients normally import bindings by first calling rpc_ns_binding_import_begin( ) to set up an import context. Once this is done, successive calls to rpc_ns_binding_import_next( ) will return binding handles from namespace entries until the handles have all been returned or the client decides to stop; the client decides which handle(s) to use based on its own criteria. When it is finished importing, it calls rpc_ns_binding_import_done( ) to free the context.
The kind of entry the information is returned from is usually unknown to the client, which needs to know only a name to look up and the interface UUID by which it wants to bind. If the name is that of a simple server entry, then the bindings contained in that entry only will be returned. If the name is of a group entry, then bindings will be returned from members (single entries) of the group, selected (by the RPC runtime) in an undefined order. If one or more members of the group are themselves groups, then the same thing happens recursively whenever these lower-level groups are accessed.
Note that the group entry and its members are separate things. The group entry can be deleted, but its former members will continue to exist as independent entries, unless they too are explicitly deleted. Thus, you can implement a namespace organization where the same bindings can be imported through individual simple entries or through group entries, depending on how the client is coded.