Enterprise Root Subordinate Contexts

The following objects can be named relative to the enterprise root:

• Organizational units in that enterprise

• Sites in the top organizational unit of the enterprise (an extension to XFN policies)

• Users in the top organizational unit of the enterprise

• Hosts in the top organizational unit of the enterprise

• Services for the top organizational unit of the enterprise

• File service for the top organizational unit of the enterprise

  These objects are named by composing the namespace identifier of the target object's namespace with the name of the target object.

Enterprise Root and Organizational Subunits

Organizational subunits can be named relative to the enterprise root.

Given an organization root name, you can compose names for its subordinate organizational unit contexts by using one of the namespace identifiers, orgunit or _orgunit.

For example, if .../doc.com is the name of an enterprise, the root of the context for naming organizational units is .../doc.com/orgunit/, and organizational unit names look like .../doc.com/orgunit/sales and .../doc.com/orgunit/west.sales. Or, you could achieve the same result with org//orgunit/sales.

The following objects can be named relative to an organizational unit name:

• Sites for that organizational unit (an extension to the XFN policies)

• Hosts in that organizational unit

• Users in that organizational unit

• Services for that organization unit

• File service for that organizational unit

  For example, the name ...doc.com/orgunit/sales/service/calendar, identifies the calendar service of the sales organizational unit. (See "Organizational Unit Namespace" and "Composing Names Relative to Organizations" for a more detailed description of naming objects relative to organization units.)

Enterprise Root and Sites

Sites are an extension to the XFN policies.

Sites can be named relative to

• The enterprise root

• An organizational unit

  Sites named relative to the enterprise root are the same as sites named relative to the top organizational unit. Given an organization name, you can compose a name for its site context by using one of the namespace identifiers, site or _site. For example, if the enterprise root is ../doc.com the context for naming sites relative to the enterprise root is ../doc.com/site. Sites would have names like ../doc.com/site/alameda.

  The following objects can be named relative to a site name:

• Services at the site, such as the site schedule or calendar, printers, and faxes

• The file service available at the site

  These objects are named by composing the site name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name site/Clark.bldg-5/service/calendar names the calendar service of the conference room Clark.bldg-5 and is obtained by composing the site name site/Clark.bldg-5 with the service name service/calendar. (See "Composing Names Relative to Sites" for a more detailed description of naming objects relative to sites.)

Enterprise Root and Users

Users can be named relative to

• An organizational unit

• The enterprise root

  Users named relative to the enterprise root are the same as users named relative to the top organizational unit. Given an organization name, you can compose a name for its username context by using one of the namespace identifiers, user or _user. Thus, if orgunit/east.sales names an organization, then orgunit/east.sales/user/hirokani names a user hirokani in the east.sales organizational unit.

  The following objects can be named relative to a user name:

• Services associated with the user

• The user's files

  These objects are named by composing the user's name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name user/sophia/service/calendar names the calendar for the user sophia. (See "User Namespace" and "Enterprise Root and Users" for more information on the user namespace and naming objects relative to users.)

Enterprise Root and Hosts

Hosts can be named relative to

• An organizational unit

• The enterprise root

  Hosts named relative to the enterprise root are the same as hosts named relative to the top organizational unit. Given an organization name, you can compose a name for its hostname context by appending one of the namespace identifiers, host or _host. Thus if orgunit/west.sales names an organization, the name org/west.sales/host/altair names a machine altair in the west.sales organizational unit.

  The following objects can be named relative to a host name:

• Services associated with the host

• Files exported by the host

  These objects are named by composing the host name with the namespace identifier of the target object's namespace and the name of the target object. For example, the name host/sirius/fs/release names the file directory release being exported by the machine sirius. (See "Host Namespace" and "Composing Names Relative to Hosts" for more information on the host namespace and naming objects relative to hosts.)

Enterprise Root and Services

A service can be named relative to

• An organizational unit

• The enterprise root

• A user

• A host

• A site

  Services named relative to the enterprise root are the same as services named relative to the top organizational unit.

  A service context is named by using the namespace identifiers service or _service, relative to the organization, site, user, or host with which it is associated. For example, if orgunit/corp.finance names an organizational unit, then orgunit/corp.finance/service/calendar names the calendar service of the organizational unit corp.finance. (See "Service Namespace" and "Composing Names Relative to Services and Files" for more information on the user namespace and naming objects relative to users.)

  FNS does not restrict the types of bindings in the service namespace. Applications can create contexts of a type other than service contexts and bind them in the service namespace.

  FNS supports the creation of generic contexts in the service context. A generic context is similar to a service context except that a generic context has an application-determined reference type. All other properties of a generic context are the same as a service context.

  For example, a company named World Intrinsic Designs Corp (WIDC), reserves the name extcomm in the service namespace to refer to a generic context for adding bindings related to its external communications line of products. The context bound to extcomm is a generic context, with reference type WIDC_comm. The only difference between this context and a service context is that this context has a different reference type.

  Service names should be registered with Sun Microsystems, Inc., as directed in "Service Name and Reference Registration".

Enterprise Root and Files

A file namespace can be named relative to

• The enterprise root

• An organizational unit

• A user

• A host

• A site

  Files named relative to the enterprise root are the same as files named relative to the top organizational unit. A file context is named by using the namespace identifiers fs or _fs, relative to the organization, site, user, or host with which it is associated. For example, if orgunit/accountspayable.finance names an organizational unit, then the name user/jsmith/fs/report96.doc names her file report96.doc. The file service of the user defaults to her home directory, as specified in the NIS+ passwd table. (See "File Namespace" for more information on the user namespace.)

  There can be no other type of context subordinate to a file system.

Enterprise Root and Printers

The printer context is an extension of XFN policies.

A printer namespace can be named in the service context. A printer context is named by using the namespace identifier, printer, in the service context relative to

• An organizational unit

• A user

• A host

• A site

  For example, if org/east.sales names an organizational unit, then org/eastsales/service/printer names the printer service of the organizational unit east.sales. Thus, an individual printer named lp1 would be identified as: org/east.sales/service/printer/lp1.

  There can be no other type of context subordinate to a printer.