[ADDITIONS]: Discuss crude spatialContext virtualization alternative

[JesseCoretta]

Consider the following conditions:

• No Collective Attribute functionality, nor ClassOfService
• Min, Max, Sup and Top values are desired
• Manual management of these values is undesirable, and/or space requirements would be excessive

Given a generic subentry of the following design, present beneath any parent registration in which siblings are present:

dn: cn=spatialContext,<parent dn>
objectClass: top
objectClass: subentry
objectClass: spatialContext
subtreeSpecification: {}
minArc: <minimum sibling DN>
maxArc: <maximum sibling DN>
supArc: <parent DN>
topArc: <top DN>

... capable RA DUAs, when faced with a group of sibling entries which lack these types, and their collective variants, MAY perform a separate baseObject-scoped search request for a subentry, identified by the RDN cn=spatialContext and joined by comma (",") with the parent DN. For example, if the parent DN is:

n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA

... then the relative subentry, such as the one shown above, should bear the DN:

cn=spatialContext,n=1,n=4,n=1,n=6,n=3,n=1,ou=Registrations,o=rA

Use of the cn RDN type and the spatialContext RDN value is RECOMMENDED for RA DUA simplicity and predictability. Case is not significant in the matching process.

To access the subentry, an RA DUA can either "blindly" call the DN, OR simply attempt to grab all subentry instances beneath the intended parent.

Benefits:

• No reliance upon virtualization of (listed) attribute types
• No need to manually manage large numbers of entries; simply maintain the spatialContext subentry
• Reduced storage requirements (particularly in large setups)
• No need to manage separate non-collective and collective instances within context
• Can be "mixed" with collective attribute functionality, allowing for smaller contexts that may not qualify for collective virtualization to benefit in similar fashion

Drawbacks:

• Though not harmful, this is an atypical use of subentry entries
  • Normal entries cannot suffice, as their enumeration may interfere with client-driven DN extrapolation, given the lack of the requisite n type for registration entries
• RA DUA responsibilities increase:
  • RA DUA must be aware of this technique and be capable of supporting it, imposing the contents of the subentry upon appropriate registration entries
  • RA DUA is expected to MAINTAIN subentry instances incremental fashion, such as updating the maxArc DN following a successful allocation
• RA DUA must make a separate LDAP search request to obtain the subentry
• Does not help with Left, Right and Sub spatial types (but neither do virtualized or collective types)