Appendix A XFN Composite Names

This appendix describes XFN composite names in detail.

• "Syntax"

• "Composite Name and Naming System Boundaries"

• "Strong Separation"

• "Weak Separation"

• "Composite Name Resolution"

• "Explicit NNSPs: Junctions"

• "Implicit NNSPs"

• "XFN Links"

• "Composite Name Encoding"

• "Backus-Naur Form (BNF)"

• "Decomposing the Composite Name String"

• "Composing the Composite Name String"

Syntax

The standard string form for XFN composite names is the concatenation of the components of a composite name from left to right, with the XFN component separator character (/) separating each component. Components can be quoted using either double-quote ("") or single-quote ('') pairs. You can use a backslash character (\) to excape the XFN component separator or quote characters if the intention is for these characters not to behave as separators or quotes. Note that quotation marks and escape characters are interpreted as such only when they appear in places that need quotes or escapes. For example, a quote appearing in an unquoted component is not interpreted as a quote.

XFN defines an abstract data type, FN_composite_name_t, for representing the structural form of a composite name. XFN also defines the syntax of how component string names are composed into an XFN composite name and the corresponding rules for converting an XFN composite name to its structural form from its string form, and vice versa. The XFN client interface includes operations that perform these conversions.

Table A-1 contains some examples of how the string form of XFN composite names are decomposed into components according to the syntax of XFN composite names. See also "Composite Name Encoding" for more information.

Composite Name and Naming System Boundaries

There might not be a one-to-one correspondence between component separators and naming system boundaries if a composite name contains names from naming systems that use the same character as the XFN component separator to separate their atomic names. Consequently, a component of a composite name might represent an atomic name from a hierarchical naming system that uses the XFN component separator or a compound name. Strong separation and weak separation refer to how a context considers the XFN component separator as a naming system boundary.

Strong Separation

An XFN context that treats the XFN component separator as a naming system boundary supports strong separation. An XFN component separator that appears within a component to be resolved by the context must be escaped or quoted.

Support for strong separation is a property of a context. A context that supports strong separation expects to receive the name that it is going to resolve entirely in one component of the composite name structure. When a composite name is supplied to such a context, it consumes the leading component of the name; any remaining components are left to be resolved by subordinate naming systems.

An XFN context with a name syntax that is either flat or hierarchical, and does not use the XFN component separator as its atomic separator, supports strong separation. Examples of naming systems that support strong separation are DNS and NIS+, both of which have right-to-left dot-separated names. The following are examples of names with DNS and NIS+ components, respectively.

	.../wiz.com/orgunit/ppt
	orgunit/accountspayable.finance/user/jsmith

Weak Separation

An XFN context that does not always treat the XFN component separator as a naming system boundary supports weak separation. This arises when the component naming system associated with the context uses the same character as the XFN component separator as its atomic component separator. The context allows its atomic separator to appear unescaped and unquoted in its compound names when they occur in composite names. This means that an XFN component separator might not necessarily signify a naming system boundary.

Support for weak separation is a property of a context. A context that supports weak separation expects to receive its atomic names in separate components of the composite name structure. When a composite name is supplied to a context that supports weak separation, the context consumes the leading components of the name (and treats them as atomic components); any remaining components are resolved by subordinate naming systems. The number of components consumed is determined either syntactically or dynamically.

CDS names and X.500 names are examples of names that use the XFN component separator as their atomic name separator. X.500 supports weak separation using a syntactic method (by scanning for typed names) while CDS supports weak separation by determining the naming system boundary dynamically.

The following example shows a composite name with an X.500 component.

	.../c=us/o=wiz.com/orgunit/ppt

An XFN context that supports weak separation using only syntax-specific discovery of its naming system boundary might not always be federated with arbitrary subordinate naming systems. If the subordinate naming system has a naming syntax that is indistinguishable from that of the superior naming system, the superior naming system is not able to identify the naming system boundary.

