The binding routines that acl_edit uses are discriminating enough to detect a junction anywhere in an entry name that is passed to it. This allows a distributed application to have its own namespace for objects with ACLs on them, rather than burdening the DCE namespace by separately exporting binding information for every one of these objects. The separate objects have to be made publicly accessible somehow because entities should be able to access ACLs directly, regardless of whether they happen to already be in contact with the server that manages the ACL'ed object, and indeed regardless of whether or not they happen to be a client of the particular server to which the objects belong.
Suppose, for example, a user enters the following in order to interactively edit the ACL for the printer object cotta, where the namespace entry for a print server is /.../tinseltown.org/dce/dce_print, and there is no /.../tinseltown.org/dce/dce_print/cotta entry in the DCE namespace:
acl_edit /.../tinseltown.org/dce/dce_print/cotta
The binding routine, sec_acl_bind( ), which is called internally by acl_edit, receives an error when it tries to bind to the object cotta. However, the DCE Directory Service also tells it how much of the name it passed is valid. The sec_acl_bind( ) routine then retries the binding operation, this time through the valid entry name /.../tinseltown.org/dce/dce_print and passes the residual part of the name (cotta) as a parameter. Now it is up to the application ACL manager to interpret the residual name correctly and find the requested ACL.