Both attributes are defined in ASN.1 as follows:

        objectReferenceString ATTRIBUTE ::= {
            WITH SYNTAX             OCTET STRING
            EQUALITY MATCHING RULE  octetStringMatch
            SINGLE VALUE            TRUE
            ID                      { id-at-objectReferenceString }
        }
        id-at-objectReferenceString OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) ansi(840) sun(113536)
            ds-at-objectReferenceString(30)
        }
        nNSReferenceString ATTRIBUTE ::= {
            WITH SYNTAX             OCTET STRING
            EQUALITY MATCHING RULE  octetStringMatch
            SINGLE VALUE            TRUE
            ID                      { id-at-nNSReferenceString }
        }
        id-at-nNSReferenceString OBJECT IDENTIFIER ::= {
            iso(1) member-body(2) ansi(840) sun(113536)
            ds-at-nNSReferenceString(31)
        }

Both objectReferenceString and nNSReferenceString store XFN references in a string form. Their octet string syntax is further constrained to conform to the following BNF definition:

     <ref>          ::= <id> '$' <ref-addr-set>
     <ref-addr-set> ::= <ref-addr> | <ref-addr> '$' <ref-addr-set>
     <ref-addr>     ::= <id> '$' <addr-set>
     <addr>         ::= <hex-string>
     <id>           ::= 'id'   '$' <string> |
                        'uuid' '$' <uuid-string> |
                        'oid'  '$' <oid-string>
     <string>       ::= <char> | <char> <string>
     <char>         ::= <PCS> | '\' <PCS>
     <PCS>          ::= // Portable Character Set:
                        // !"#$%&'()*+,-./0123456789:;<=>?
                        // @ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
                        // `abcdefghijklmnopqrstuvwxyz{|}~
     <uuid-string>  ::= <uuid-char>  | <uuid-char> <uuid-string>
     <uuid-char>    ::= <hex-digit> | '-'
     <oid-string>   ::= <oid-char>  | <oid-char> <oid-string>
     <oid-char>     ::= <digit> | '.'
     <hex-string>   ::= <hex-octet> | <hex-octet> <hex-string>
     <hex-octet>    ::= <hex-digit> <hex-digit>
     <hex-digit>    ::= <digit> |
                        'a' | 'b' | 'c' | 'd' | 'e' | 'f' |
                        'A' | 'B' | 'C' | 'D' | 'E' | 'F'
     <digit>        ::= '0' | '1' | '2' | '3' | '4' | '5' |
                        '6' | '7' | '8' | '9'

The following example is a string form XFN reference:

id$onc_fn_enterprise$id$onc_fn_nisplus_root$0000000f77697a2e636fd2e2062696762696700

The example uses an XFN reference of type onc_fn_enterprise. It contains the address type onc_fn_nisplus_root and a single address value. The address value is an XDR-encoded string, comprising the domain name, doc.com, followed by the host name, cygnus.

An XFN reference may be added to an X.500 entry by using the FNS command fnattr, as in this example:

# fnattr -a .../c=us/o=doc object-class top organization xfn-supplement

creates a new entry called c=us/o=doc and adds an object class attribute with the values top, organization , and XFN-supplement.

The FNS command fnbind binds the NIS+ reference to the named entry and links X.500 to the root of the NIS+ namespace. (Note the use of a trailing slash in the name argument to fnbind.)

# fnbind -r .../c=us/o=doc/ onc_fn_enterprise onc_fn_nisplus_root
 "doc.com. cygnus"

Creating Enterprise Level Contexts

FNS contexts are created using the fncreate command. This section describes how to create FNS contexts individually rather than for the entire organization.. The fncreate command creates a context of the specified type and binds it to the given composite name. It also creates subcontexts for the context.

The fncreate command has the following syntax.

fncreate -t context_type [-f input_file] [-o][-r reference_type][-s][-v] [-D] composite_name

Table 25-13 fncreate Command Options

Note - If you specify the -o option when creating an organization context, the associated host, user, and service contexts are still created but they are not populated.

When creating contexts bound to namespace identifiers, the name without the underscore (for example, user) is used to create the context and the name with the underscore (for example, _user) is then bound to the reference of the newly created context. This is done regardless of whether the name with or without the underscore is specified in the command line.

For example, the command

fncreate -t username org/sales/_user

creates a context for org/sales/user and adds a binding for org/sales/_user to the context of org/sales/user.

Creating an Organization Context

Use the org type to create an organization context. The composite name must be one of the following, depending on the primary naming service:

• NIS+. The name of an existing NIS+ domain (or subdomain). An NIS+ domain is an NIS+ directory object with an org_dir subdirectory. Populated host and passwd tables for the domain must exist in the domain's org_dir subdirectory.

• NIS. The name of the NIS domain. Associated host and passwd maps must also exist.

• /etc files. Only the org// organization context is available when using /etc files.

Organization Context NIS+ Example

Assume the root NIS+ domain is doc.com and the subdomain is sales.doc.com. To create a sales organization context to correspond to the sales subdomain, you would enter the following command:

fncreate -t org org/sales/

When the new context is created, a ctx_dir directory, if it does not already exist, is created under the directory of the domain, sales.doc.com.

Because this example used only the -t option without the -o option, it created an organization context for the composite name org/sales/ and, in addition, created hostname, username, and service subcontexts for it, which in turn, created host and user contexts, and service subcontexts for hosts and users. In effect, that is the same as running the following commands:

fncreate -t hostname org/sales/host/
fncreate -t username org/sales/user/
fncreate -t service org/sales/service/

If, instead, you ran fncreate -o -t org, the org context is created and the hostname, username, and service contexts are also created, but not populated with host and user contexts.

The org context is owned by the administrator who executed the fncreate command, as are the hostname, username, and service subcontexts. The host and user contexts, however, and their subcontexts are owned by the hosts or users for which the contexts were created. In order for the administrator to subsequently manipulate host and user contexts, the NIS_GROUP environment variable must have been set accordingly at the time fncreate is executed. For example, assuming a C-Shell, to set NIS_GROUP to fns_admins.doc.com:

rootmaster# setenv NIS_GROUP fns_admins.doc.com

All Hosts Context

The hostname type creates a hostname context in which host contexts can be created and bound. Host contexts and their subcontexts are created for each machine name found in the NIS+ hosts.org_dir table unless the -o option is used. When the -o option is used, only the hostname context is created.

For example, running the command

fncreate -t hostname org/sales/host/

creates the hostname context and effectively runs the command:

fncreate -t host org/sales/host/hname

Where hname is the name of each machine found in the hosts.org_dir table. It also adds a binding for org/sales/_host/ that is bound to the reference of org/sales/host/.

The hostname context is owned by the administrator who executed the fncreate command. A host context and its subcontexts are owned by the machine for which the contexts were created. That is, each host owns its own host context and subcontexts.

The -f option can be used to create contexts for a subset of the hosts found in the NIS+ table hosts.org_dir. It creates contexts for those hosts listed in the given input file.