Naming systems that use the same character as the XFN component separator as their atomic separator, and which cannot support weak separation because it cannot use a syntactic or dynamic method to determine the naming system boundary, must provide context implementations that support strong separation. This means that occurrences of atomic separators must be quoted or escaped when they appear in compound names within composite names.

Composite Name Resolution

Composite name resolution combines resolution in each component naming system and resolution across federated naming system boundaries. There are several techniques for resolving an XFN composite name in the underlying federation of naming systems.

This section describes two implementation techniques for composite name resolution across a naming system boundary. One technique uses an explicit next naming system pointer (NNSP) to resolve across a naming system boundary, while the other uses an implicit NNSP.

An NNSP is the XFN reference of an XFN context in which composite name components from subordinate naming systems are to be resolved. NNSPs are entities that "tie" naming systems together into a federated system. NNSPs can be bound to names, in which case they are explicit NNSPs or junctions. NNSPs can also be nameless, in which case they are implicit NNSPs.

Explicit NNSPs: Junctions

A junction is an atomic name that is bound to an NNSP. It is a terminal name in the superior naming system. There is no limit to the number of junctions bound in a single context, except that imposed by the context. A context can reserve certain names for use as junctions or have other policies for selecting names for use as junctions. The conventions used for identifying junctions and their references are context-specific.

Composite name resolution involving junctions proceeds as follows, depending on whether the context supports strong or weak separation.

A context that supports strong separation and junctions consumes the first component of the composite name supplied to it. The last atomic name of the first component must be a junction. Any remaining components are resolved in the context named by the junction.

A context that supports weak separation and junctions resolves a composite name by consuming leading components until a junction is reached, at which point resolution of any remaining components is continued in the context resolved by the junction. Determination of whether a component is a junction can be done statically, using a syntactic policy, or dynamically during resolution.

Implicit NNSPs

When a context does not want to use part of its namespace for junctions, it uses implicit NNSPs for federating subordinate naming systems. An implicit NNSP is named using the XFN component separator. For example, the name wiz.com/ names the implicit NNSP of wiz.com. Each context can have one implicit NNSP.

Composite name resolution involving implicit NNSPs proceeds as follows, depending on whether the context supports strong or weak separation.

A context that supports strong separation and resolves composite names using an implicit NNSP consumes the first component of the composite name supplied to it. Any remaining components are resolved in the context pointed to by the implicit NNSP of the first component.

A context that supports weak separation and implicit NNSPs in its implementation needs to distinguish the use of the XFN component separator character as an XFN component separator or an atomic separator. This means that such a context needs to know when to exit the current (native) naming system and follow the NNSP. This can be achieved using a static, syntactic policy or a dynamic, resolution-based policy.

With the syntactic policy, a context syntactically discovers where the boundary between its naming system and the subordinate naming system lies. This can impose certain restrictions on the syntax of subordinate naming systems. Subordinate naming systems must not permit, as valid top-level names, that are syntactically indistinguishable from names allowed in the superior naming system. For example, assume the superior naming system has a name syntax whose distinguishing feature is that each atomic part must have an equal sign (=). The superior naming system might impose as a policy that subordinate naming systems must not have top-level names with an equal sign in them. Resolution in the superior naming system continues until all leading components of the supplied composite name fitting the syntactic rule are consumed. Any remaining components are resolved in the context of the NNSP of the last component fitting the syntactic rule.

If a context is not able to syntactically differentiate between atomic components and composite name components, or does not want to impose any syntactic restrictions, it might be able to determine the naming system boundary at runtime, during resolution. The policy is to continue resolution in the current naming system until resolution fails, at which point the implicit NNSP associated with the last context at which resolution succeeded is used to continue the resolution. A conflict arises if the same atomic name is bound both in the last context and the context pointed to by the last context's implicit NNSP. In this case, the binding in the last context takes precedence. This way of supporting weak separation requires the context to have the capability of returning remaining unresolved parts of a given name.

