home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD2.mdf / ccitt / 1992 / x / x525_d.asc < prev    next >
Text File  |  1994-01-30  |  109KB  |  2,508 lines
  1.                                - _ -
  2.                           COM VII-R 51-E
  3. CCITT\COMVII\RAPP\R051E4.DOC
  4.  
  5.  
  6.  
  7.  
  8.  
  9.  
  10.  
  11.  
  12.  
  13.  
  14.  
  15.  
  16.  
  17.  
  18. 5.   Draft new Recommendation X.525
  19.  
  20.  
  21.  
  22.  
  23.  
  24.  
  25.  
  26.  
  27.  
  28.  
  29.  
  30.  
  31.  
  32. Information Technology ╤
  33.  
  34. Open Systems Interconnection ╤
  35.  
  36. The Directory: Replication
  37.  
  38.  
  39.  
  40. Draft Recommendation X.525
  41.  
  42. ISO/IEC DIS 9594-9
  43.  
  44. Contents page
  45.  
  46.  
  47. Introduction
  48.  
  49.      This Recommendation|International Standard, together with the
  50. others of the series, has been produced to facilitate the
  51. interconnection of information processing systems to provide
  52. directory services.  The set of all such systems, together with the
  53. directory information which they hold, can be viewed as an
  54. integrated whole, called the Directory.  The information held by
  55. the Directory, collectively known as the Directory Information Base
  56. (DIB) is typically used to facilitate communication between, with
  57. or about objects such as application-entities, people, terminals
  58. and distribution lists.
  59.  
  60.      The Directory plays a significant role in Open Systems
  61. Interconnection, whose aim is to allow, with a minimum of technical
  62. agreement outside of the interconnection standards themselves, the
  63. interconnection of information processing systems:
  64.      ╤  from different manufacturers;
  65.      ╤  under different managements;
  66.      ╤  of different levels of complexity; and
  67.      ╤  of different ages.
  68.  
  69.      This Recommendation|International Standard defines the
  70. Replication capabilities provided by DSAs to improve the level of
  71. service to Directory users.
  72.  
  73.  
  74. Information Technology - Open Systems Interconnection - The
  75.      Directory - Replication
  76.  
  77.  
  78. 1    Scope
  79.  
  80.      This Recommendation|International Standard specifies a shadow
  81. service which DSAs may use to replicate Directory information.  The
  82. service allows Directory information to be replicated among DSAs to
  83. improve service to Directory users.  The shadowed information is
  84. updated, using the defined protocol, thereby improving the service
  85. provided to users of the Directory.
  86.  
  87.  
  88. 2    Normative references
  89.  
  90.      The following Recommendations|International Standards contain
  91. provisions which, through reference in this text, constitute
  92. provisions of the Recommendation|International Standard.  At the
  93. time of publication, the editions indicated were valid.  All
  94. Recommendations|International Standards are subject to revision,
  95. and entities to agreements based on this
  96. Recommendation|International Standard are encouraged to investigate
  97. the possibility of applying the most recent edition of the
  98. Recommendations|Standards listed below.  Members of IEC and ISO
  99. maintain registers of currently valid International Standards.  The
  100. CCITT Secretariat maintains a list of currently valid CCITT
  101. Recommendations.
  102.      ╤  CCITT Recommendation X.500 (1992) | ISO/IEC 9594-1:1992,
  103.         Information Technology ╤ Open Systems Interconnection ╤ The
  104.         Directory: Overview of Concepts, Models and Services.
  105.      ╤  CCITT Recommendation X.501 (1992) | ISO/IEC 9594-2:1992,
  106.         Information Technology ╤ Open Systems Interconnection ╤ The
  107.         Directory: Models.
  108.      ╤  CCITT Recommendation X.511 (1992) | ISO/IEC 9594-3:1992,
  109.         Information Technology ╤ Open Systems Interconnection ╤ The
  110.         Directory: Abstract Service Definition.
  111.      ╤  CCITT Recommendation X.518 (1992) | ISO/IEC 9594-4:1992,
  112.         Information Technology ╤ Open Systems Interconnection ╤ The
  113.         Directory: Procedures for Distributed Operation.
  114.      ╤  CCITT Recommendation X.519 (1992) | ISO/IEC 9594-5:1992,
  115.         Information Technology ╤ Open Systems Interconnection ╤The
  116.         Directory: Protocol Specifications.
  117.      ╤  CCITT Recommendation X.520 (1992) | ISO/IEC 9594-6:1992,
  118.         Information Technology ╤ Open Systems Interconnection ╤The
  119.         Directory: Selected Attribute Types.
  120.      ╤  CCITT Recommendation X.521 (1992) | ISO/IEC 9594-7:1992,
  121.         Information Technology ╤ Open Systems Interconnection ╤The
  122.         Directory: Selected Object Classes.
  123.      ╤  CCITT Recommendation X.509 (1992) | ISO/IEC 9594-8:1992,
  124.         Information Technology ╤ Open Systems Interconnection ╤ The
  125.         Directory: Authentication Framework.
  126.      ╤  ISO/IEC DIS 8824-1:1992, Information Technology ╤ Open
  127.         Systems Interconnection ╤ Abstract Syntax Notation One
  128.         (ASN.1): Specification of Basic Notation.
  129.      ╤  ISO/IEC DIS 8824-2:1992, Information Technology ╤ Open
  130.         Systems Interconnection ╤ Abstract Syntax Notation One
  131.         (ASN.1): Information Object Specification.
  132.      ╤  ISO/IEC DIS 8824-3:1992, Information Technology ╤ Open
  133.         Systems Interconnection ╤ Abstract Syntax Notation One
  134.         (ASN.1): Constraint Specification.
  135.      ╤  ISO/IEC DIS 8824-4:1992, Information Technology ╤ Open
  136.         Systems Interconnection ╤ Abstract Syntax Notation One
  137.         (ASN.1): Parameterization of ASN.1 Specifications.
  138.      ╤  CCITT Recommendation X.219 (1988) Remote Operations ╤
  139.         Model, Notation and Service Definition.
  140.        ISO/IEC 9072-1:1989, Information Processing Systems ╤ Text
  141.         Communication ╤ Remote Operations Part 1: Model, Notation
  142.         and Service Definition.
  143.        ISO/IEC 9072-2:1989, Information Processing Systems ╤ Text
  144.         Communication ╤ Remote Operations: Protocol Specification.
  145.      ╤  CCITT Recommendation X.218 (1988) Reliable Transfer.
  146.        ISO/IEC 9066-1:1989, Information Processing Systems ╤ Text
  147.         Communication ╤ Reliable Transfer.
  148.  
  149. 3    Definitions
  150.  
  151. 3.1  The following term is defined in CCITT Rec.  X.500 | ISO/IEC
  152. 9594-1;
  153.      a)(the) Directory.
  154.  
  155. 3.2  The following terms are defined in CCITT Rec.  X.501 | ISO/IEC
  156. 9594-2;
  157.      a)distinguished name;
  158.      b)Directory Information Tree;
  159.      c)DSA Specific Entry;
  160.      d)DSA Information Model;
  161.      e)DSA Information Tree;
  162.      f)Directory System Agent;
  163.      g)operational attributes;
  164.      h)user attributes.
  165.  
  166. 3.3  The following terms are defined in CCITT Rec.  X.518 | ISO/IEC
  167. 9594-4;
  168.      a)access point;
  169.      b)knowledge information;
  170.      c)name resolution;
  171.      d)naming context;
  172.      e)non-specific subordinate reference;
  173.      f)subordinate reference.
  174.  
  175. 3.4  For purposes of this Recommendation|International Standard,
  176. the following definitions apply:
  177.      a)area prefix: The sequence of RDNs and associated
  178.         administrative information common to all entries within a
  179.         replicated area;
  180.      b)cache copy: A copy of an entry (or part of an entry) whose
  181.         consistency with its corresponding entry is maintained by
  182.         means outside the scope of this Directory Specification;
  183.      c)caching: The process of creating cache copies. This process
  184.         is outside the scope of this Directory Specification;
  185.      d)consumer reference:  The access point of the shadow
  186.         consumer;
  187.      e)entry copy: Shadowed information from an entry;
  188.      f)extended knowledge:  Those subordinate references that
  189.         would be included as subordinate knowledge if the
  190.         replicated area were extended to the lower boundary of the
  191.         naming context;
  192.      g)master DSA: The DSA which has administrative authority for
  193.         a naming context. All adds, deletes and modifications to
  194.         entries in this naming context are done by this DSA.  The
  195.         master DSA may enter into a shadowing agreement with
  196.         another DSA to provide copies of a subset of this naming
  197.         context (see unit of replication);
  198.      h)primary shadowing: Shadowing where the shadow supplier is
  199.         the master DSA;
  200.      i)replicated area: A subtree from which entries for
  201.         replication are selected;
  202.      j)replication: The process by which copies of entry and
  203.         operational information are held by DSAs other than the
  204.         master DSA;
  205.      k)replication base entry:  The distinguished name of the root
  206.         vertex of the replicated area;
  207.      l)secondary shadowing: Shadowing where the shadow supplier is
  208.         not the master DSA;
  209.      m)shadow consumer: A DSA that receives shadowed information;
  210.      n)shadow service: The service provided to perform shadowing
  211.         between two DSAs that have entered into one or more
  212.         shadowing agreements;
  213.      o)shadow supplier: A DSA that provides shadowed information.
  214.         This DSA may or may not be the master DSA;
  215.      p)shadowed DSA specific entry (SDSE):  A unit of shadowed
  216.         information which is associated with a specific name; it
  217.         represents the information taken from a DSE which is
  218.         shadowed;
  219.      q)shadowed information:  The complete set of information
  220.         associated with a unit of replication.  Shadowed
  221.         information is conceptually held both by the shadow
  222.         supplier and the shadow consumer for the purposes of the
  223.         shadow protocol and comprises a tree shaped structure of
  224.         shadowed DSEs;
  225.      r)shadowing: Replication between two DSAs whereby shadowed
  226.         information is copied and maintained using the Directory
  227.         Information Shadowing Protocol;
  228.      s)shadowing agreement: The terms conforming to an agreement
  229.         between two DSA Administrative Authorities (one being the
  230.         Administrative Authority of the shadow supplier and the
  231.         other being the Administrative Authority of the shadow
  232.         consumer);
  233.      t)supplier reference:  The access point of the shadow
  234.         supplier;
  235.      u)unit of replication:  A specification of the information to
  236.         be shadowed, including (optionally) subordinate knowledge
  237.         information.
  238.  
  239.  
  240. 4    Abbreviations
  241.  
  242.      The following abbreviations are used in this
  243. Recommendation|International Standard:
  244.      DIB    Directory Information Base
  245.      DISP Directory Information Shadowing Protocol
  246.      DIT    Directory Information Tree
  247.      DSA  Directory System Agent
  248.      DSE  DSA Specific Entry
  249.      RDN  Relative Distinguished Name
  250.      SDSE Shadowed DSA Specific Entry
  251.  
  252.  
  253. 5    Conventions
  254.  
  255.      This Directory Specification has been prepared according to
  256. the "Presentation of CCITT/ISO/EC common text" guidelines in the
  257. Guide for CCITT and ISO/IEC JTC 1 Cooperation, September 1991.
  258. Exceptions to these guidelines are described below.
  259.  
  260.      The term "Directory Specification" (as in "this Directory
  261. Specification") shall be taken to mean CCITT
  262. Recommendation╩X.525|ISO/IEC╩9594-9. The term "Directory
  263. Specifications" shall be taken to mean the X.500-Series of
  264. Recommendations and all parts of ISO/IEC 9594.
  265.  
  266.      Some Directory Specifications may be organized into sections
  267. which signal to the reader the beginning of material significantly
  268. different in content to that proceeding. Division into sections
  269. merely aids the user and does not affect clause numbering.
  270.  
  271.      If the items in a list are numbered (as opposed to using "╨"
  272. or letters), then the items shall be considered steps in a
  273. procedure.
  274.  
  275.      All text in a note is indented (not just the first line). The
  276. term "note" is in boldface type and all the note is in nine point.
  277. Some notes may contain requirements.
  278.  
  279.      Those Directory Specifications defining Directory operations
  280. do so using the Remote Operation notation defined in CCITT
  281. Recommendation╩X.219|ISO/IEC 9072-1.
  282.  
  283.      All ASN.1 notation is in a bold sans serif typeface. If an
  284. ASN.1 type or value is used in text, it is in a bold sans serif
  285. typeface one point smaller than the text of the clause in which it
  286. is contained.
  287.  
  288.      In clause 3, the terms being defined appear in italics rather
  289. than in boldface (as per the agreed format for common text). Since
  290. ASN.1 terms appear throughout the Directory Specification in
  291. boldface, the use of italics is intended to clarify that these are
  292. defined terms and not ASN.1 types or values.
  293.  
  294.      As these Directory Specifications are being constructed
  295. through the ISO/IEC amendment process, additional annexes which
  296. form an integral part of this Directory Specification may appear
  297. after annexes which are not an integral part of this Directory
  298. Specification.
  299.  
  300.      This Directory Specification uses the term "1988 edition
  301. systems" to refer to systems conforming to the previous (1988)
  302. edition of the Directory Specifications Systems conforming to the
  303. current Directory Specifications are referred to as "1992 edition
  304. systems".
  305.  
  306.      The last annex of this Directory Specification lists which
  307. amendments and technical corrigenda have been incorporated to form
  308. this edition of this Directory Specification.
  309.  
  310.  
  311. 6    Replication in the Directory
  312.  
  313.      Replicated (copied) information can exist in the Directory.
  314. Caching and shadowing are two mechanisms for replication.
  315. Directory information can also be replicated by means outside this
  316. Specification.  Any such alternative means of replication will need
  317. to ensure that exactly one instance of each replicated entry is
  318. identified as the master copy if the Directory and DSA Abstract
  319. Services are to be used.
  320.  
  321.      Service controls provide the ability to control whether
  322. replicated information may be used in support of directory
  323. operations, regardless of the replication mechanism used to acquire
  324. the copy.
  325.  
  326. 6.1  Caching
  327.  
  328.      One method of replicating directory information is caching.
  329. Caching procedures are considered to be almost entirely governed by
  330. local policies, and therefore outside the scope of this
  331. Specification.
  332.  
  333. 6.2  Shadowing
  334.  
  335.      Another method of replicating directory information is
  336. shadowing.  An overview of the Directory information shadow service
  337. is found in clause 7.  Before shadowing can occur, the
  338. Administrative Authorities of the two DSAs involved must come to
  339. agreement on the terms under which the shadowing will take place.
  340. This negotiation is done prior to any protocol exchange.
  341. Components of the agreement are described in clause 9 of this
  342. Specification.
  343.  
  344.      Once the terms of the agreement have been established, the
  345. DSAs may initiate, modify and subsequently terminate the agreement.
  346. This may be done through a shadow operational binding as described
  347. in clause 8 of this Specification.
  348.  
  349.      This shadowing service for the Directory is based on the
  350. models established in CCITT Rec. X.501|ISO/IEC 9594-2, to satisfy
  351. the requirements outlined in CCITT Rec. X.500|ISO/IEC 9594-1.  The
  352. protocol specification for shadowing and conformance requirements
  353. are provided in CCITT Rec. X.519|ISO/IEC 9594-5.  In addition, this
  354. Specification provides the definition of an operational binding for
  355. the purpose of initiating and terminating shadowing agreements
  356. between DSAs.  This operational binding type is defined using the
  357. tools specified in CCITT Rec. X.501|ISO/IEC 9594-2.
  358.  
  359. The directory information shadow service is described in clause 10
  360. of this document.  The actual shadowing occurs through the set of
  361. operations defined in clause 11.  These operations accommodate the
  362. transfer of Directory information and updates to the shadowed
  363. information.
  364.  
  365.      The use of shadowed information by a DSA to satisfy a
  366. Directory request is described in CCITT Rec. X.518|ISO/IEC 9594-4.
  367.  
  368. 6.3  Shadowing functional model
  369.  
  370.      In the standardized form of Directory replication, termed
  371. shadowing, a DSA may assume the role of shadow supplier, the source
  372. of shadowed information, or shadow consumer, the recipient  of
  373. shadowed information. The role played by a DSA when engaging in
  374. standardized replication activities (shadow supplier or shadow
  375. consumer) is always with respect to another DSA which plays the
  376. reciprocal role (shadow consumer or shadow supplier).
  377.  
  378.      A given DSA may assume both roles, either
  379.      ╤  with respect to different DSAs for the same or different
  380.         units of replication; or
  381.      ╤  with respect to a single DSA (which plays the reciprocal
  382.         role) for different units of replication.
  383.  
  384.      The Shadowing functional model addresses two approaches to
  385. shadowing Directory information:
  386.      ╤  a primary shadowing policy requires that each shadow
  387.         consumer receives its updates directly from the master DSA
  388.         for the unit of replication;
  389.      ╤  a secondary shadowing policy permits a shadow consumer to
  390.         assume the shadow supplier role with respect to shadow
  391.         consumers not having a shadowing agreement directly with
  392.         the master DSA.
  393.  
  394.      The characteristics of these two policies and their approach
  395. to satisfying the requirements for levels of performance,
  396. availability, reliability and recovery that cannot otherwise be met
  397. are described below.
  398.  
  399. 6.3.1Primary shadowing
  400.  
  401.      Figure 1 depicts primary shadowing. In this case the shadowing
  402. policy in effect has the following characteristics:
  403.      a)the master DSA is the only shadow supplier;
  404.      b)each shadow consumer has a direct shadowing agreement with
  405.         the master DSA;
  406.      c)only read (including compare) and search (including list)
  407.         operations may be performed at a shadow consumer holding
  408.         shadowed information.  All modification operations are
  409.         directed to the master DSA.
  410.  
  411.      Because it allows for the placement of copies of often
  412. requested information, or knowledge of it, closer to the requestor,
  413. this approach may be used to satisfy the performance requirement.
  414. Also, because this approach provides for the redundancy of
  415. individual entry or knowledge information it also is capable, in a
  416. primitive sense, of satisfying the availability, reliability, and
  417. recovery requirements.
  418.                                  
  419.                             T0712580-91
  420.                                  
  421.                                  
  422.                              FIGURE 1
  423.                          Primary shadowing
  424.                                  
  425.                                  
  426.                                  
  427.  
  428. 6.3.2Secondary shadowing
  429.  
  430.      Figure 2 depicts secondary shadowing. In this case the
  431. shadowing policy in effect has the following characteristics:
  432.      a)the master DSA is not the only shadow supplier. Only some
  433.         shadow consumers have a direct shadowing agreement with the
  434.         master DSA as their shadow supplier;
  435.      b)other shadow consumers may have a shadowing agreement with
  436.         a shadow supplier that is not the master for the unit of
  437.         replication. The shadowing agreements between the master
  438.         DSA and its direct shadow consumers may, however, have an
  439.         impact on secondary shadowing agreements;
  440.      c)only read (including compare) and search (including list)
  441.         operations may be performed at a shadow consumer holding
  442.         shadowed information.  All modification operations are
  443.         directed to the master DSA, whether directly (if a
  444.         secondary shadow consumer DSA has knowledge of the master
  445.         DSA) or indirectly via the shadow supplier DSA(s);
  446.  
  447.      Secondary shadowing is very similar to primary shadowing in
  448. the way it addresses the performance, availability, reliability and
  449. recovery requirements. It differs in that it relieves the single
  450. master DSA of the burden of directly contacting all shadow
  451. consumers for the shadowed information. This is a desirable
  452. combination in environments where a large number of shadow
  453. consumers are holding the same shadowed information.
  454.                                  
  455.                             T0712590-91
  456.                                  
  457.                                  
  458.                              FIGURE 2
  459.                         Secondary shadowing
  460.                                  
  461.                                  
  462.                                  
  463.  
  464.  
  465. 7    Overview of the Directory information shadow service
  466.  
  467.      The directory information shadow service defined here provides
  468. the Directory with a standardized mechanism to provide and support
  469. replicated information.  In outline,  the shadow supplier
  470. maintains, for each shadowing agreement, information which is to be
  471. shadowed (the shadowed information).  This information is
  472. replicated by protocol exchange between the shadow supplier and the
  473. shadow consumer.  The information to be shadowed is all or a subset
  474. of the information held by the shadow supplier's DSA Information
  475. Tree.  The shadow consumer's shadowed information becomes part of
  476. its DSA Information Tree.
  477.  
  478.      To use the directory information shadow service, the
  479. Administrative Authorities of two DSAs must first reach an
  480. agreement on the terms under which shadowing will take place.  This
  481. agreement, and the technical specification related to this
  482. agreement (the shadowing agreement), is discussed in 7.1.  A
  483. description of the manner in which shadowed information is
  484. represented for the purposes of shadowing is provided in 7.2 below.
  485. The actual transfer of this shadowed information from the shadow
  486. supplier to the shadow consumer is accomplished by means of a set
  487. of shadow operations, which are introduced in 7.3.
  488.  
  489.      The use of shadowed information to satisfy Directory requests
  490. is described in CCITT Rec.╩X.518 ISO/IEC 9594-4.
  491.  
  492.  
  493. 7.1  Shadowing agreement
  494.  
  495.      The agreement that is reached between the Administrative
  496. Authorities of two DSAs forms the technical and policy basis for
  497. the provision of the directory information shadow service.  This
  498. agreement may include any set of terms acceptable on a bilateral
  499. basis to the two Administrative Authorities.  For example, the
  500. agreement may specify policy information related to security,
  501. charging, or special conditions such as the deletion of shadowed
  502. information upon termination of the agreement.
  503.  
  504.      Certain aspects of the shadowing agreement must be specified,
  505. including an identifier by which the shadowing agreement  will be
  506. referenced, a specification of the unit of replication, information
  507. related to the update mode, and optionally,  the access point of
  508. the master DSA for the shadowed information.  Some technical
  509. aspects of the shadowing agreement may be exchanged via protocol
  510. and are discussed in detail in clause 9.   Access control
  511. information is always supplied and need not be explicitly specified
  512. in the shadowing agreement.  Initially the shadowing agreement is
  513. created by an off-line administrative process.  It represents
  514. essentially a template whose technical parameter values are
  515. subsequently validated during the initiating phase of the agreement
  516. and possibly modified during modification operations on the
  517. agreement. The method of storing this agreement is beyond the scope
  518. of this Specification.
  519.  
  520.      It must be noted that although the shadowing agreement will
  521. normally provide a true representation of the technical parameters
  522. related to the directory information shadow service, there may be
  523. exceptional cases in which policy overrides the technical
  524. specification resulting in a service inconsistency.  For example,
  525. there may be certain attributes or attribute values that must be
  526. withheld for security reasons.  It may be the case that security
  527. policy prevents disclosing the mere existence of these attributes,
  528. in which case it would be a violation to represent in the shadowing
  529. agreement the fact that they are being withheld.  In this type of
  530. situation, the behaviour of the shadow supplier DSA will be as if
  531. the technical specification were a true representation.  Thus,
  532. users with access to the sensitive data will receive different
  533. views of the affected entries, depending on whether they access the
  534. master or a shadow consumer.
  535.  
  536. 7.2  Shadowed information
  537.  
  538.      Shadowed information is the logical set of information which
  539. is replicated by the shadow consumer.  The three components of
  540. shadowed information are:
  541.      a)area information :  Information about DSEs whose names fall
  542.         within the replicated area;
  543.      b)prefix information :  Information relevant to entries
  544.         within the replicated area which, with respect to the DSA
  545.         information model, are positioned between the area prefix
  546.         and the root DSE.  This may contain administrative point
  547.         and subentry information;
  548.      c)subordinate information :  Information about knowledge
  549.         references subordinate to the replicated area.
  550.  
  551.      Figure 3 illustrates the derivation of shadowed information.
  552.                                  
  553.                             T0712600-91
  554.                                  
  555.                                  
  556.                              FIGURE 3
  557.         Shadow supplier derivation of shadowed information
  558.                                  
  559.                                  
  560.                                  
  561.  
  562.      As illustrated at the left of figure 3, the replicated area
  563. must be fully contained within a single naming context.  The unit
  564. of replication specifies the replicated area and any requirements
  565. pertinent to the shadowing of subordinate knowledge references.
  566. The specification of the unit of replication may extend beyond the
  567. naming context, however the replicated area is limited to the
  568. naming context.  From this unit of replication specification, the
  569. shadow supplier can derive a representation of the shadowed
  570. information, which, as shown at the right of the figure, includes
  571. the prefix information, the area information (representing
  572. information held by DSEs in the replicated area), and (optionally)
  573. subordinate information.  This shadowed information is subsequently
  574. conveyed by protocol to the shadow consumer which then integrates
  575. the information into its own DSA information tree.  The shadowed
  576. information is built out of shadowed DSEs (SDSEs), which are
  577. discussed in 7.2.1.  The establishment of shadowed information is
  578. discussed in 7.2.2.
  579.  
  580.      Figure 4 illustrates the derivation of shadowed information
  581. where extended knowledge is included.
  582.                                  
  583.                             T0212610-91
  584.                                  
  585.                                  
  586.                              FIGURE 4
  587.  Shadow supplier derivation of shadowed information with extended
  588.                              knowledge
  589.                                  
  590.                                  
  591.                                  
  592.  
  593. 7.2.1SDSEs
  594.  
  595.      Shadowed DSE (SDSE) :  That information within shadowed
  596. information that is associated with a specific name.  It is the
  597. information to be replicated from a DSE.  It is distinct from this
  598. DSE, and is therefore not part of the DSA Information Model.
  599.  
  600.      The definition and transfer of SDSEs is not intended to impose
  601. any obligation to have a distinct representation of SDSEs in any
  602. particular implementation.
  603.  
  604.      An SDSE is analogous to a DSE and consists of:
  605.      ╤  SDSE type (always);
  606.      ╤  user attributes (derived from entry information for DSEs
  607.         corresponding to entries that are to be shadowed);
  608.      ╤  operational attributes (present as required);
  609.      ╤  subordinate-completeness flag (for area and subordinate
  610.         information only);
  611.      ╤  attribute-completeness flag (present for area information
  612.         only).
  613.  
  614. 7.2.1.1 SDSE type
  615.  
  616.      DSE types are defined in CCITT Rec. X.501|ISO/IEC 9594-2.
  617. SDSE type, as specified in 11.3.1.1, is analogous to DSE type, but
  618. has fewer options;  glue, cp, entry, alias, subr, nssr, admPoint,
  619. subEntry and as.
  620.  
  621. 7.2.1.2 Subordinate-completeness flag
  622.  
  623.      The subordinate-completeness flag is a boolean that is present
  624. for SDSEs within the area information and subordinate information.
  625. The flag has the following semantics:
  626.  
  627.      The flag is TRUE if and only if one of the following
  628. conditions is met for a particular SDSE:
  629.      a)it represents a leaf entry;
  630.      b)it contains SDSEs for each subordinate entry or each
  631.         subordinate or non-specific subordinate reference known to
  632.         the master DSA.
  633.  
  634.      The flag is FALSE if one of the following conditions is met
  635. for a particular SDSE:
  636.      a)the subordinates known to the master for that particular
  637.         SDSE are not all present in the shadow information;
  638.      b)it is not determined whether the shadowed information
  639.         contains SDSEs for all subordinates known to the master
  640.         DSA;
  641.      c)the shadow supplier does not intend to provide information
  642.         about subordinate completeness, the default value FALSE is
  643.         used for each SDSE.
  644.  
  645. 7.2.1.3 Attribute-completeness flag
  646.  
  647.      The attribute completeness flag is a boolean and is TRUE if
  648. and only if all user attributes of the entry and all relevant
  649. collective attributes are present  for the SDSE.  It is only
  650. present for SDSEs containing entry information.
  651.  
  652.      The attribute-completeness flag is not used with respect to
  653. directory operational attributes;  it is always assumed that they
  654. are not all present in the SDSE.
  655.  
  656. 7.2.2Establishment of shadowed information
  657.  
  658.      The shadowed information represents three basic types of
  659. information:  prefix information, area information, and subordinate
  660. information.  Each of these is discussed in the following
  661. subclauses.
  662.  
  663. 7.2.2.1 Prefix information
  664.  
  665.      If the replicated area does not start immediately below the
  666. root of the DIT, the shadowed information will include SDSEs for
  667. each entry that is part of the area prefix of the replicated area
  668. (the path down from the root of the DIT to the replication base
  669. entry). Each of these SDSEs will be of type glue  and will only
  670. represent the RDN of the entry, unless it represents an
  671. administrative point containing administrative policy information.
  672. There is an empty SDSE for the root DSE.  There are no subordinate-
  673. completeness flags in area prefix SDSEs.
  674.  
  675. 7.2.2.1.1     Administrative point
  676.  
  677.      If the entry is an administrative point that has attributes
  678. pertaining to the replicated area, or that has one or more
  679. associated subentries whose subtree scope includes some or all of
  680. the replicated area, the SDSE is of type admPoint instead of type
  681. glue. Any attributes that are relevant for the replicated area are
  682. included in the SDSE.  The administrativeRole attribute shall be
  683. included in all administrative point SDSEs which are relevant to
  684. the shadowed information.
  685.  
  686. 7.2.2.1.2     Subentries
  687.  
  688.      For subentries below the administrative point for which the
  689. subtree scope includes some or all of the replicated area,  SDSEs
  690. of type subEntry may be included in the shadowed information.  If
  691. the subtree scope of such a subentry does not include the
  692. replicated area or parts of it, no SDSE for this subentry need be
  693. included.  Collective attributes, schema and access control
  694. information selected for the area information are represented in
  695. SDSEs of type subEntry.
  696.  
  697. 7.2.2.2 Area information
  698.  
  699.      All entries in the shadow supplier information tree that are
  700. included in the replicated area are represented in the shadowed
  701. information as SDSEs of type entry (unless removed by filtering).
  702. This SDSE contains the attributes of the entry as selected by the
  703. attribute selection of the shadowing agreement.  Collective
  704. attributes held in subentries are selected in the same manner as
  705. other attributes and are represented in SDSEs of type subEntry.  If
  706. any attributes of an entry have been selected for inclusion in the
  707. shadow, the objectClass attribute and the relevant entry access
  708. control information will be included in the SDSE for that entry.
  709. The attribute-completeness flag is set to indicate whether all user
  710. attributes in the DSE and all relevant collective attributes are
  711. present for the SDSE.  The collectiveExclusions operational
  712. attribute, if present, is always included in the SDSE.  It is
  713. always assumed that all directory operational attributes are not
  714. present, thus no corresponding flag is provided.
  715.  
  716.      If the DSE is of type admPoint, the corresponding SDSE is of
  717. additional type admPoint and SDSEs of type subEntry for all
  718. relevant subentries immediately subordinate to the administrative
  719. point DSE are included in the shadowed information. The rules for
  720. inclusion of subentries are stated in 7.2.2.1.2.
  721.  
  722.      If the DSE is of type cp, the corresponding SDSE is of
  723. additional type cp.
  724.  
  725.      If filtering has been applied to the replicated area the
  726. resulting shadowed information may no longer be contiguous. There
  727. may be entries that have been removed by filtering that will create
  728. "holes" in the tree structure of the shadowed information. For each
  729. entry that has been removed by filtering the following rules are
  730. applied:
  731.      a)if there are SDSEs subordinate to that entry within the
  732.         shadowed information that are not filtered out, an SDSE for
  733.         the removed entry of type glue is added to the shadowed
  734.         information.  If the shadow supplier DSA supplies
  735.         subordinate completeness information, then the subordinate
  736.         completeness flag is set to TRUE if there are no other
  737.         SDSEs subordinate to that entry that have been filtered
  738.         out, and to FALSE otherwise.  As this SDSE contains no
  739.         entry information, it has no attribute completeness flag;
  740.      b)if there are no other SDSEs subordinate to the entry within
  741.         the shadowed information, the subordinate-completeness flag
  742.         of the SDSE for the entry immediately superior to the
  743.         removed entry is set to FALSE and the SDSE for the removed
  744.         entry is excluded from the shadowed information.
  745.      c)if the DSE is of type admPoint, it is always shadowed and
  746.         the administrativeRole attribute is included.
  747.  
  748.      Each SDSE in area information has a subordinate-completeness
  749. flag.  If all of the subordinates of a given entry  or a reference
  750. to them as known by the master DSA are included in the shadowed
  751. information, the  subordinate-completeness flag of the SDSE is set
  752. to TRUE. Otherwise it is set to FALSE.
  753.  
  754. 7.2.2.3 Subordinate information
  755.  
  756.      The type of subordinate information required (i.e., master
  757. access points, shadow access points, or both;  and whether extended
  758. knowledge is to be included or not) is specified in the shadowing
  759. agreement.
  760.  
  761.      If subordinate knowledge is requested, subordinate references
  762. directly below the replicated area (master, shadow, or both types
  763. of knowledge as appropriate) are included as SDSEs of type subr or
  764. nssr as applicable, complete with the appropriate knowledge.
  765.  
  766.      If extended knowledge is specified, subordinate references
  767. below (but not immediately subordinate to) the replicated area
  768. (master, shadow, or both) are included as SDSEs of type subr or
  769. nssr, complete with the appropriate knowledge.  Subordinate  glue
  770. SDSEs must be inserted to maintain connection with  SDSEs in the
  771. replicated area.  This may create glue SDSEs which are either
  772. within or below the replicated area.  No other glue SDSEs are
  773. provided to support subordinate information.
  774.  
  775.      subr and nssr SDSEs carry a subordinate completeness flag.
  776. glue SDSEs added for the purpose of extended knowledge carry no
  777. subordinate completeness flag and are always assumed to be
  778. incomplete (with respect to subordinate knowledge).
  779.  
  780.      More detailed information on the unit of replication and the
  781. representation of shadowed information is contained in 9.2.
  782.  
  783. 7.3  Shadow operations
  784.  
  785.      Shadowed information is transmitted from the shadow supplier
  786. to the shadow consumer by using directory shadow operations.  These
  787. operations provide for two fundamentally different models for
  788. updating shadowed information:  shadow supplier-initiated shadowing
  789. (a "push" model), and shadow consumer-initiated shadowing (a "pull"
  790. model).  These models are described more fully in clause 10.  In
  791. either model, the information transmitted by protocol takes one of
  792. two forms total (the complete set of information within the
  793. shadowed information is transmitted) or incremental (only changes
  794. to the shadowed information are transmitted).  Each element in
  795. total is an SDSE.  Each element of incremental is an SDSE change.
  796. SDSE changes reflect the net effect of changes that have been made
  797. to the corresponding DSEs in the replicated area since the previous
  798. update, whether these changes originally occurred as a result of
  799. changes to individual DSEs (adds, deletes, etc.) or as a result of
  800. changes to multiple DSEs (e.g., resulting from a ModifyDN
  801. operation).
  802.  
  803.      Three shadow operations have been defined.  The
  804. CoordinateShadowUpdate operation is used in the push model to
  805. enable the shadow supplier to indicate the shadowing agreement  for
  806. which it intends to send an update, to indicate the time the last
  807. update was sent for that agreement, and to indicate the intended
  808. update strategy (e.g., total or incremental).  If a positive result
  809. is received in response to a CoordinateShadowUpdate operation, the
  810. shadow supplier uses the UpdateShadow operation to convey the
  811. shadowed information or the changes in the shadowed information, as
  812. indicated by the update strategy.  For the pull model, the shadow
  813. consumer uses a RequestShadowUpdate operation to indicate the
  814. shadowing agreement  for which it wishes to receive an update, to
  815. indicate the time supplied in the last update for that agreement,
  816. and to indicate the desired update strategy.  If the parameters of
  817. the RequestShadowUpdate operation are acceptable to the shadow
  818. supplier a positive result is sent to the shadow consumer.  The
  819. shadow supplier uses the UpdateShadow operation to convey the
  820. shadowed information or the changes to the shadowed information, as
  821. indicated by the update strategy.  These operations are described
  822. in detail in clause 11.
  823.  
  824. 7.4  DSA Shadow Bind and DSA Shadow Unbind
  825.  
  826.      The DSAShadowBind and DSAShadowUnbind operation, defined in
  827. 7.4.1 and 7.4.2 respectively, are used by a DSA at the beginning
  828. and the end of a particular period of providing shadow updates.
  829.  
  830. 7.4.1DSA Shadow Bind
  831.  
  832.      A DSAShadowBind operation is used at the beginning of a period
  833. of prividing shadows.
  834.  
  835. DSAShadowBind ::= BIND
  836.      ARGUMENT       DirectoryBindArgument
  837.      RESULT         DirectoryBindResult
  838.      BIND-ERROR          DirectoryBindError
  839.  
  840.      The components of the DSAShadowBind are identical to their
  841. counterparts in the DirectoryBind (see CCITT Rec. X.511|ISO/IEC
  842. 9594-3) with the following differences:
  843.      a)The Credentials of the DirectoryBindArgument allows
  844.         information identifying the AE-Title of the initiating DSA
  845.         to be sent to the responding DSA.  The AE-Title must be in
  846.         the form of a Directory Distinguished Name.
  847.      b)The Credentials of the DirectoryBindResult allows
  848.         information identifying the AE-Title of the responding DSA
  849.         to be sent to the initiating DSA.  The AE-Title must be in
  850.         the form of a Directory Distinguished Name.
  851.  
  852. 7.4.2DSA Shadow Unbind
  853.  
  854.      A DSAShadowUnbind operation is used at the end of a period of
  855. providing shadows.
  856.  
  857. DSAShadowUnbind ::= UNBIND
  858.  
  859.  
  860. 8    Shadow operational binding
  861.  
  862.      This clause defines the operational binding type for
  863. shadowing. It uses the elements and mechanisms of the DSA
  864. Operational Framework defined in CCITT Rec. X.501|ISO/IEC 9594-2.
  865.  
  866.      The shadow operational binding type may be used to administer
  867. a shadowing agreement reached between the administrative
  868. authorities of two DSAs.   Otherwise, the administration of such an
  869. agreement is outside the scope of this Specification.  An instance
  870. of this operational binding type creates the environment in which
  871. shadow operations can be carried out between the two DSAs. Each
  872. instance is identified by an OperationalBindingID (AgreementID).
  873. The AgreementID is modified in a ModifyOperationalBinding
  874. operation.
  875.  
  876. 8.1  Shadow operational binding type characteristics
  877.  
  878. 8.1.1Symmetry and roles
  879.  
  880.      The shadow operational binding type is an asymmetrical type of
  881. operational binding. The two roles in a binding of this type are:
  882.      ╤  the role of the shadow supplier (associated with the
  883.         abstract role "A");
  884.      ╤  the role of the shadow consumer (associated with the
  885.         abstract role "B").
  886.  
  887.      A detailed description of these roles is given in CCITT Rec.
  888. X.501|ISO/IEC 9594-2.
  889.  
  890. 8.1.2Agreement
  891.  
  892.      The agreement that has to be exchanged during the
  893. establishment of the shadow operational binding or subsequent
  894. modifications is defined by the ASN.1 type ShadowingAgreementInfo
  895. defined in 9.1.
  896.  
  897. 8.1.3Initiator
  898.  
  899.      The establishment, modification and termination of the shadow
  900. operational binding can be initiated by either the DSA with role
  901. shadow supplier (ROLE-A) or by the DSA with role shadow consumer
  902. (ROLE-B);
  903.  
  904. 8.1.4Establishment parameters
  905.  
  906.      No additional parameters are transferred during the
  907. establishment of the binding.
  908.  
  909. 8.1.5Type identification
  910.  
  911.      The shadow operational binding type is identified by the
  912. object identifier assigned by the application of the OPERATIONAL-
  913. BINDING-TYPE macro in 8.3.
  914.  
  915. 8.2  DSA procedures for operational binding management
  916.  
  917.      A set of operations has been defined for managing operational
  918. bindings.  The use of these operations for management of a shadow
  919. operational binding is described in 8.2.1 to 8.2.3 below.  These
  920. procedures apply to DSAs which support the
  921. directoryOperationalBindingManagementAC, as defined in CCITT Rec.
  922. X.519|ISO/IEC 9594-5.  In the event of a protocol loss while
  923. initiating or terminating a shadowing agreement, the initiator
  924. shall assume the operation did not complete successfully.  No
  925. specific action is required by the responder.  Subsequent
  926. procedures are outside the scope of this Specification.  Procedures
  927. for management of the shadow operational binding for DSAs which do
  928. not support the directoryOperationalBindingManagementAC are outside
  929. the scope of this Specification.
  930.  
  931. 8.2.1Establishment procedure
  932.  
  933.      Once the bilateral agreement has been established (using
  934. procedures outside the scope of this Specification), it is
  935. activated with an EstablishOperationalBinding operation, as defined
  936. in CCITT Rec. X.501|ISO/IEC 9594-2. As arguments to this operation,
  937. the initiating DSA supplies the AgreementID for the instance of the
  938. binding, the role of the initiating DSA for this binding instance
  939. (shadow supplier or shadow consumer), and the
  940. ShadowingAgreementInfo.
  941.  
  942. AgreementID ::=     OperationalBindingID
  943.  
  944.      AgreementID  identifies the shadowing agreement being
  945. established. It shall be unique between the pair of DSAs, and is
  946. used in subsequent operations to identify this agreement.
  947.  
  948.      The values for the parameters in ShadowingAgreementInfo are
  949. simply accepted or rejected; there is no negotiation. The
  950. responding DSA  does not have the option of returning a modified
  951. set of acceptable parameter values.  Assuming a successful outcome
  952. of the request to establish an agreement, the shadow supplier and
  953. shadow consumer have the same information in their shadowing
  954. agreement.
  955.  
  956.      If the EstablishOperationalBinding is successful, the
  957. shadowing agreement becomes active.
  958.  
  959.      Errors returned in response to an EstablishOperationalBinding
  960. operation are interpreted according to the error description in
  961. CCITT Rec. X.501 | ISO/IEC 9594-2.
  962.  
  963. 8.2.2Modification procedure
  964.  
  965.      Modification of the parameters of a shadowing agreement is
  966. agreed as part of the bilateral agreement between the two DSA
  967. Administrative Authorities.  Modification to these parameters
  968. results in a new shadowing agreement being established.  The
  969. parameters of the agreement may be exchanged using a
  970. ModifyOperationalBinding operation.  The DSA Administrative
  971. Authorities should consider the effect of agreement modification on
  972. any secondary shadows prior to the modification operation as these
  973. secondary agreements may be required to be modified, updated or
  974. terminated.
  975.  
  976.      The modification procedure does not allow modification to the
  977. replication base entry.
  978.  
  979.      The arguments to the ModifyOperationalBinding are the
  980. AgreementID for this instance of the binding, the AgreementID for
  981. the binding after the operation has been applied, the role of the
  982. DSA for this binding instance (shadow supplier or shadow consumer),
  983. and the new ShadowingAgreementInfo. The values for the parameters
  984. of the ShadowingAgreementInfo for the modify operation are accepted
  985. or rejected; there is no negotiation.  Assuming a successful
  986. outcome to the request for a modification of the agreement, the
  987. shadow consumer and shadow supplier have the same information in
  988. their shadowing agreement.
  989.  
  990.      After the modification operation the data associated with the
  991. prior agreement remains in the shadow consumer and becomes the
  992. shadowed information for the new agreement.  This does not preclude
  993. the shadow consumer requesting a total refresh.   An update of the
  994. shadowed information may be required to remove  inconsistencies
  995. between prior shadowed data and data required to be shadowed as
  996. specified in the UnitOfReplication associated with the new
  997. agreement.
  998.  
  999.      Errors returned in response to a ModifyOperationalBinding
  1000. operation are interpreted according to the error description in
  1001. CCITT Rec. X.501 | ISO/IEC 9594-2.
  1002.  
  1003. 8.2.3Termination procedure
  1004.  
  1005.      Termination of the operational binding deactivates the
  1006. shadowing agreement.  The termination is accomplished by either the
  1007. shadow supplier or the shadow consumer initiating the
  1008. TerminateOperationalBinding operation as specified in CCITT Rec.
  1009. X.501|ISO/IEC 9594-2.  Conditions may have been specified as part
  1010. of the bilateral agreement regarding subsequent treatment of the
  1011. data upon termination, such as the removal of the shadowed
  1012. information from the shadow consumer DSA within a specified time.
  1013. Such conditions take effect upon termination.  In the event that a
  1014. shadowing agreement  is terminated, the shadow consumer shall
  1015. terminate any secondary shadowing agreements dependent on
  1016. information in the shadowing agreement in question.  The
  1017. termination of secondary shadowing agreements is decoupled from the
  1018. original TerminateOperationalBinding operation.
  1019.  
  1020.      If the TerminateOperationalBinding is successful, the
  1021. shadowing agreement ceases.
  1022.  
  1023.      Errors returned in response to a TerminateOperationalBinding
  1024. operation are interpreted according to the error description in
  1025. CCITT Rec. X.501 | ISO/IEC 9594-2.
  1026.  
  1027. 8.2.4Operations and procedures
  1028.  
  1029.      The operations that can be executed in the active state of a
  1030. shadow operational binding are those defined within the
  1031. shadowConsumerInitiatedAC, shadowSupplierInitiatedAC,
  1032. reliableShadowConsumerInitiatedAC and
  1033. reliableShadowSupplierInitiatedAC application contexts defined in
  1034. CCITT Rec. X.519|ISO/IEC 9594-5 :
  1035.      ╤  updateShadow  operation
  1036.      ╤  requestShadowUpdate  operation
  1037.      ╤  coordinateShadowUpdate  operation
  1038.  
  1039.      These operations are defined in clause 11.  The associated
  1040. service is defined in clause╩10.
  1041.  
  1042. 8.3  Type definition
  1043.  
  1044.      This subclause defines the shadow operational binding type
  1045. using the OPERATIONAL-BINDING-TYPE macro defined in  CCITT Rec.
  1046. X.501|ISO/IEC 9594-2.
  1047.  
  1048.      shadowOperationalBinding  OPERATIONAL-BINDING-TYPE
  1049.         AGREEMENT   ShadowingAgreementInfo
  1050.         APPLICATION CONTEXTS
  1051.            ShadowSupplierInitiatedAC APPLIES TO ALL OPERATIONS
  1052.            ShadowConsumerInitiatedAC APPLIES TO ALL OPERATIONS
  1053.            ReliableShadowSupplierInitiatedAC APPLIES TO ALL
  1054. OPERATIONS
  1055.            ReliableShadowConsumerInitiatedAC APPLIES TO ALL
  1056. OPERATIONS
  1057.         ASYMMETRIC
  1058.            ROLE-A   -- shadow supplier role
  1059.              ESTABLISHMENT-INITIATOR
  1060.              MODIFICATION-INITIATOR
  1061.              TERMINATION-INITIATOR
  1062.            ROLE-B   -- shadow consumer role
  1063.              ESTABLISHMENT-INITIATOR
  1064.              MODIFICATION-INITIATOR
  1065.              TERMINATION-INITIATOR
  1066.         ::= { operationalBinding 1}
  1067.  
  1068.      The type ShadowingAgreementInfo is defined in 9.1.
  1069.  
  1070.  
  1071. 9    Shadowing agreement
  1072.  
  1073.      Before shadowing takes place between two DSAs, a bilateral
  1074. agreement is established by an offline administrative process.
  1075. Such an agreement may be explicitly established by the
  1076. Administrative Authorities of the two DSAs for each individual
  1077. shadowing agreement.  Typically such explicit bilateral agreements
  1078. may be required where the two DSAs are in different Directory
  1079. management domains.  Alternatively a general agreement may be
  1080. established which implicitly covers all shadowing agreements among
  1081. a set of DSAs.  Typically such implicit bilateral agreements may be
  1082. applicable to shadowing agreements between pairs of DSAs within a
  1083. single Directory management domain.
  1084.  
  1085.      In addition to the parameters of a shadowing agreement (see
  1086. below) this bilateral agreement may include policy conditions for
  1087. the treatment of the data upon termination of the agreement, such
  1088. as for the removal of shadowed information upon termination (or
  1089. modification) of the shadowing agreement itself..  Administrative
  1090. Authorities also need to consider factors affecting
  1091. interoperability, such as use of RTSE or ROSE ASEs, when
  1092. establishing agreements.
  1093.  
  1094.      A shadowing agreement is required before shadowed information
  1095. may be shared between any pair of DSAs.  This establishes the
  1096. technical parameters of the agreement, specifying update frequency,
  1097. replicated area and information to be shadowed.  This shadowing
  1098. agreement may be a representation of some of the technical
  1099. components of the bilateral agreement between the two DSA
  1100. Administrative Authorities.
  1101.  
  1102.      The shadowing agreement may be activated by its inclusion in
  1103. an EstablishOperationalBinding operation (as outlined in 8.2.1) or
  1104. by means outside the scope of this Specification.  In addition a
  1105. shadowing agreement may be modified through a
  1106. ModifyOperationalBinding operation (as outlined in 8.2.2).  No
  1107. negotiation of parameters of the agreement is supported by the
  1108. operational binding management protocol.  The parameters are either
  1109. accepted or rejected.
  1110.  
  1111.  
  1112. 9.1  Shadowing  agreement specification
  1113.  
  1114.      The shadowing agreement is specified as:
  1115.  
  1116.      ShadowingAgreement ::=   ShadowingAgreementInfo
  1117.  
  1118.      ShadowingAgreementInfo ::= SEQUENCE {
  1119.         shadowSubject      UnitOfReplication,
  1120.         updateMode    UpdateMode,
  1121.         master             AccessPoint  OPTIONAL,
  1122.         completeSubentry      BOOLEAN DEFAULT TRUE }
  1123.  
  1124.      shadowSubject specifies the subtree, entries and attributes to
  1125. shadow.  The components of the UnitOfReplication are defined in
  1126. 9.2.
  1127.  
  1128.      updateMode  specifies when updates of a shadowed area are
  1129. scheduled to occur.  The components of UpdateMode are defined in
  1130. 9.3.
  1131.  
  1132.      master contains the access point of the DSA containing the
  1133. mastered area.  This element is optional and need only be supplied
  1134. for optimization purposes.
  1135.  
  1136.      completeSubentry, if set to TRUE, indicates that the shadow
  1137. supplier shall always supply a complete copy for each subentry
  1138. which has changed within the shadowed information.  If a subentry
  1139. within the shadowed information requires updating, the shadow
  1140. supplier provides a total replacement of the changed subentry
  1141. employing the replace option within ContentChange of SDSEChanges.
  1142.  
  1143. 9.2  Unit of replication
  1144.  
  1145.      This subclause describes how portions of the DIT can be
  1146. replicated, by defining the granularity of the DIT information that
  1147. can be shadowed.  The unit of replication is defined within the
  1148. Directory information model and a specification mechanism is
  1149. provided.   The shadowing mechanism in the Directory is based on
  1150. the definition of the subset of the DIT that will be shadowed. This
  1151. subset is called unit of replication.
  1152.  
  1153.      Because shadowing in the Directory is only defined between
  1154. pairs of DSAs, there is a constraint that the shadowed information
  1155. shall be completely within a single DSA.  The specification of the
  1156. unit of replication may extend beyond a naming context, but the
  1157. replicated area is limited to the naming context.
  1158.  
  1159.      The unit of replication comprises a three-part specification
  1160. which defines the scope of the DIT to be replicated, the attributes
  1161. to be replicated within that scope, and the requirements for
  1162. subordinate knowledge.  The unit of replication also implicitly
  1163. causes the shadowed information to include policy information in
  1164. the form of operational attributes held in entries and subentries
  1165. (e.g., access control information) which is to be used to govern
  1166. access to the shadowed information.  The information to be included
  1167. begins at an autonomous administrative point and extends to the
  1168. replication base entry.
  1169.  
  1170.      The unit of replication is specified as:
  1171.  
  1172.      UnitOfReplication  ::=       SEQUENCE   {
  1173.         area             AreaSpecification,
  1174.         attributes       AttributeSelection,
  1175.         knowledge    Knowledge OPTIONAL }
  1176.  
  1177.      AreaSpecification ::= SEQUENCE {
  1178.         contextPrefix    DistinguishedName,
  1179.         replicationArea  SubtreeSpecification }
  1180.  
  1181.      Knowledge  ::=  SEQUENCE {
  1182.         knowledgeType    ENUMERATED {
  1183.                           master   (0),
  1184.                           shadow   (1),
  1185.                           both  (2) },
  1186.      extendedKnowledge   BOOLEAN DEFAULT FALSE }
  1187.  
  1188.      area defines the replicated area.  It includes the context
  1189. prefix of the naming context for the replicated area and the
  1190. subtree specification relative to that context prefix.
  1191. SubtreeSpecification is defined in  CCITT Rec. X.501|ISO/IEC 9594-
  1192. 2.
  1193.  
  1194.      attributes defines the set of attributes to be shadowed.  It
  1195. includes specification of user attributes (including collective
  1196. attributes) and operational attributes, as described in 9.2.2.
  1197.  
  1198.      knowledge defines the knowledge  references to be shadowed.
  1199. It includes specification  of the type of references
  1200. (master/shadow) to be shadowed as well as whether the knowledge
  1201. requested is extended knowledge.
  1202.  
  1203.      master indicates that only references to master naming
  1204. contexts are to be supplied.
  1205.  
  1206.      shadow indicates that only references to shadowed naming
  1207. contexts are to be supplied.
  1208.  
  1209.      both indicates that references to both master and shadowed
  1210. naming contexts are to be supplied.
  1211.  
  1212.      If extendedKnowledge is specified,  then all subordinate and
  1213. non-specific subordinate references of the naming context, which
  1214. are subordinate to the area prefix are included in the unit of
  1215. replication.  To achieve this glue SDSEs are included in the
  1216. shadowed area to represent all entries between the lower boundary
  1217. of the replicated area and the subordinate knowledge references.
  1218.  
  1219.      The following subclauses define the components of the unit of
  1220. replication in detail.  Support, by a shadow supplier DSA, for
  1221. various components is optional as specified in 9.3.1 of X.519 9594-
  1222. 5.
  1223.  
  1224. 9.2.1Area specification
  1225.  
  1226.      The replicated area is specified by defining a subtree of the
  1227. DIT and refining that subtree to exclude those portions not
  1228. required.  The refinements include a filtering of entries and
  1229. subentries, based on their object or subentry class.  These stages
  1230. are described in 9.2.1.1 and 9.2.1.2.
  1231.  
  1232. 9.2.1.1 Subtree boundary specification
  1233.  
  1234.      The first stage is to specify the shape of the subtree that is
  1235. to be shadowed within a DSA. This is done by  drawing the boundary
  1236. of the subtree based on the tree structure using the subtree
  1237. specification mechanism as defined in CCITT Rec. X.501|ISO/IEC 9594-
  1238. 2.  The component base of SubtreeSpecification is used to provide
  1239. the replication base entry of the unit of replication relative to
  1240. an appropriate context prefix.  The chop component of
  1241. SubtreeSpecification is used to define the lower boundary of the
  1242. subtree that is to be shadowed. The entries that can be referenced
  1243. by either the exclusions or the maximum component are limited to
  1244. the lower boundary of the naming context holding the replication
  1245. base entry. If the chop component is absent, the unit of
  1246. replication includes the whole subtree starting with the base and
  1247. proceeding down to the lower boundary of the naming context.
  1248.  
  1249. 9.2.1.2 Subtree refinement
  1250.  
  1251.      The next stage of refinement is to apply a filter to the
  1252. selected subtree.  The specification-filter component of
  1253. SubtreeSpecification is used to specify the filter.  Filtering is
  1254. done on object class or subentry class (only).
  1255.  
  1256.      Filtering may result in a unit of replication that is no
  1257. longer a connected subtree in the DSA, from the viewpoint of the
  1258. Directory Information Model.  For such subtrees glue DSEs are
  1259. required to be supplied for as many entries as are needed to build
  1260. a connected subtree in the shadow consumer.
  1261.  
  1262. 9.2.2Attribute selection
  1263.  
  1264.      This further stage of refinement of the unit of replication
  1265. specifies the attributes (user, collective and Directory
  1266. operational) to be shadowed.
  1267.  
  1268.      In addition to those specified here, access control
  1269. operational attributes and modification timestamps are always
  1270. included in a unit of replication.  Also, if knowledge is specified
  1271. (as defined in 9.2.3) the knowledge operational attributes will be
  1272. included in the shadowed information and need not be enumerated as
  1273. part of this attribute selection.
  1274.  
  1275.      The attribute selection shall be specified to reflect, if at
  1276. all possible, any restrictions on shadow consumer access to the
  1277. information.  However it is possible that some security policies
  1278. may cause very limited exceptions to this norm where particular
  1279. information is withheld from the shadowed information.
  1280.  
  1281.      AttributeSelection  ::=  SET OF ClassAttributeSelection
  1282.  
  1283.      ClassAttributeSelection  ::=  SEQUENCE {
  1284.         class            OBJECT IDENTIFIER OPTIONAL,
  1285.         classAttributes  ClassAttributes }
  1286.  
  1287.      ClassAttributes  ::= CHOICE {
  1288.         allAttributes         NULL,
  1289.         include     [0]  AttributeTypes,
  1290.         exclude     [1]  AttributeTypes
  1291.                     }    DEFAULT allAttributes  NULL
  1292.  
  1293.      AttributeTypes ::=  SET OF AttributeType
  1294.  
  1295.      Each element of AttributeSelection is a
  1296. ClassAttributeSelection, and specifies the attributes for objects
  1297. of the indicated class.  The class may be an object class (for
  1298. entries) or a subentry class.  Specification of attributes for an
  1299. object superclass also applies to any subclasses of the named
  1300. class.  If the class is omitted, the selection applies to all
  1301. classes.
  1302.  
  1303.      The default allAttributes specifies that all user attributes
  1304. (including collective attributes) are to be included.  If there are
  1305. relevant collective attributes associated with the class, the
  1306. appropriate collectiveAttributeArea subentries are implicitly
  1307. included.  If any directory operational attributes (other than
  1308. access control, timestamps and knowledge) are to be included, they
  1309. must be identified in the include element of the specification.
  1310.  
  1311.      Attributes are implicitly included in the case where
  1312. allAttributes is specified.  In addition, when using the exclude
  1313. specification, any attributes contained in an entry  which are not
  1314. explicitly excluded are implicitly included.  The specification of
  1315. an attribute supertype implicitly includes any subtypes of that
  1316. attribute.
  1317.  
  1318.      Explicit include or exclude of a collective attribute for a
  1319. particular class results in the corresponding inclusion or
  1320. exclusion of the corresponding collectiveAttributeArea subentries.
  1321.  
  1322.      Where entries belong to more than one of the specified
  1323. classes, the specifications are cumulative.  In the case of
  1324. conflicting specifications include has priority over explicitly
  1325. excluded attributes and exclude has priority over implicitly
  1326. included attributes.
  1327.  
  1328. 9.2.3Subordinate knowledge
  1329.  
  1330.      The next stage in defining the unit of replication is the
  1331. inclusion of subordinate knowledge.  This knowledge may include
  1332. subordinate knowledge of either master or shadowed naming contexts
  1333. and may include specific or non-specific references.  Additionally,
  1334. such subordinate knowledge references may be included in the unit
  1335. of replication, even if they are not immediately subordinate to
  1336. entries in the replicated area, in which case they are referred to
  1337. as extendedKnowledge references.
  1338.  
  1339. 9.2.4Subentries
  1340.  
  1341.      Subentries are included in the unit of replication for access
  1342. control, schema and collective entries as described below.
  1343.  
  1344. 9.2.4.1 Access control information
  1345.  
  1346.      It is the responsibility of the shadow supplier to provide
  1347. properly transformed access control information for each item in
  1348. the unit of replication.  The nature of the transformation is
  1349. specified as part of the shadowing agreement and may be as simple
  1350. as the identity transformation.
  1351.  
  1352.      Note╤For example, the transformation may reflect a local
  1353. policy that states it is not necessary to shadow permission related
  1354. to controlling modification of the shadowed items.  Such a policy
  1355. is consistent with the read-only nature of shadowed information.
  1356.  
  1357.      The following access control information shall always be
  1358. shadowed:
  1359.      a)prescriptive access controls relevant to the reading of the
  1360.         replicated information and found in access-control-specific
  1361.         or inner points within the replicated area up to and
  1362.         including the first access-control-specific or autonomous
  1363.         administrative point encountered proceeding from the area
  1364.         prefix towards the root;
  1365.      b)entry access controls relevant to the reading of each entry
  1366.         shadowed.
  1367.  
  1368.      The shadow consumer shall enforce access control using the
  1369. shadowed access control information.
  1370.  
  1371.      Note╤It is desirable that changes in access control policy, as
  1372. expressed by prescriptive ACI, should be propagated to shadowing
  1373. DSAs (and other DSAs) as soon as possible.  Such changes may cause
  1374. (for example) the initiation of a (normal) incremental refresh
  1375. exchange to affected DSAs, without regard for any particular
  1376. periodic strategy.  The refresh would include (for consistency) any
  1377. other updates pending to the unit of replication.  A similar
  1378. consideration may apply to group-of-unique-name updates when these
  1379. updates affect access control.
  1380.  
  1381. 9.2.4.2 Schema information
  1382.  
  1383.      The schema information required by a shadow consumer to
  1384. accommodate the shadowed information in its DSA Information Tree
  1385. and to satisfy Directory query operations on that shadowed
  1386. information, needs to be shadowed as part of the unit of
  1387. replication.
  1388.  
  1389.      The relevant operational attributes of the subschema subentry
  1390. are specified for that class in the AttributeSelection component of
  1391. the UnitOfReplication specification.
  1392.  
  1393. 9.2.4.3 Entry collection information
  1394.  
  1395.      Collective attributes are included in/excluded from the unit
  1396. of replication as user attributes.  If allAttributes is specified,
  1397. all corresponding collectiveAttributeArea subentries are implicitly
  1398. included in the unit of replication.  If user attributes explicitly
  1399. included in the unit of replication are collective attributes the
  1400. corresponding attributes of the collectiveAttributeArea are
  1401. included in the unit of replication.
  1402.  
  1403. 9.2.5Overlapping replicated areas
  1404.  
  1405.      A shadow consumer may optionally be involved in two or more
  1406. shadowing agreements specifying overlapping replicated areas.  The
  1407. procedures to be followed by DSAs that do not support overlapping
  1408. replicated areas are defined in 9.2.5.1.  The procedures to be
  1409. followed by DSAs that support overlapping replicated areas are
  1410. defined in 9.2.5.2.
  1411.  
  1412.      To support overlapping replicated areas and overlapping
  1413. subentry information in the shadow consumer the createTimestamp and
  1414. modifyTimestamp shall be provided by the shadow supplier in the
  1415. shadow information (entries and subentries).  The createTimestamp
  1416. shall be conveyed in the SDSEContent during a total refresh or if a
  1417. new shadow DSE is added.  The modifyTimestamp shall always be
  1418. conveyed in the SDSEContent if present in the shadow supplier╒s DSE
  1419. for that entry or subentry.
  1420.  
  1421. 9.2.5.1 Procedures for DSAs not supporting overlapping replicated
  1422.       areas
  1423.  
  1424.      This clause defines the procedures to be followed by shadow
  1425. consumers that do not support overlapping replicated areas.
  1426.  
  1427.      A shadow consumer shall not engage in two or more shadowing
  1428. agreements whose UnitOfReplication specifies overlapping replicated
  1429. areas.  However, the shadow consumer may encounter cases where non-
  1430. overlapping replicated areas share the same area prefix, resulting
  1431. in overlapping area prefix SDSEs.  Thus, any subentry SDSEs within
  1432. an area prefix may be subject to separate (uncoordinated) updates
  1433. from different shadowing agreements.  Changes in subentries (such
  1434. as prescriptive access control information) need to be associated
  1435. with particular data and updates reflecting such changes will only
  1436. be sent for relevant shadowing agreements.  Subentries for
  1437. shadowing agreements which share an area prefix need to be
  1438. logically maintained separately and associated with the appropriate
  1439. replicated area.
  1440.  
  1441. 9.2.5.2 Procedures for DSAs supporting overlapping replicated areas
  1442.  
  1443.      This clause defines the procedures to be followed by shadow
  1444. consumers that support overlapping replicated areas.
  1445.  
  1446.      Each replicated area (associated with a shadowing agreement)
  1447. shall be represented in the shadow consumer by a separate
  1448. ╥information plane.╙  When the shadowed information associated with
  1449. a shadowing agreement is updated, only the ╥information plane╙ that
  1450. represents that shadowed information shall be affected.
  1451.  
  1452.      When performing a Directory interrogation operation on a given
  1453. replicated area, a shadow consumer shall do one of the following:
  1454.      a)select an "information plane" that is capable of satisfying
  1455.         the specified Directory operation. The procedure used to
  1456.         select the appropriate ╥information plane╙ is outside the
  1457.         scope of this Specification. Once an appropriate
  1458.         "information plane" is found, only the shadow DSEs
  1459.         contained in that "plane" are considered during the
  1460.         execution of the Directory operation, i.e., information
  1461.         contained in other "information planes" is ignored;
  1462.      b)consider the aggregate of shadowed information the shadow
  1463.         consumer holds for the relevant replicated area by merging
  1464.         the shadow DSEs from different "information planes"into one
  1465.         single set of shadow DSEs, one for each replicated entry.
  1466.         If the resulting shadowed information is capable of
  1467.         satisfying the Directory operation, execute the latter on
  1468.         the resulting set of shadow DSEs.
  1469.  
  1470. Note╤A shadow DSE resulting from the union of all shadow DSEs
  1471. representing a given replicated entry should contain the most
  1472. current shadowed information from the set of all applicable
  1473. "information planes".
  1474.  
  1475. 9.3  Update mode
  1476.  
  1477.      The updateMode argument in the shadowing agreement specifies
  1478. when updates are expected to occur for shadowed information.
  1479.  
  1480.      UpdateMode  ::=CHOICE    {
  1481.            supplierInitiated  [0]  SupplierUpdateMode,
  1482.            consumerInitiated       [1]  ConsumerUpdateMode  }
  1483.  
  1484.      SupplierUpdateMode ::=   CHOICE    {
  1485.            onChange  BOOLEAN DEFAULT TRUE,
  1486.            scheduled SchedulingParameters    }
  1487.  
  1488.      ConsumerUpdateMode    ::=     SchedulingParameters
  1489.  
  1490.      The components of updateMode are defined in 9.3.1 through
  1491. 9.3.3.
  1492.  
  1493.      For each shadowing agreement, a choice has to be made between
  1494. the shadow supplier or shadow consumer initiating the update.  This
  1495. is specified by selecting supplierInitiated or consumerInitiated.
  1496. This choice does not preclude either party in a shadowing agreement
  1497. from initiating (or attempting to initiate) an update at times
  1498. outside those specified by the UpdateMode.
  1499.  
  1500. 9.3.1Supplier update mode
  1501.  
  1502.      In SupplierUpdateMode, onChange indicates that the shadow
  1503. supplier is expected to provide updates when changes occur within
  1504. the shadowed information as specified by the unit of replication.
  1505. Should the shadow consumer be unavailable, the shadow supplier
  1506. shall resend the update within an appropriate, locally-defined,
  1507. time period. If, due to the unavailability of the shadow consumer,
  1508. a number of changes are outstanding, the shadow supplier may
  1509. transmit them within one single UpdateShadow operation.
  1510.  
  1511.      scheduled allows updates from the shadow supplier to be
  1512. scheduled as specified by SchedulingParameters.
  1513.  
  1514. 9.3.2Consumer update mode
  1515.  
  1516.      In ConsumerUpdateMode the scheduling of the update requests is
  1517. as specified by the SchedulingParameters.
  1518.  
  1519. 9.3.3Scheduling parameters
  1520.  
  1521.      The SchedulingParameters provide the information required to
  1522. schedule the requests for updates.
  1523.  
  1524.      SchedulingParameters ::= SEQUENCE   {
  1525.         periodic    PeriodicStrategy    OPTIONAL,
  1526.            -- must be present if othertimes is set to FALSE --
  1527.         othertimes  BOOLEAN DEFAULT FALSE    }
  1528.  
  1529.      Scheduling can be based on a periodic basis (periodic), an
  1530. exception basis (othertimes) or a combination of both.
  1531.  
  1532.      If present, periodic indicates that update windows are
  1533. expected to occur on a regular basis. PeriodicStrategy is used to
  1534. specify the windows by providing a start time of the first window,
  1535. the size of each window and the amount of time between windows.
  1536. These parameters provide guidance as to when updates are expected
  1537. to occur, however updates may also be attempted, for a number of
  1538. reasons, outside the windows specified.
  1539.  
  1540.      PeriodicStrategy ::= SEQUENCE {
  1541.         beginTime       Time OPTIONAL,
  1542.         windowSize      INTEGER,
  1543.         frequencyOfUpdate     INTEGER   }
  1544.  
  1545.      Time  ::=  GeneralizedTime  -- per 30.3 b) of Recommendation
  1546. X.208|ISO 8824--
  1547.  
  1548.      beginTime specifies the start time of the first window.
  1549.  
  1550.      windowSize is the length of the update window in minutes.
  1551.  
  1552.      frequencyOfUpdate is the period between update windows in
  1553. minutes.
  1554.  
  1555.      If beginTime is not specified, the update strategy starts at
  1556. the time the shadowing agreement is activated.
  1557.  
  1558.      othertimes  indicates that updates can be scheduled according
  1559. to local requirements. When this is set as part of the shadowing
  1560. agreement, then the shadow supplier may include the updateWindow
  1561. parameter during shadow update operations to signal the window for
  1562. the next expected update.
  1563.  
  1564.      If periodic is present and othertimes is TRUE the window
  1565. selected via othertimes has precedence over those specified in
  1566. PeriodicStrategy (e.g. if othertimes calls for a later time than
  1567. the next periodic update according to the periodic strategy, the
  1568. periodic update strategy time is ignored).
  1569.  
  1570.  
  1571. 10   Directory information shadow service
  1572.  
  1573.      The directory information shadow service defined here provides
  1574. the Directory with a mechanism to provide and support replicated
  1575. information.  The use of shadowed information to satisfy Directory
  1576. requests is described in CCITT Rec. X.518|ISO/IEC 9594-4.
  1577.  
  1578.      Once a shadowing agreement has been activated, shadowing may
  1579. take place in the form of updates by using abstract operations of
  1580. the Directory Information Shadowing Protocol (DISP).  Three
  1581. distinct operations are available:  CoordinateShadowUpdate,
  1582. UpdateShadow,  and RequestShadowUpdate. Descriptions of how these
  1583. operations are used for shadow supplier initiated update and for
  1584. shadow consumer initiated update are provided in 10.1 and 10.2
  1585. below.  In both cases the updates for a particular agreement are
  1586. sent in a single operation.  The operations themselves are defined
  1587. in clause 11 and the associated errors in clause 12.
  1588.  
  1589. 10.1 Shadow supplier initiated service
  1590.  
  1591.      This subclause describes shadow supplier initiated update
  1592. using the CoordinateShadowUpdate and UpdateShadow operations.  The
  1593. CoordinateShadowUpdate operation, invoked by the shadow supplier,
  1594. identifies the shadowing agreement for which the shadow supplier
  1595. intends to send an update.
  1596.  
  1597.      Upon receipt of a positive acknowledgement, the shadow
  1598. supplier sends the update for the shadowing agreement by using the
  1599. UpdateShadow operation.
  1600.  
  1601.      Otherwise the shadow supplier responds with a ShadowError.
  1602. The circumstances under which particular errors will be returned
  1603. are defined in clause 12.
  1604.  
  1605.      Although the CoordinateShadowUpdate operation applies to only
  1606. a single shadowing agreement, several shadowing agreements can be
  1607. updated within a single application association.  For any one
  1608. shadowing agreement, the CoordinateShadowUpdate operation (request
  1609. and result) must precede the UpdateShadow operation.  Only one
  1610. instance of the UpdateShadow operation can be invoked per
  1611. CoordinateShadowUpdate instance.  For any one shadowing agreement,
  1612. there can only be a single CoordinateShadowUpdate operation for
  1613. which the response and UpdateShadow operation are outstanding at
  1614. any one time.
  1615.  
  1616.      Under certain circumstances, a failure of underlying services
  1617. may be detected by the shadow supplier and/or shadow consumer
  1618. (e.g., as a result of a RO-REJECT-P or provider abort).  If such an
  1619. indication is received at any point prior to receipt of a positive
  1620. response to the UpdateShadow operation, the shadow supplier shall
  1621. assume that the combination of CoordinateShadowUpdate and
  1622. UpdateShadow failed .  If the shadow consumer receives such an
  1623. indication at any point prior to responding to the UpdateShadow
  1624. operation, the shadow consumer shall also assume that the entire
  1625. combination failed.  Assuming such a failure the shadow consumer,
  1626. upon receipt of another CoordinateShadowUpdate operation for this
  1627. shadowing agreement shall disregard any previously outstanding
  1628. CoordinateShadowUpdate rather than return an error.  Procedures for
  1629. recovery are outside the scope of this Specification.
  1630.  
  1631. 10.2 Shadow consumer initiated service
  1632.  
  1633.      This clause describes shadow consumer initiated update using
  1634. the RequestShadowUpdate and UpdateShadow operations.  The
  1635. RequestShadowUpdate operation, invoked by the shadow consumer,
  1636. identifies the shadowing agreement for which the shadow consumer
  1637. wishes to receive an update.
  1638.  
  1639.      If the parameters in the RequestShadowUpdateArgument are
  1640. acceptable to the shadow supplier, a result will be returned
  1641. although no information will be conveyed with it.  The shadow
  1642. supplier sends the update for the shadowing agreement using the
  1643. UpdateShadow operation.
  1644.  
  1645.      Otherwise the shadow supplier responds with a ShadowError.
  1646. The circumstances under which particular errors will be returned
  1647. are defined in clause 12.
  1648.  
  1649.      Although the RequestShadowUpdate operation applies to only a
  1650. single shadowing agreement, several shadowing agreements can be
  1651. updated within a single application association.  For any one
  1652. shadowing agreement the RequestShadowUpdate operation (request and
  1653. result) must precede the UpdateShadow operation.  Only one instance
  1654. of the UpdateShadow operation can be invoked per
  1655. RequestShadowUpdate instance.  For any one shadowing agreement
  1656. there can only be a single RequestShadowUpdate operation for which
  1657. the response and UpdateShadow operation are outstanding at any one
  1658. time.
  1659.  
  1660.      Under certain circumstances, a failure of underlying services
  1661. may be detected by the shadow supplier and/or shadow consumer
  1662. (e.g., as a result of a RO-REJECT-P or provider abort).  If such an
  1663. indication is received at any point prior to receipt of a positive
  1664. response to theUpdateShadow operation, the shadow supplier shall
  1665. assume that the combination of RequestShadowUpdate and UpdateShadow
  1666. failed .  If the shadow consumer receives such an indication at any
  1667. point porior to responding to the UpdateShadow operation, the
  1668. shadow consumer shall also assume that the entire combination
  1669. failed.  Assuming such a failure the shadow supplier, upon receipt
  1670. of another RequestShadowUpdate operation for this shadowing
  1671. agreement shall disregard any previously outstanding
  1672. RequestShadowUpdate rather than return an error.   Procedures for
  1673. recovery are outside the scope of this Specification.
  1674.  
  1675.  
  1676. 11   Shadow operations
  1677.  
  1678.      The operations of the Directory Information Shadowing Protocol
  1679. (DISP), used by shadow suppliers and shadow consumers to realize
  1680. the directory information shadow service described in clause 10,
  1681. are defined in 11.1 through 11.3.  The associated errors are
  1682. defined in clause 12.
  1683.  
  1684. 11.1 Coordinate Shadow Update operation
  1685.  
  1686.      The CoordinateShadowUpdate operation is used by the shadow
  1687. supplier to indicate the shadowing agreement for which it intends
  1688. to send updates.
  1689.  
  1690.      CoordinateShadowUpdate ::= OPERATION
  1691.         ARGUMENT    CoordinateShadowUpdateArgument
  1692.         RESULT           CoordinateShadowUpdateResult
  1693.         ERRORS           ShadowError
  1694.  
  1695.      CoordinateShadowUpdateArgument ::=  SEQUENCE {
  1696.         agreementID AgreementID,
  1697.         lastUpdate       Time,
  1698.         updateStrategy   CHOICE {
  1699.                         standard   ENUMERATED {
  1700.                                    noChanges (0),
  1701.                                    incremental    (1),
  1702.                                    total          (2)  },
  1703.                         other EXTERNAL  }  }
  1704.  
  1705.      CoordinateShadowUpdateResult ::= NULL
  1706.  
  1707. 11.1.1        Coordinate Shadow Update Parameters
  1708.  
  1709.      The various parameters have the meanings defined below:
  1710.  
  1711.      The agreementID argument identifies the shadowing agreement as
  1712. defined in 9.1.
  1713.  
  1714.      The lastUpdate argument indicates the shadow supplier's
  1715. understanding of the time at which the last update for this
  1716. agreement was sent and is the time as provided by the shadow
  1717. supplier DSA.
  1718.  
  1719.      The updateStrategy argument identifies the update strategy the
  1720. shadow supplier intends to use for this update.  Within the choice
  1721. of standard, the shadow supplier may select  noChanges (indicating
  1722. no modifications to the shadowed information), incremental
  1723. (indicating incremental changes), or total (indicating a complete
  1724. replacement of the unit of replication).
  1725.  
  1726.      The option noChanges should only be used when the shadow
  1727. supplier wishes to inform the shadow consumer that no modifications
  1728. have occurred to the replicated area since the last update (e.g. in
  1729. the case where a regularly scheduled update is expected).  This
  1730. shall be followed by an UpdateShadow operation with
  1731. RefreshInformation set to noRefresh.
  1732.  
  1733. 11.1.2        Coordinate Shadow Update success
  1734.  
  1735.      Should the  request succeed, a result will be returned,
  1736. although no information will be conveyed with it.
  1737.  
  1738. 11.1.3        Coordinate Shadow Update  failure
  1739.  
  1740.      Should the  request fail,  a ShadowError shall be reported.
  1741. Circumstances under which the particular shadow problems will be
  1742. returned are defined below.
  1743.  
  1744.      An invalidAgreementID shadow problem is returned if the shadow
  1745. consumer DSA does not recognize the AgreementID specified within
  1746. the set of AgreementIDs with this shadow supplier DSA.
  1747.  
  1748.      An inactiveAgreement shadow problem is returned if the shadow
  1749. consumer DSA recognizes the AgreementID as a valid AgreementID for
  1750. this shadow supplier DSA, but the shadow consumer DSA understands
  1751. that the AgreementID is inactive.
  1752.  
  1753.      An unsupportedStrategy  shadow problem is returned if the
  1754. shadow consumer DSA does not support the refresh strategy selected
  1755. by the shadow supplier DSA  for this shadowing agreement.
  1756.  
  1757.      A missedPrevious  shadow problem is returned if the shadow
  1758. consumer DSA╒s understanding of the time of last update is earlier
  1759. than the time indicated by the value received in lastUpdate.
  1760.  
  1761.      A fullUpdateRequired shadow problem is returned by the shadow
  1762. consumer DSA to inform the shadow supplier that a total refresh is
  1763. required to bring the shadow consumer DSA into a state of
  1764. consistency with the shadow supplier.  This could be returned, for
  1765. instance, if the shadow consumer DSA is recovering from a major
  1766. failure and does not currently understand its state of consistency
  1767. with respect to the shadow supplier.
  1768.  
  1769.      An unwillingToPerform shadow problem is returned by the shadow
  1770. consumer DSA to indicate that it is unwilling to perform the update
  1771. operation associated with this coordinate operation.
  1772. Interpretation of this shadow problem is outside the scope of this
  1773. Specification.
  1774.  
  1775.      An unsuitableTiming shadow problem is returned if the shadow
  1776. consumer DSA is unwilling to perform the update associated with
  1777. this operation at this time.
  1778.  
  1779.      An updateAlreadyReceived shadow problem is returned if the
  1780. shadow consumer DSA╒s understanding of the time of last update is
  1781. later than the time indicated by the value received in lastUpdate.
  1782.  
  1783.      The invalidInformationReceived shadow problem is not returned
  1784. in response to this operation.
  1785.  
  1786.      An invalidSequencing shadow problem is returned to signal the
  1787. receopt of multiple consecutive CoordinateShadowUpdate requests for
  1788. a single shadowing agreement without completing an intervening
  1789. UpdateShadow operation or receiving an underlying service failure
  1790. indication.
  1791.  
  1792. 11.2 Request Shadow Update operation
  1793.  
  1794.      A RequestShadowUpdate operation is used by the shadow consumer
  1795. to request updates from the shadow supplier.
  1796.  
  1797.      RequestShadowUpdate ::= OPERATION
  1798.         ARGUMENT  RequestShadowUpdateArgument
  1799.         RESULT      RequestShadowUpdateResult
  1800.         ERRORS      ShadowError
  1801.  
  1802.      RequestShadowUpdateArgument ::= SEQUENCE {
  1803.         agreementID    AgreementID,
  1804.         lastUpdate     Time,
  1805.         requestedStrategy     CHOICE {
  1806.                          standard       ENUMERATED     {
  1807.                                        incremental     (1),
  1808.                                        total      (2) },
  1809.                          other          EXTERNAL } }
  1810.  
  1811.      RequestShadowUpdateResult ::=   NULL
  1812.  
  1813. 11.2.1        Request Shadow Update parameters
  1814.  
  1815.      The various parameters have the meanings as defined below:
  1816.  
  1817.      The agreementID argument identifies the shadowing agreement as
  1818. defined in 9.1.
  1819.  
  1820.      The lastUpdate argument is the time provided by the shadow
  1821. supplier in the most recent successful update.
  1822.  
  1823.      The requestedStrategy argument identifies the type of update
  1824. being requested by the shadow consumer.
  1825.  
  1826.      The shadow consumer may request either an incremental or a
  1827. total update from the shadow supplier. However,  if the shadow
  1828. consumer requests an incremental update and the shadow supplier
  1829. determines that it needs to send a total update, it will return a
  1830. ShadowError with problem  set to fullUpdateRequired.
  1831.  
  1832. 11.2.2        Request Shadow Update success
  1833.  
  1834.      Should the request succeed, a result will be returned although
  1835. no information will be conveyed with it.
  1836.  
  1837. 11.2.3        Request Shadow Update failure
  1838.  
  1839.      Should the  request fail,  a ShadowError shall be reported.
  1840. Circumstances under which the particular shadow problems will be
  1841. returned are defined below.
  1842.  
  1843.      An invalidAgreementID shadow problem is returned if the shadow
  1844. supplier DSA does not recognize the AgreementID specified within
  1845. the set of AgreementIDs with this shadow consumer DSA.
  1846.  
  1847.      An inactiveAgreement shadow problem is returned if the shadow
  1848. supplier DSA recognizes the AgreementID as a valid AgreementID for
  1849. this shadow consumer DSA, but the shadow supplier DSA understands
  1850. that the AgreementID is inactive.
  1851.  
  1852.      An unsupportedStrategy  shadow problem is returned if the
  1853. shadow supplier DSA does not support the refresh strategy selected
  1854. by the shadow consumer DSA  for this shadowing agreement.
  1855.  
  1856.      A fullUpdateRequired shadow problem is returned by the shadow
  1857. supplier DSA to inform the shadow consumer that a total refresh is
  1858. required to bring the shadow consumer DSA into a state of
  1859. consistency with the shadow supplier.  This could be returned, for
  1860. instance, if the shadow supplier DSA is unable to construct a
  1861. meaningful incremental update with respect to the value received in
  1862. lastUpdate.
  1863.  
  1864.      An unwillingToPerform shadow problem is returned by the shadow
  1865. supplier DSA to indicate that it is unwilling to perform the update
  1866. operation associated with this request operation.  Interpretation
  1867. of this shadow problem is outside the scope of this Specification.
  1868.  
  1869.      An unsuitableTiming shadow problem is returned if the shadow
  1870. supplier DSA is unwilling to perform the update associated with
  1871. this request operation at this time.
  1872.  
  1873.      The invalidInformationReceived, missedPrevious, and
  1874. updateAlreadyReceived shadow problems are not returned in response
  1875. to this operation.
  1876.  
  1877.      An invalidSequencing shadow problem is returned to signal the
  1878. receipt of multiple consecutive RequestShadowUpdate requests for a
  1879. single shadowing agreement without completing an intervening
  1880. UpdateShadow operation or receiving an underlying service failure
  1881. indication.
  1882.  
  1883. 11.3 Update Shadow operation
  1884.  
  1885.      An UpdateShadow operation is invoked by the shadow supplier to
  1886. send updates to the shadow  consumer for a unit of replication.
  1887. Prior to this operation being initiated, a CoordinateShadowUpdate
  1888. or a RequestShadowUpdate operation must have been successfully
  1889. completed.
  1890.  
  1891.      UpdateShadow ::= OPERATION
  1892.         ARGUMENT      UpdateShadowArgument
  1893.         RESULT        UpdateShadowResult
  1894.         ERRORS        ShadowError
  1895.  
  1896.      UpdateShadowArgument ::= SEQUENCE {
  1897.         agreementID           AgreementID,
  1898.         updateTime   Time,
  1899.         updateWindow       UpdateWindow OPTIONAL,
  1900.         updatedInfo  RefreshInformation }
  1901.  
  1902.      UpdateShadowResult ::= NULL
  1903.  
  1904. 11.3.1        Update Shadow Parameters
  1905.  
  1906.      The various parameters have the meanings as defined below:
  1907.  
  1908.      The agreementID identifies the shadowing agreement that has
  1909. been established.
  1910.  
  1911.      The updateTime argument is supplied by the shadow supplier.
  1912. This time is used during the next CoordinateShadowUpdate  or
  1913. RequestShadowUpdate to ensure that the shadow supplier and shadow
  1914. consumer have a common view of the shadowed information.
  1915.  
  1916.      The updateWindow argument, when present, indicates the next
  1917. window during which the shadow supplier expects to send an update.
  1918. This parameter is only allowed if the SchedulingParameter of the
  1919. UpdateMode of the shadowing agreement has the othertimes parameter
  1920. set to TRUE.
  1921.  
  1922.      UpdateWindow ::=    SEQUENCE {
  1923.         start       Time,
  1924.         stop        Time }
  1925.  
  1926.      The updatedInfo argument provides the information required by
  1927. the shadow consumer to update its shadowed information. This may be
  1928. a total copy of the shadowed information or only incremental
  1929. updates for a set of SDSEs.  Although this need not provide a
  1930. ╥mirror image╙ in the shadow consumer of the shadow supplier╒s
  1931. information at any particular instant in time, the updates sent
  1932. must be internally consistent for the replicated area.
  1933.  
  1934.      The semantics of the information conveyed in this parameter
  1935. shall result in the shadow consumer reflecting the changes
  1936. supplied.  Furthermore each update shall be applied independently
  1937. and without regard to previously transmitted updates.  If for
  1938. instance, a particular add or delete was sent twice (in two
  1939. separate updates with different update times), the shadow consumer
  1940. would not signal an error, as the effect of adding the same shadow
  1941. DSE twice in immediate succession is the same as adding it once.
  1942. Similarly, deletin twice in immediate succession is the same as
  1943. deleting once.  However, neither would the shadow consumer
  1944. disregard the second update on the basis of having received an
  1945. earlier identical update, since intervening changes to the DSE
  1946. (within the update window) could make the second update
  1947. significant.
  1948.  
  1949.      RefreshInformation ::= CHOICE {
  1950.         noRefresh      NULL,
  1951.         total            [0]  TotalRefresh,
  1952.         incremental    [1]    IncrementalRefresh,
  1953.         otherStrategy  EXTERNAL  }
  1954.  
  1955.      noRefresh indicates that there have been no changes to the
  1956. shadowed information from the previous instance to the present.
  1957. This may be used where an UpdateShadow operation  must be supplied
  1958. at a certain intervals defined in the shadowing agreement
  1959. (updateMode), but no modification has actually occurred.
  1960.  
  1961.      total provides a new instance of the shadowed information.
  1962.  
  1963.      incremental provides, instead of a complete replacement of the
  1964. shadowed information, only the changes which have occurred to that
  1965. shadowed information between lastUpdate in the most recent
  1966. CoordinateShadowUpdate (or RequestShadowUpdate request), and
  1967. updateTime in the current UpdateShadow request  (or
  1968. RequestShadowUpdate response).
  1969.  
  1970.      otherStrategy provides the ability to send updates by
  1971. mechanisms outside the scope of this Directory Specification.
  1972.  
  1973.      Note╤Refresh of a subtree of the replicated area can be
  1974. accomplished through shadowing agreements with overlapping areas of
  1975. replication.
  1976.  
  1977. 11.3.1.1      Total refresh
  1978.  
  1979.      The complete shadowed information is included starting at the
  1980. root and including all SDSEs within the shadowed information.
  1981.  
  1982.      TotalRefresh ::= SEQUENCE {
  1983.         sDSE        SDSEContent OPTIONAL,
  1984.         subtree          SET OF Subtree OPTIONAL }
  1985.  
  1986.      SDSEContent ::= SEQUENCE {
  1987.         sDSEType         SDSEType,
  1988.         subComplete      BOOLEAN DEFAULT FALSE,
  1989.         attComplete           BOOLEAN OPTIONAL,
  1990.                     SET OF Attribute }
  1991.  
  1992. SDSEType  ::=  BIT STRING  {
  1993.                     glue      (1), -- represents knowledge of a
  1994. name --
  1995.                     cp        (2)  -- context prefix --
  1996.                     entry          (3), -- object entry --
  1997.                               alias          (4), -- alias entry -
  1998.            -
  1999.                               subr      (5), -- subordinate
  2000.            reference --
  2001.                               nssr      (6), -- non-specific
  2002.            subordinate reference --
  2003.                               admPoint  (9), -- administrative
  2004.            point --
  2005.                               subEntry  (10),     -- subentry --
  2006.                               immSupr   (13),     -- immediate
  2007.            superior reference
  2008.                               as        (15) }    -- subordinate
  2009.            alias --
  2010.  
  2011.      Subtree ::= SEQUENCE {
  2012.         RelativeDistinguishedName,
  2013.         COMPONENTS OF TotalRefresh }
  2014.  
  2015.      Absence of objects  (SDSEs) formerly contained in the shadowed
  2016. information indicates their deletion.
  2017.  
  2018.      Subtree is omitted for SDSEs which have no subordinate SDSEs.
  2019.  
  2020.      subComplete is a boolean that, if present, indicates  whether
  2021. or not  subordinate knowledge is complete.  If TRUE, subordinate
  2022. knowledge is complete.  If FALSE, subordinate knowledge is
  2023. incomplete or unknown.
  2024.  
  2025.      attComplete is a boolean that, if present, indicates whether
  2026. or not all user attributes are included.   If TRUE, all user
  2027. attributes are included.  If FALSE, some user attributes have been
  2028. omitted.  If absent, it is undefined whether or not all user
  2029. attributes are present.
  2030.  
  2031. 11.3.1.2      Incremental refresh
  2032.  
  2033.      Only the changes to the shadowed information are included in
  2034. the IncrementalRefresh.
  2035.  
  2036.      IncrementalRefresh ::= SEQUENCE  OF  {
  2037.         IncrementalStepRefresh     IncrementalStepRefresh }
  2038.  
  2039.      IncrementalStepRefresh    ::= SEQUENCE {
  2040.         sDSEChanges      CHOICE {
  2041.            add           [0]  SDSEContent,
  2042.            remove        NULL,
  2043.            modify        [1]  ContentChange } OPTIONAL
  2044.         subordinateUpdates         SET OF    SubordinateChanges
  2045. OPTIONAL }
  2046.  
  2047.      ContentChange ::= SEQUENCE {
  2048.         rename           RelativeDistinguishedName OPTIONAL,
  2049.         CHOICE {
  2050.            replace  [0]  SET OF Attribute,
  2051.            changes       SEQUENCE OF EntryModification
  2052.                                    } OPTIONAL,
  2053.         sDSEType              SDSEType,
  2054.          subComplete     [1]  BOOLEAN DEFAULT FALSE,
  2055.          attComplete     [2]  BOOLEAN OPTIONAL }
  2056.  
  2057.      SubordinateChanges ::= SEQUENCE {
  2058.         RelativeDistinguishedName,
  2059.         COMPONENTS OF IncrementalRefresh }
  2060.  
  2061.      The sequence of incrementalStepRefresh within the
  2062. IncrementalRefresh shall be applied to the replicated area in the
  2063. order supplied.  This is required to support incremental updates in
  2064. the case of reuse of a Distinguished Name.
  2065.  
  2066.      incrementalStepRefresh specifies a group of changes to be
  2067. applied to the replicated area.
  2068.  
  2069.      SDSEChanges indicates changes which need to be reflected in
  2070. the shadowed information.
  2071.  
  2072.      add provides a copy of a complete SDSE.  The shadow DSE in the
  2073. shadow consumer has no subordinates.  If a shadow DSE with this
  2074. name already exists in the shadow consumer, any subordinates are
  2075. deleted and the shadow DSE replaced.
  2076.  
  2077.      remove indicates that this SDSE, and any subordinates to it,
  2078. should not be represented by shadow DSEs in the shadow consumer.
  2079.  
  2080.      modify includes those changes that need to be reflected in a
  2081. particular SDSE.
  2082.  
  2083.      rename is used to indicate changes to the distinguished value
  2084. of one or more attributes which needs to be reflected in the SDSE.
  2085. This does not affect the attribute types used for naming..
  2086.  
  2087.      If the changes to the SDSE are extensive, a complete
  2088. replacement of content is achieved using replace.  Otherwise
  2089. changes  is used to indicate changes which need to be reflected in
  2090. the SDSE.
  2091.  
  2092.      If attComplete is absent this indicates that its value is
  2093. undefined and it should not be included in the SDSE.
  2094.  
  2095.      SubordinateChanges  is used to create or modify subordinates.
  2096. It is absent  if there are no differences in the subordinate SDSEs.
  2097.  
  2098. 11.3.2        Update Shadow success
  2099.  
  2100.      Should the request succeed, a result will be returned,
  2101. although no information will be conveyed with it.
  2102.  
  2103. 11.3.3        Update Shadow failure
  2104.  
  2105.      Should the  request fail,  a ShadowError shall be reported.
  2106. Circumstances under which the particular shadow problems will be
  2107. returned are defined below.
  2108.  
  2109.      An invalidAgreementID shadow problem is returned if the shadow
  2110. consumer DSA does not recognize the AgreementID specified within
  2111. the list of AgreementIDs with this shadow supplier DSA.
  2112.  
  2113.      An inactiveAgreement shadow problem is returned if the shadow
  2114. consumer DSA recognizes the AgreementID as a valid AgreementID for
  2115. this shadow supplier DSA, and if the shadow consumer DSA
  2116. understands that the AgreementID is inactive.
  2117.  
  2118.      An invalidInformationReceived shadow problem is returned if
  2119. the shadow consumer DSA determines that, as a result of an error in
  2120. the received data, it may not be able to use the received data to
  2121. provide directory services to the directory users.  As a general
  2122. rule, extraneous data (e.g., entries that should have been filtered
  2123. as a result of object class selection, attributes that should have
  2124. been filtered out, etc.) is not considered sufficiently serious to
  2125. require the return of this shadow problem as it can be ignored by
  2126. the shadow consumer.  Interpretation of this shadow problem is
  2127. outside the scope of this Specification.
  2128.  
  2129.      An unwillingToPerform shadow problem is returned by the shadow
  2130. consumer DSA to indicate that the shadow consumer DSA is unwilling
  2131. to perform this update operation.  It may be returned, for example,
  2132. to indicate that the APDU size exceeds local limits.
  2133. Interpretation of this shadow problem is outside the scope of this
  2134. Specification.
  2135.  
  2136.      The unsupportedStrategy, missedPrevious, fullUpdateRequired,
  2137. unsuitableTiming,  and updateAlreadyReceived shadow problems are
  2138. not returned in response to this operation.
  2139.  
  2140.      An invalidSequencing shadow problem is returned to signal the
  2141. receipt of an UpdateShadow operation for which there had been no
  2142. prior CoordinateShadowUpdate or RequestShadowUpdate operation.
  2143.  
  2144.  
  2145. 12   Shadow error
  2146.  
  2147.      For any of the operations defined in clause 11 a ShadowError
  2148. may be returned, the nature of the problem, and optionally the
  2149. lastUpdate with a more suitable updateWindow.
  2150.  
  2151.      ShadowError ::= ERROR
  2152.         PARAMETER SEQUENCE    {
  2153.            problem     ShadowProblem,
  2154.            lastUpdate  Time OPTIONAL,
  2155.            updateWindow  UpdateWindow OPTIONAL}
  2156.  
  2157.      ShadowProblem ::= INTEGER {
  2158.         invalidAgreementID         (1),
  2159.         inactiveAgreement          (2),
  2160.         invalidInformationReceived (3),
  2161.         unsupportedStrategy   (4),
  2162.         missedPrevious        (5),
  2163.         fullUpdateRequired         (6),
  2164.         unwillingToPerform         (7) ,
  2165.         unsuitableTiming      (8),
  2166.         updateAlreadyReceived (9),
  2167.         invalidSequencing               (10) }
  2168.  
  2169. 12.1 Shadow error problems
  2170.  
  2171.      One of the following problems encountered is specified in
  2172. problem:
  2173.      a)invalidAgreementID:  This DSA does not recognize the
  2174.         AgreementID specified within the list of AgreementIDs with
  2175.         that DSA;
  2176.      b)inactiveAgreement:  This error is returned when the
  2177.         agreement with this DSA exists but has not yet become
  2178.         active, or has become inactive but still exists;
  2179.      c)invalidInformationReceived:  This error indicates a serious
  2180.         problem with the shadow consumer DSA's understanding of the
  2181.         data received (i.e., the shadow consumer DSA is unable to
  2182.         use the data to provide directory services to directory
  2183.         users);
  2184.      d)unsupportedStrategy:  Indicates that the refresh strategy
  2185.         selected is not in the shadowing agreement or is not
  2186.         supported by this DSA;
  2187.      e)missedPrevious: Indicates that the value received in
  2188.         lastUpdate is not consistent with the time the shadow
  2189.         consumer DSA understands was the time of the last update;
  2190.      f)fullUpdateRequired:  Indicates that the only acceptable
  2191.         strategy at this time (e.g., in the event of an otherwise
  2192.         unrecoverable mismatch of time stamps) is a full update;
  2193.      g)unwillingToPerform: Indicates that the responder is
  2194.         unwilling to perform the requested operation.
  2195.         Interpretation of and action following receipt of this
  2196.         error is outside the scope of this Specification.
  2197.      h)unsuitableTiming:  Indicates that the responder is
  2198.         unwilling to handle the update or the generation of the
  2199.         update at this time.
  2200.      i)updateAlreadyReceived:  Indicates that the shadow consumer
  2201.         has already received the update associated with lastUpdate.
  2202.      j)invalidSequencing:  Indicates the receipt of shadow
  2203.         operations that are out of sequence.
  2204.  
  2205. 12.2 Last update
  2206.  
  2207.      If a missedPrevious error is reported by the shadow consumer
  2208. the lastUpdate argument may be provided.. This allows the shadow
  2209. supplier to determine whether it should send a total  or
  2210. incremental update. The means by which the shadow supplier reaches
  2211. this decision is outside the scope of this Specification.
  2212.  
  2213. 12.3 Update window
  2214.  
  2215.      The updateWindow argument is (optionally) provided only if the
  2216. shadow supplier is reporting an unsuitableTiming  error.  This is
  2217. used by the shadow supplier to indicate the preferred window for
  2218. the next attempt to refresh the shadow.
  2219.                                  
  2220.                                  
  2221.                                  
  2222.                               Annex A
  2223.                                  
  2224.                ASN.1 for Directory shadow operations
  2225.                                  
  2226.                                  
  2227.             (This annex forms an integral part of this
  2228.               Recommendation|International Standard.)
  2229.  
  2230.      This Annex includes all of the ASN.1 type, and value and
  2231. definitions contained in this Specification in the form of the
  2232. ASN.1 module DirectoryShadowAbstractService.
  2233.  
  2234.      DirectoryShadowAbstractService {joint-iso-ccitt ds(5)
  2235. modules(1) directoryShadowAbstractService(15) version (2) }
  2236.      DEFINITIONS  ::=
  2237.      BEGIN IMPLICIT-TAGS
  2238.  
  2239.      --    EXPORTS ALL The types and values defined in this module
  2240. are being exported for use in
  2241.      --    the other ASN.1 modules contained within the Directory
  2242. Specifications, and for the use of
  2243.      --    other applications which will use them to access
  2244. Directory services.  Other applications may
  2245.      --    use them for their own purposes but those uses will not
  2246. constrain extensions and
  2247.      --    modifications needed to maintain or improve the
  2248. Directory service.--
  2249.  
  2250.      IMPORTS
  2251.         BIND, UNBIND, OPERATION, ERROR
  2252.      FROM Remote-Operation-Notation {joint-iso-ccitt
  2253. remoteOperations(4) notation(0)}
  2254.  
  2255.         id-pt-shadow-update
  2256.      FROM DirectoryShadowObjectIndentifiers
  2257. directoryShadowObjectIdentifiers
  2258.  
  2259.         Attribute, ATTRIBUTE, ATTRIBUTE-SYNTAX, attributeSyntax,
  2260. AttributeType, Name,     RelativeDistinguishedName,
  2261. DistinguishedName, SubtreeSpecification
  2262.      FROM InformationFramework informationFramework
  2263.  
  2264.         DirectoryBind, Entry Modification
  2265.      FROM DirectoryAbstractService directoryAbstractService
  2266.  
  2267.         AccessPoint
  2268.      FROM DistributedOperations distributedOperations
  2269.  
  2270.         OPERATIONAL-BINDING-TYPE, OperationalBindingID
  2271.      FROM DirectoryOperationalBindingManagementAbstractService
  2272. directoryOperationalBindingManagementAbstractService;
  2273.  
  2274. -- bind and unbind --
  2275.  
  2276.      DSAShadowBind ::= BIND
  2277.         ARGUMENT    DirectoryBindArgument
  2278.         RESULT           DirectoryBindResult
  2279.         BIND-ERROR  DirectoryBindError
  2280.  
  2281.      DSAShadowUnbind ::= UNBIND
  2282.  
  2283. -- shadow operational binding --
  2284.  
  2285.      shadowOperationalBinding  OPERATIONAL-BINDING-TYPE
  2286.         AGREEMENT   ShadowingAgreementInfo
  2287.         APPLICATION CONTEXTS
  2288.            ShadowSupplierInitiatedAC APPLIES TO ALL OPERATIONS
  2289.            ShadowConsumerInitiatedAC APPLIES TO ALL OPERATIONS
  2290.            ReliableShadowSupplierInitiatedAC APPLIES TO ALL
  2291. OPERATIONS
  2292.            ReliableShadowConsumerInitiatedAC APPLIES TO ALL
  2293. OPERATIONS
  2294.         ASYMMETRIC
  2295.            ROLE-A   -- shadow supplier role
  2296.              ESTABLISHMENT-INITIATOR
  2297.              MODIFICATION-INITIATOR
  2298.              TERMINATION-INITIATOR
  2299.            ROLE-B   -- shadow consumer role
  2300.              ESTABLISHMENT-INITIATOR
  2301.              MODIFICATION-INITIATOR
  2302.              TERMINATION-INITIATOR
  2303.         ::= { operationalBinding 1}
  2304.  
  2305.      AgreementID ::=     OperationalBindingID
  2306.  
  2307.      ShadowingAgreement ::= ShadowingAgreementInfo
  2308.  
  2309.      ShadowingAgreementInfo ::= SEQUENCE {
  2310.         shadowSubject UnitOfReplication,
  2311.         updateMode    UpdateMode,
  2312.         master           AccessPoint  OPTIONAL,
  2313.         completeSubentry      BOOLEAN DEFAULT TRUE }
  2314.  
  2315.      UnitOfReplication    ::=SEQUENCE   {
  2316.         area             AreaSpecification,
  2317.         attributes            AttributeSelection,
  2318.         knowledge        Knowledge OPTIONAL }
  2319.  
  2320.      AreaSpecification ::= SEQUENCE {
  2321.         contextPrefix    DistinguishedName,
  2322.         replicationArea  SubtreeSpecification }
  2323.  
  2324.      Knowledge  ::= SEQUENCE {
  2325.         knowledgeType    ENUMERATED {
  2326.                          master    (0),
  2327.                          shadow    (1),
  2328.                          both (2) },
  2329.         extendedKnowledge          BOOLEAN DEFAULT FALSE }
  2330.  
  2331.      AttributeSelection  ::=  SET OF ClassAttributeSelection
  2332.  
  2333.      ClassAttributeSelection  ::=  SEQUENCE {
  2334.         class                 OBJECT IDENTIFIER OPTIONAL,
  2335.         classAttributes  ClassAttributes }
  2336.  
  2337.      ClassAttributes  ::= CHOICE {
  2338.         allAttributes              NULL,
  2339.         include          [0]  AttributeTypes,
  2340.         exclude          [1]  AttributeTypes
  2341.                     }    DEFAULT allAttributes  NULL
  2342.  
  2343.      AttributeTypes ::=  SET OF AttributeType
  2344.  
  2345.      UpdateMode  ::=     CHOICE    {
  2346.         supplierInitiated     [0]  SupplierUpdateMode,
  2347.         consumerInitiated          [1]  ConsumerUpdateMode  }
  2348.  
  2349.      SupplierUpdateMode ::=        CHOICE         {
  2350.         onChange         BOOLEAN DEFAULT TRUE,
  2351.         scheduled        SchedulingParameters     }
  2352.  
  2353.      ConsumerUpdateMode    ::=     SchedulingParameters
  2354.  
  2355.      SchedulingParameters ::= SEQUENCE {
  2356.         periodic    PeriodicStrategy    OPTIONAL,
  2357.            -- must be present if othertimes is set to FALSE --
  2358.         othertimes  BOOLEAN DEFAULT FALSE    }
  2359.  
  2360.      PeriodicStrategy ::= SEQUENCE {
  2361.         beginTime       Time OPTIONAL,
  2362.         windowSize            INTEGER,
  2363.         frequencyOfUpdate     INTEGER   }
  2364.  
  2365.      Time  ::=  UTCTime
  2366.  
  2367.      UpdateWindow ::= SEQUENCE {
  2368.         start            Time,
  2369.         stop        Time }
  2370.  
  2371. -- shadow operations, arguments, and results --
  2372.  
  2373.      CoordinateShadowUpdate ::= OPERATION
  2374.         ARGUMENT         CoordinateShadowUpdateArgument
  2375.         RESULT           CoordinateShadowUpdateResult
  2376.         ERRORS           ShadowError
  2377.  
  2378.      CoordinateShadowUpdateArgument ::=  SEQUENCE {
  2379.         agreementID AgreementID,
  2380.         lastUpdate       Time,
  2381.         updateStrategy   CHOICE {
  2382.                          standard  ENUMERATED {
  2383.                                    noChanges (0),
  2384.                                    incremental    (1),
  2385.                                    total          (2)  },
  2386.                          other     EXTERNAL  }  }
  2387.  
  2388.      CoordinateShadowUpdateResult ::= NULL
  2389.  
  2390.      UpdateShadow ::= OPERATION
  2391.         ARGUMENT         UpdateShadowArgument
  2392.         RESULT           UpdateShadowResult
  2393.         ERRORS           ShadowError
  2394.  
  2395.      UpdateShadowArgument ::= SEQUENCE {
  2396.         agreementID AgreementID,
  2397.         updateTime            Time,
  2398.         updateWindow     UpdateWindow   OPTIONAL,
  2399.         updatedInfo      RefreshInformation }
  2400.  
  2401.      UpdateShadowResult ::= NULL
  2402.  
  2403.      RefreshInformation ::= CHOICE {
  2404.         noRefresh        NULL,
  2405.         total            [0]  TotalRefresh,
  2406.         incremental      [1]  IncrementalRefresh,
  2407.         otherStrategy    EXTERNAL  }
  2408.  
  2409.      TotalRefresh ::= SEQUENCE {
  2410.         sDSE        SDSEContent OPTIONAL,
  2411.         subtree          SET OF Subtree OPTIONAL }
  2412.  
  2413.      SDSEContent ::= SEQUENCE {
  2414.         sDSEType         SDSEType,
  2415.         subComplete BOOLEAN DEFAULT FALSE,
  2416.         attComplete      BOOLEAN OPTIONAL,
  2417.                     SET OF Attribute }
  2418.  
  2419.      SDSEType  ::=  BIT STRING  {
  2420.                          glue      (1), -- represents knowledge of
  2421. a name --
  2422.                          cp        (2)  -- context prefix --
  2423.                          entry          (3), -- object entry --
  2424.                          alias          (4(  -- alias entry --
  2425.                          subr      (5), -- subordinate reference --
  2426.                          nssr      (6), -- non-specific subordinate
  2427. reference --
  2428.                          admPoint  (9), -- administrative point --
  2429.                          subEntry  (10),     -- subentry --
  2430.                i         immSupr   (13),     -- immediate superior
  2431. reference
  2432.                               as        (15) }    -- subordinate
  2433. alias --
  2434.  
  2435.      Subtree ::= SEQUENCE {
  2436.         RelativeDistinguishedName,
  2437.         COMPONENTS OF TotalRefresh }
  2438.  
  2439.      IncrementalRefresh ::= SEQUENCE  OF{
  2440.         incrementalStepRefresh     IncrementalStepRefresh }
  2441.  
  2442.      IncrementalStepRefresh   ::=     SEQUENCE {
  2443.         sDSEChanges      CHOICE {
  2444.            add           [0]  SDSEContent,
  2445.            remove        NULL,
  2446.            modify        [1]  ContentChange } OPTIONAL
  2447.         subordinateUpdates         SET OF
  2448. SubordinateChanges OPTIONAL }
  2449.  
  2450.      ContentChange ::= SEQUENCE {
  2451.         rename           RelativeDistinguishedName OPTIONAL,
  2452.         CHOICE {
  2453.            replace  [0]  SET OF Attribute,
  2454.            changes       SEQUENCE OF EntryModification
  2455.                               } OPTIONAL,
  2456.         sDSEType              SDSEType,
  2457.          subComplete     [1]  BOOLEAN DEFAULT FALSE,
  2458.          attComplete     [2]  BOOLEAN OPTIONAL }
  2459.  
  2460.      SubordinateChanges ::= SEQUENCE {
  2461.         RelativeDistinguishedName,
  2462.         COMPONENTS OF IncrementalRefresh }
  2463.  
  2464.      RequestShadowUpdate ::= OPERATION
  2465.         ARGUMENT         RequestShadowUpdateArgument
  2466.         RESULT   RequestShadowUpdateResult
  2467.         ERRORS   ShadowError
  2468.  
  2469.      RequestShadowUpdateArgument ::= SEQUENCE {
  2470.         agreementID AgreementID,
  2471.         lastUpdate       Time,
  2472.         requestedStrategy     CHOICE {
  2473.                          standard       ENUMERATED     {
  2474.                                         incremental    (1),
  2475.                                         total          (2) },
  2476.                          other          EXTERNAL } }
  2477.  
  2478.      RequestShadowUpdateResult ::=   NULL
  2479.  
  2480. -  errors --
  2481.  
  2482.      ShadowError ::= ERROR
  2483.         PARAMETER SEQUENCE {
  2484.            problem       ShadowProblem,
  2485.            lastUpdate         Time OPTIONAL,
  2486.            updateWindow       UpdateWindow OPTIONAL}
  2487.  
  2488.      ShadowProblem ::= INTEGER {
  2489.         invalidAgreementID         (1),
  2490.         inactiveAgreement          (2),
  2491.         invalidInformationReceived (3),
  2492.         unsupportedStrategy   (4),
  2493.         missedPrevious        (5),
  2494.         fullUpdateRequired         (6),
  2495.         noInformation         (7),
  2496.         unwillingToPerform         (8) ,
  2497.         unsuitableTiming      (9),
  2498.         updateAlreadyReceived (10)
  2499.         invalidSequencing               (11) }
  2500.  
  2501.      END
  2502.  
  2503.  
  2504.  
  2505.  
  2506.                                  
  2507.                           _______________
  2508.