StreetTalk lets you store all items on the network as three-part names (e.g., Item@Group@Org). The three-part names consist of items, groups, and organizations. Items are unique to the group they belong in, and groups are unique to the organization they belong in. You cannot nest StreetTalk groups and organizations.
Let's look at an example of a three-part hierarchical name. You can define a user as Steve@MCS@Microsoft. You can define additional attributes for each StreetTalk item to extend the StreetTalk directory from the three-part naming format. For example, you can instill hierarchy further within the three-part naming structure by breaking up the name: Steve@MCS Federal@Microsoft HQ. Objects can also take on three-part naming structures. For instance, you can create a printer account, such as Printer@Accouting@Acme.
Within StreetTalk, you can grant administrators rights to groups and organizational objects. Administrators of organizations can administer everything within their organization, or you can limit them to administering certain groups within the organization. Administrators of groups are limited to administering only their groups.
On a VINES network, StreetTalk is stored on every server on the network. The sequenced routing update protocol, which propagates network topology information, lets StreetTalk determine the location of each group defined on the network. Replication of StreetTalk data is not user configurable and is based on sophisticated protocol timers and sequence numbers. This type of implementation means that two StreetTalk servers on the same LAN or WAN will always see each other and share informationunless router- or bridge-level filtering has blocked advertisements.
Like StreetTalk, Windows NT 5.0's new Active Directory (AD) will allow physical partitioning and replication. You can logically nest entries in a hierarchical organization. AD supports multiple disjoint namespaces, and you can easily extend the directory schema within a single directory. AD supports diverse name formats, so RFC822-style names such as stevebo@microsoft.com and RFC1779-style names such as CN=SteveBoyce,O=Microsoft,C=US are valid.
Because administration within AD is very granular, you can delegate administration to the point of granting administrators the sole right of changing user passwords. You can extend this level of delegation to provide administration based on groups, organizations, or other directory objects. AD supports nested groups and nested organizational units.
With AD, you can schedule replication. AD supports the concept of sites, which you can use to define good areas of connectivity and determine boundaries for replication. As in NT 4.0, under NT 5.0's AD, the concept of member servers still exists, so AD does not have to be on every server in the network. Also, AD retains domain integrity for security, and the implementation of Kerberos trusts provides for the control of security trust relationships. In addition, AD can exchange directory information with any application or directory equipped with LDAP or other key X.500 protocols.