Coexistence of Explicit and Implicit NNSPs

Naming systems that implement either technique can coexist in a federation. A naming system that supports composite name resolution using junctions can be federated with one that supports implicit NNSPs, and vice versa.

XFN Links

An XFN link affects name resolution in the following way. Suppose lname is a link bound to the atomic name aname in the context ctx. If at some point resolution of a composite name cname reaches the context ctx and the next atomic name is aname, resolution of aname results in the resolution of the link name lname. This is termed "following the link." If the first component of the link lname is the atomic name ".", the remaining components of lname are resolved relative to ctx; otherwise, lname is resolved from the initial context. The resolution of any remaining portion of the name cname proceeds from the reference that results by resolving lname.

The link name can itself cause resolution to resolve through other links. This gives rise to the possibility of a cycle of links whose resolution could not terminate normally. As a simple means to avoid such nonterminating resolutions, implementations can define limits on the number of XFN links that can may be resolved in any single operation invoked by the caller.

Composite Name Encoding

All XFN implementations are required to support the ISO 646 portable representation (same encoding as ASCII) for XFN composite names. All other representations are optional.

All characters of the string form of an XFN composite name use a single encoding. Characters with different encodings cannot exist in the same name string. This does not preclude component names of a composite name in its structural form from having different encodings. Code set mismatches that occur during the process of converting a composite name structure to its string form are resolved in an implementation-dependent way. Strings with code sets that are determined by the implementation to be compatible are converted without loss of information into a single representation, which is also determined by the implementation. When an implementation discovers that a composite name has components with incompatible code sets, it returns the error code FN_E_INCOMPATIBLE_CODE_SETS.

Backus-Naur Form (BNF)

The following defines the standard string form of XFN composite names in Backus-Naur Form (BNF). All the characters of the string representation of one name must uniformly use the same encoding and locale information. The notations used are as shown in Table A-2:

The XFN composite name syntax in BNF is shown in Table A-3:

// Portable Character Set
The set consists of the glyphs:
//!"#$%&'()*+,\0123456789:;<=>? 
//@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_'
//abcdefghijklmnopqrstuvwxyz{|}~

<PCS>
| Characters from the repertoire of a string representation

// any character from <CharSet> with <MetaChar>, <Quote1>,
// and <Quote2> excluded. An<EscapeChar> <MetaChar>, or
// <EscapeChar> <Quote1>, or <EscapeChar> <Quote2> is equivalent to
// <SimpleChar>.

<SimpleChar>*
| <SimpleChar>+ {<Quote1> |  <Quote2> | <SimpleChar>}*
| <Quote1> <CharSet>* {<EscapeChar> <Quote1>}* <Quote1>
 // <CharSet> must not contain unescaped <Quote1>
 // (note that <Quote2> can appear unescaped)  
| <Quote2> <CharSet>* {<EscapeChar> <Quote2>}* <Quote2>
 // <CharSet> must not contain unescaped <Quote2>
 // (note that <Quote1> can appear unescaped)

NULL
| <Component> {<ComponentSep> <Component>}*   

Decomposing the Composite Name String

The function fn_composite_name_from_string() returns an XFN composite name in its structural form, FN_composite_name_t, given the composite name's string representation. The syntax rules used by fn_composite_name_from_string() are as follows:

• An XFN composite name is decomposed into an ordered set of components (<Component>).

• Each component represents a compound name, or a single atomic name of a compound name if the compound name's syntax uses the XFN component separator (/) as a separator for its atomic parts and the compound name is not quoted.

The following are the rules for parsing a composite name.

1. Any <ComponentSep> character that is neither escaped nor enclosed in quoted strings is considered to be a component separator.

2. Any string enclosed by component separators is a component (<Component>).

3. A composite name is parsed and decomposed into components from left to right:

   1. The first component is the string preceding the first occurrence of a component separator.

   2. Empty components are processed as follows:

      1. A leading component separator (the composite name begins with a component separator) means a leading null component.

      2. A trailing component separator (the composite name ends with a component separator) means a trailing null component.

   3. Two consecutive component separators mean a null component.

   4. The name string that immediately follows the last component separator of the composite name is the final component.

4. A component string is evaluated from left to right and converted into its standard form according to the following rules:

   1. A component string is considered to be quoted if it is enclosed in a pair of matching unescaped quote characters (either a <Quote1> or a <Quote2> pair). The quoted string must represent the full component; that is, a begin quote must immediately be preceded by a component separator or no character, and the end quote must immediately be followed by a component separator or no character.

   2. If a component does not contain a valid begin quote (a <Quote1> or <Quote2> immediately preceded by either a component separator or no character), any occurrence of <Quote1> or <Quote2> within that component is treated just as any other <SimpleChar>.

   3. An unmatched begin quote (missing or misplaced end quote) fails with an FN_E_ILLEGAL_NAME status.

   4. Quotes are considered to be escaped in quoted strings if a matching quote character is preceded immediately by the unescaped <EscapeChar>.

   5. Quoted components are resolved by eliminating the quote characters from the component name and substituting possibly escaped quotes by simple quote characters. <MetaChar>s and the nonmatching quote characters enclosed in quoted strings are treated just as any other <SimpleChar>.

   6. Any of the defined metacharacters (<ComponentSep> and <EscapeChar>) is considered to be escaped in an unquoted component name string if preceded immediately by the unescaped <EscapeChar> (for instance, the sequence <EscapeChar> <EscapeChar> <ComponentSep> denotes an escaped <EscapeChar> but an unescaped <ComponentSep>).

   7. <Quote1> and <Quote2> are considered to be escaped in an unquoted component if and only if <EscapeChar> is preceded by a component separator (that is, sequences <ComponentSep> <EscapeChar> <Quote1> or <ComponentSep> <EscapeChar> <Quote2>). Other occurrences of <Quote1> and <Quote2> in an unquoted component are treated just as any other <SimpleChar>.

   8. Any occurrence of escaped <MetaChar>, escaped <Quote1>, or escaped <Quote2> in unquoted components is substituted by the corresponding unescaped character.

   9. No substitution is done for <EscapeChar> <SimpleChar>. <EscapeChar> <SimpleChar> maps to <EscapeChar> <SimpleChar>.

Composing the Composite Name String

The function fn_string_from_composite_name() returns the string representation of an XFN composite name given its structural form (FN_composite_name_t). The following are the rules used by fn_string_from_composite_name().

1. The components are added to the composite name string in left to right order (that is, rightmost is the tail).

2. Successive components are separated by the component separator (<ComponentSep>).

3. Empty components are handled in the following way:

   1. A leading empty component is represented by a leading <ComponentSep>.

   2. A trailing empty component is represented by a trailing <ComponentSep>.

   3. An empty component occurring within a composite name is represented by two consecutive <ComponentSep>s.

4. A composite name denoting a single non-empty component does not contain any unescaped component separator.

5. Any occurrence of <ComponentSep> in a component is escaped by inserting <EscapeChar> immediately preceding <ComponentSep>.

6. If the first character of a component is either <Quote1> or <Quote2>, it will be escaped by inserting <EscapeChar> immediately preceding the quote.

7. Any occurrence of <EscapeChar> before <ComponentSep> in a component is escaped by inserting <EscapeChar> immediately preceding the <EscapeChar>.

8. Any occurrence of <EscapeChar> as the first character of a component with <Quote1> or <Quote2> as the second character in a component is escaped by inserting <EscapeChar> immediately preceding the <EscapeChar>. Subsequent <EscapeChar> occurring before any matching quote character is also escaped by inserting <EscapeChar> immediately preceding the <EscapeChar>.