RFC1276

From RFC-Wiki

Network Working Group S.E. Hardcastle-Kille Requests for Comments 1276 University College London 

                                                     November 1991

      Replication and Distributed Operations extensions
         to provide an Internet Directory using X.500

Status of this Memo 

This RFC specifies an IAB standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements.  Please refer to the current edition of the ``IAB
Official Protocol Standards for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

Abstract 

Some requirements on extensions to X.500 are described in the
RFC[HK91b], in order to build an Internet Directory using
X.500(1988).  This document specifies a set of solutions to the
problems raised.  These solutions are based on some work done for
the QUIPU implementation, and demonstrated to be effective in a
number of directory pilots.  By documenting a de facto standard,
rapid progress can be made towards a full-scale pilot.  These
procedures are an INTERIM approach.  There are known
deficiencies, both in terms of manageability and scalability.
Transition to standard approaches are planned when appropriate
standards are available.  This RFCwill be obsoleted at this
point.

Contents

1 Approach 2

2 Extensions to Distributed Operations 3

3 Alternative DSAs 4

4 Data Model 5

5 DSA Naming 6

6 Knowledge Representation 6

7 Replication Protocol 9

8 New Application Context 12

9 Policy on Replication Procedures 12

10 Use of the Directory by Applications 12

11 Migration and Scaling 12

12 Security Considerations 13

13 Author's Address 13

A ASN.1 Summary and Object Identifier Allocation 14

List of Figures 

1      Knowledge Attributes  .   .   .   .   .   .   .   .       8

2      Replication Protocol  .   .   .   .   .   .   .   .      10
3      Summary of the ASN.1  .   .   .   .   .   .   .   .      17

Hardcastle-Kille Page 1

1 Approach

There are a number of non-negotiable requirements which must be met before a directory can be deployed on the Internet [HK91b]. These problems are being tackled in the standards arena, but there is currently no stable solution. One approach would be to attempt to intercept the standard. Difficulties with this would be: 

o  Defining a coherent intercept would be awkward, and the effort
would probably be better devoted to working on the standard.  It
is not even clear that such an intercept could be defined.

o  The target is moving, and it is always tempting to track it, thus
causing more delay.

o  There would be a delay involved with this approach.  It would be
too late to be useful for a rapid start, and sufficiently close to
the timing of the final standard that many would choose not to
implement it.

Therefore, we choose to take a simple approach. This is a good deal simpler than the full X.500 approach, and is based on operational experience. The advantages of this approach are: 

o  It is proven in operation.  This RFCis simply documenting what is
being done already.

o  There will be a minimum of delay in starting to use the approach.

o  The approach is simpler, and so the cost of implementation is much
less.  It will therefore be much more attractive to add into an
implementation, as it is less effort, and can be further ahead of
the standard.

These procedures are an INTERIM approach. There are known deficiencies, both in terms of manageability and scalability. Transition to standard approaches are planned when appropriate standards are available. This RFCwill be obsoleted at this point.

Hardcastle-Kille Page 2

2 Extensions to Distributed Operations

The distributed operations of X.500 assume that all DUAs and DSAs are fully interconnected with a global network service. For the Internet Pilot, this assumption is invalid. DSAs may be operated over TCP/IP, TP4/CLNS, or TP0/CONS. The extension to distributed operations to support this situation is straightforward. We define the term community as an environment where direct (network) communication is possible. Communities may be separated because they operate different protocols, or because of lack of physical connectivity. Example communities are the DARPA/NSF Internet, and the Janet private X.25 network. A network entity in a community is addressed by its Network Address. If two network entities are in the same community, they can by definition communicate. A community is identified by a set of network address prefixes. For the approach to be useful, this set should be small (typically 1). For TCP/IP Networks, and X.25 Networks not providing CONS, the approach is described in [HK91a] allows for communities to be defined for the networks of operational interest.

This model can be used to determine whether a pair of application entities can communicate. For each entity, determine the presentation address (typically by directory lookup). Each network address in the presentation address will have a single associated community. The set of communities to which each application entity belongs can thus be determined. If the two application entities have a common community, then they can communicate directly. Two extensions to the standard distributed operations are needed.

Consider a DSA (the local DSA) which is contacted by either a DUA

or DSA (the calling entity) to resolve a query.  The local DSA
determines that the query must be progressed by another DSA (the
referred-to DSA). The DSA will make a chain/referral choice.  If
chaining is prohibited by service control, a referral will be
passed back.  Otherwise, if the local DSA prefers to chain (e.g.,
for policy reasons) it will then chain.  The remaining situation
is that the local DSA prefers to give a referral.  It shall only
do so if it believes that the calling entity can directly connect
to the referred-to DSA. If the calling entity is a DUA, it should
be assumed to belong only to the community of the called network
address.  If the calling entity is a DSA, its communities should
be determined by lookup of the DSA's presentation address in the
directory.  The communities of the referred-to DSA can be

Hardcastle-Kille Page 3 

determined from its presentation address, which will either be
present in the reference or can be looked up in the directory.  If
the calling entity and the referred-to DSA do not have a common
community, then chaining shall be used.  Otherwise, a referral may
be passed back to the calling entity.

Consider that a DSA (or DUA), termed here the local entity is

following a referral (to a referred-to DSA). In some cases, the
local entity and referred-to DSA will not be able to communicate
directly (i.e., not have a common community).  There are two
approaches to solve this:

(a) Pass the query to a DSA it would use to resolve a query for 

    the entry one level higher in the DIT. This will work,
    provided that this DSA follows this specification.  This
    default mechanism will work without additional configuration.

(b) Use a ``relay DSA to access the community. A relay DSA is 

    one which can chain the query on to the remote community.  The
    relay DSA must belong to both the remote community and to at
    least one community to which the local entity belongs.  The
    choice of relay DSA for a given community will be manually
    configured by a DSA manager to enable access to a community to
    which there is not direct connectivity.  Typically this will
    be used where the default DSA is a poor choice (e.g., because
    relaying is not authorised through this DSA).

A DSA conforming to this specification shall follow these
procedures.  A DUA may also follow these procedures, and this will
give improvements in some circumstances (i.e., the ability to
resolve certain queries without use of chaining).  However, this
specification does not place requirements on DUAs.

3 Alternative DSAs

There is a need to give information on slave copies of data. This can be done using the standard protocol, but modifying the semantics. This relies on the fact that there may only be a single subordinate reference or cross reference.

If there is a need to include references to master and slave data (EDB copies) in a referral, then this should be done in a referral by specifying a subordinate reference with multiple values. This cannot

Hardcastle-Kille Page 4

be a standard subordinate reference, which would only have a single value. Therefore, this usage does not conflict with standard references. The first reference is the master copy, and subsequent references are slave copies.

4 Data Model

The X.500 data model takes the unit of mastering data as the entry. A DSA may hold an arbitrary collection of entries. We restrict this model so that for the replication protocol defined in this specification the base unit of replication (shadowing) is the complete set of immediate subordinate entries of a given entry, termed an Entry Data Block (EDB). An EDB is named by its parent entry. It contains the relative distinguished names of all of the children of the entry, and each of the child entries. For each entry, this comprises all attributes of the entry, the relative distinguished name, and knowledge information associated with the entry. If a DSA holds (non-cached) information on an entry, it will hold information on all of its siblings. One DSA will hold a master EDB. This will contain two types of entry:

Entries for which this DSA is the master.

Slave copies of entries which are mastered in another DSA,

indicated by a subordinate reference.  This copy must be
maintained automatically by the DSA holding the master EDB.

Thus the master EDB contains a mixture of master entries, and entries which are mastered elsewhere and shadowed by the DSA holding the master EDB on an entry by entry basis. Other DSAs may hold slave copies of this EDB (slave EDBs), which are replicated in their entirity directly or indirectly from the master EDB. This approach has the following advantages. 

o  Name resolution is simplified, and performance improved.

o  Single level searching and listing have good performance, and are
straightforward to implement.  In a more general case of applying
the standard, without sophisticated replication, these operations
might require to access very many DSAs and be prohibitively
expensive.

Hardcastle-Kille Page 5

5 DSA Naming

All DSAs must be named in the DIT, and the master definition of the presentation address stored in this entry. X.500 (including some of the extension work) implies that the presentation address information is extensively replicated (manually). The management overhead implied by this is not acceptable. Care must be taken to prevent deadlock in determining a DSAs address. This is solved by:

Use of a well known DSA with ``root knowledge

Naming DSAs in a manner which prevents deadlocks. Currently this

is done by giving DSAs names high in the DIT.

The Internet Pilot will need to define detailed policies for naming DSAs, in conjunction with the replication policy. This will be defined in a future RFC.

6 Knowledge Representation

Knowledge information is represented in the DIT. It seems unreasonable to manage this by any other means. Knowledge information is represented in an entry by use of knowledge attributes. These attributes are considered separately from all the other attributes in the entry which are termed ``user attributes. Each entry in a master EDB will be in one of four categories.

The entry is a leaf entry mastered in this EDB, and so only

contains user attributes

The level below has an associated EDB (i.e., the DIT continues

downwards to use the data model of this specification).  All
attributes of this entry will be mastered in this entry.  The
entry will contain an attribute with the name of the DSA which
holds the master of the associated EDB. Optionally, it will
contain an attribute holding the names of DSAs which hold slave
EDBs.  The entry may not hold a subordinate reference attribute.
The DIT is followed by use of the master and slave attributes.

Hardcastle-Kille Page 6

The entry is mastered in a DSA which does not follow this

specification.  The entry in the EDB will contain a master
attribute, which holds a subordinate reference (or cross
reference) to the DSA which holds the master entry.  The user
attributes of the entry will be mastered in the DSA pointed to by
the reference.  The DSA holding the master EDB, which actually
acts as an intermediate shadow for this entry, will read these
attributes from the DSA indicated by the reference, so that it
will have a full copy of the entry, using a standared DSP Read
operation.  This technique is called ``spot shadowing.  Any
access control on the entry being spot shadowed must be configured
so that all attributes can be copied by the DSA holding the master
EDB. DSAs taking slave copies of the EDB will not do spot
shadowing.  However, the knowledge attributes will be copied, and
may be used by this DSA (e.g., for modify operations).

The entries at the level below are held in DSAs which do not

follow this specification, and all of these are indicated by a set
of NSSRs (Non Specific Subordinate Reference).  The NSSRs are
stored as an attribute of the entry.  The user attributes are
either mastered in the EDB.
It is important to note that NSSRs are stored at the level above
subordinate references.  At a given point in the DIT, if there are
subordinate references, these are stored in shadow entries below
that point, and named by the RDN. If there are NSSRs, they are
stored in the entry itself, as there is no RDN associated with an
NSSR. This approach is cleanest where there are either NSSRs or
subordinate references, but not both.  For example, consider an
Organisation HP, whose many OUs are stored in a set of DSAs
indicated by by NSSRs.  Here, the NSSR attributes will be used to
identify these DSAs.
This model of replication is not tightly integrated with NSSRs.
Where there is a mixture of NSSRs and Subordinate references at a
given point in the DIT, this is handled by giving a single
subordinate reference to a DSA which follows standard X.500
distributed operations and can cleanly handle this mixture.  In
practice, this is equivalent to not allowing a mixture of
subordinate references and NSSRs.

The information framework needed to support this is defined in Figure_1.______________________________________________________________

Hardcastle-Kille Page 7

InternetDSNonLeafObject ::= OBJECT-CLASS 

    SUBCLASS OF top
    MUST CONTAIN {masterDSA}
    MAY CONTAIN {slaveDSA}

ExternalDSObject ::= OBJECT-CLASS 

    SUBCLASS OF top
    MAY CONTAIN {SubordinateReference, CrossReference,          10
            NonSpecificSubordinateReference}
                    -- will contain exactly one of these references

MasterDSA ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
SINGLE VALUE

SlaveDSA ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
                                                                20

SubordinateReference ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX AccessPoint
SINGLE VALUE

CrossReference ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX AccessPoint
SINGLE VALUE

NonSpecificSubordinateReference ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX AccessPoint                               30

AccessPoint ::= SET { 

    ae-title [0] Name,
    address  [2] PresentationAddress OPTIONAL }

            -- Same definition as X.500 AccessPoint,
            -- but presentation address is optional

___________________Figure_1:__Knowledge_Attributes_____________________

Two object classes are defined to support this approach:

Hardcastle-Kille Page 8

InternetDSNonLeafObject This is for where the level below follows the 

model defined here, and there is an Entry Data Block (EDB)
containing the sibling entries.  The Entry itself contains master
data.  The associated attributes are:

MasterDSA The name of the DSA where the master EDB is held.

SlaveDSA The names of DSAs which hold slave copies of the EDB for
    public access.

ExternalDSObject This is for where the entry and levels below are 

mastered according to X.500.  There are attributes corresponding
to the standard knowledge references, which are used to resolve
queries.  The presentation address is optional in these
attributes.  If not present, it should be looked up in the DSAs
own entry.  For NonSpecificSubordinateReference, the master of the
entry will be in the master EDB, For SubordinateReference or
CrossReference1 the DSA which masters the EDB will ``spot shadow
the entry, by reading it at intervals.  This will ensure that the
master EDB contains a copy of each entry.  Single level searching
can then be done efficiently where it is not required to access
the master copy of the data.  DSAs holding slave copies of the EDB
do not perform spot shadowing, but do receive copies of the
references.

7 Replication Protocol _______________________________________________________________________ GetEntryDataBlock ABSTRACT-OPERATION 

    ARGUMENT GetEntryDataBlockArgument
    RESULT GetEntryDataBlockResult
    ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}

EDBVersionError ABSTRACT-ERROR 

    PARAMETER versionHeld EDBVersion

GetEntryDataBlockArgument ::= SET { 10 

1. These references are really the same.  The function and value

are the same. The name depends on where the reference is stored. It may be preferable to have only one attribute.

Hardcastle-Kille Page 9 

    entry [0] DistinguishedName,
    CHOICE {
            sendIfMoreRecentThan [1] EDBVersion,
            getVersionNumber [2] NULL,
            getEDB [3] NULL,        -- force retrieval
            continuation [4] SEQUENCE {
                    EDBVersion,
                    nextEntryPosition INTEGER }
            },
    maxEntries [5] INTEGER OPTIONAL                             20
                    -- if omitted return whole EDB in
                    -- one operation

}

GetEntryDataBlockResult ::= SEQUENCE { 

            versionHeld [0] EDBVersion,
            [1] SEQUENCE OF RelativeEntry OPTIONAL,
                    -- if omitted, only version is returned
            nextEntryPostion INTEGER OPTIONAL
                    -- if omitted there are no more entries     30
    }

RelativeEntry ::= SEQUENCE { 

    RelativeDistinguishedName,
    SET OF Attribute
    }

EDBVersion ::= UTCTime 40

___________________Figure_2:__Replication_Protocol_____________________

A ROS operation to support replication is defined in Figure 2. This pulls an entire copy of the EDB. In normal use, the initiator specifies the EDB Version held. If the responder has a more recent version, then all of the entries in the EDB are returned. There are options to rerequest only the version of EDB held, or to return the full EDB irrespective of the version held by the initiator. For large EDBs, transfer of an entire EDB in a single operation would lead to very large ROS PDUs. This gives a definite scaling limitation. To overcome this, the protocol allows an EDB to be retrived in chunks of a size (in number of entries) specified by the

Hardcastle-Kille Page 10

initiator. The responder specifies a number which indicates the next entry to be transferred. The same operation can be used to retrieve the next chunk of the EDB, with EDBVersion and the same integer as parameters. This approach is simple to implement. It is less efficient than an incremental technique. When scaling dictates that an incremental technique must be used, it is expected that a suitable standard will be available. An implementation issue that must be noted is how to deal with updates whilst a multi-operation transfer is in progress. There are two possible approaches:

Refuse/block updates until the EDB is transferred. This may cause

problems where the rate of update and transfer is high, as this
may make update very difficult (for the manager).

Create a new version of the EDB, whilst retaining the old EDB to

complete the bulk transfer.  A suitable retentions strategy would
be to hold an EDB version as long as the association on which it
is being pulled it remains active.

Allow the update and fail subsequent transfer requests for the

EDB. This may cause both transfer failure and excessive waste of
bandwidth due to retries if the rate of update and transfer is
high.

If option 1. or 3. is chosen, for a widely replicated EDB where the update rate is greater than a few changes per day, it is recommended to configure the master EDB in a DSA which only replicates to one other DSA. This second DSA can then control its update rate, and safely perform a large fanout of replications (option 3). The first DSA will have reasonable availability for modifications (option 1).

This protocol will be used by DSAs to obtain copies of EDBs high in the tree (typically root and national EDBs). DSAs which need these copies should establish bilateral agreements to access them2. This protocol should only transfer user attributes. In particular, implementation specific attributes such as those needed to support 

2. QUIPU defines some attributes to register such agreements, but

these are probably not appropriate for this specification.

Hardcastle-Kille Page 11

private access control should not be transferred. There may be bilateral agreements on access control policy of the information (e.g., size limits on listing), which are implemented by (different) system specific techniques.

8 New Application Context

A DSA which follows these procedures will support a new ApplicationContext ``Internet DSP defined in Appendix A. This will be stored in the DSAs entry, so that support of the extensions defined here can easily be determined.

9 Policy on Replication Procedures

To be effective, a directory configuration must be laid out. These protocols will need to be used in the framework of a pilot, and service providers making available data for replication. There is a requirement to manage the replication process. This can be done by a combination of local configuration (to register shadowing agreements) and directory operations to set pointers to master and slave copies of the data.

10 Use of the Directory by Applications

Care must be taken by users of the directory when replication is available. This is not a change from current use of X.500, but is noted here as it is important. Normal read requests should allow use of copy information. If the user of the directory believes that information may be out of date (e.g., because an association could not be established), then the request should be repeated and use of copy data prohibited by service controls.

11 Migration and Scaling

The major scaling limit of this approach is the non-incremental update. This will put a limit on the maximum DIT fanout which can be supported. Given an average entry size of around a thousand bytes, and a maximum reasonable transfer size is tens of megabytes, then the

Hardcastle-Kille Page 12

fanout limit of this approach is of order 10 000. Note that smaller organisations will tend to be registered geographically (e.g., in the US, by State), so that the limit of the number of Organisations is somewhat larger. It should be noted that although the replication technique described here is general, it is only intended for high levels of the DIT. These figures assume this. These techniques do not preclude use of other techniques for replication. It would be quite reasonable to replicate data using this approach, and that which will be defined in X.500(92).

References

[HK91a] S.E. Hardcastle-Kille. Encoding network addresses to support 

    operation over non-osi lower layers. Request for Comments
    RFC 1277, Department of Computer Science, University College
    London, November 1991.

[HK91b] S.E. Hardcastle-Kille. Replication requirement to provide an 

    internet directory using X.500. Request for Comments
    RFC 1275, Department of Computer Science, University College
    London, November 1991.

12 Security Considerations

Security considerations are not discussed in this memo.

13 Author's Address 

Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England

Phone:  +44-71-380-7294

EMail:  [email protected]

Hardcastle-Kille Page 13

A ASN.1 Summary and Object Identifier Allocation

There_are_a_few_object_identifiers_needed.__These_are_defined_here.____

InternetDSP TAGS ::= BEGIN

IMPORTS 

APPLICATION-SERVICE-ELEMENT, PORT, APPLICATION-CONTEXT,
aCSE, ABSTRACT OPERATION
    FROM Remote-Operations-Notation-extension {joint-iso-ccitt
    remote-operations(4) notation-extension(2)}

                                                                10

id-as-mrse, id-as-mase, id-as-ms 

    FROM MTSAccessProtocol {joint-iso-ccitt mhs-motis(6)
    protocols(0) modules(0) object-identifiers(0)}

chainedReadASE, chainedSearchASE, chainedModifyASE 

    FROM DirectorySystemProtocol {joint-iso-ccitt ds(5)
            modules(1) dsp(12)}

DistinguishedName, RelativeDistinguishedName, Attribute 

    FROM InformationFramework {joint-iso-ccitt ds(5)            20
            modules(1) InformationFramework(1)}

ATTRIBUTE, OBJECT-CLASS 

    FROM InformationFramework {joint-iso-ccitt ds(5)
    modules(1) informationFramework(1)};

internet-dsp OBJECT IDENTIFIER ::= {ccitt data(9) pss(2342) 30 

    ucl(19200300) internet-dsp(107)}

-- General

at OBJECT IDENTIFIER ::= {internet-dsp at(1)} oc OBJECT IDENTIFIER ::= {internet-dsp oc(2)}

-- Object Classes needed for association

Hardcastle-Kille Page 14 

                                                                40

id-ac-idsp OBJECT IDENTIFIER ::= {internet-dsp ac-idsp(3))} id-as-idsp OBJECT IDENTIFIER ::= {internet-dsp as-idsp(4))} id-ase-replication OBJECT IDENTIFIER ::= {internet-dsp ase-replication(5))}

-- Attribute Types

master-dsa MasterDSA ::= {at 1} slave-dsa SlaveDSA ::= {at 2} subordinate-reference SubordinateReference ::= {at 3} 50 cross-reference CrossReference ::= {at 4} nssr NonSpecificSubordinateReference ::= {at 5}

-- Object Classes

internet-ds-non-leaf-object InternetDSNonLeafObject ::= {oc 1} external-ds-object ExternalDSObject ::= {oc 2}

-- Operation and Error bindings 60

getEntryDataBlock GetEntryDataBlock ::= 10

eDBVersionError EDBVersionError ::= 10

-- Protocol Definitions

replicationASE APPLICATION-SERVICE-ELEMENT 

OPERATIONS {getEntryDataBlock}                                  70
::= id-ase-replication

internet-dsp APPLICATION-CONTEXT 

APPLICATION SERVICE ELEMENTS {aCSE}
BIND MSBind
UNBIND MSUnbind
REMOTE OPERATIONS {rOSE}
OPERATIONS OF { chainedReadADSm chainedSearchASE,
    chainedModifyASE, replicationASE }
ABSTRACT SYNTAXES {                                             80
    id-as-acse,
    id-as-idsp }
::= id-ac-idsp

Hardcastle-Kille Page 15 

                                                                90

InternetDSNonLeafObject ::= OBJECT-CLASS 

    SUBCLASS OF top
    MUST CONTAIN {masterDSA}
    MAY CONTAIN {slaveDSA}

ExternalDSObject ::= OBJECT-CLASS 

    SUBCLASS OF top
    MAY CONTAIN {SubordinateReference, CrossReference,
            NonSpecificSubordinateReference}
                    -- will contain exactly one of these references100

MasterDSA ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
SINGLE VALUE

SlaveDSA ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax

SubordinateReference ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX AccessPoint                              110
SINGLE VALUE

CrossReference ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX AccessPoint
SINGLE VALUE

NonSpecificSubordinateReference ::= ATTRIBUTE 

WITH ATTRIBUTE-SYNTAX AccessPoint

AccessPoint ::= SET { 120 

    ae-title [0] Name,
    address  [2] PresentationAddress OPTIONAL }

            -- Same definition as X.500 AccessPoint,
            -- but presentation address is optional

GetEntryDataBlock ABSTRACT-OPERATION

Hardcastle-Kille Page 16 

    ARGUMENT GetEntryDataBlockArgument
    RESULT GetEntryDataBlockResult
    ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}130

EDBVersionError ABSTRACT-ERROR 

    PARAMETER versionHeld EDBVersion

GetEntryDataBlockArgument ::= SET { 

    entry [0] DistinguishedName,
    CHOICE {
            sendIfMoreRecentThan [1] EDBVersion,
            getVersionNumber [2] NULL,                         140
            getEDB [3] NULL,        -- force retrieval
            continuation [4] SEQUENCE {
                    EDBVersion,
                    nextEntryPosition INTEGER }
            },
    maxEntries [5] INTEGER OPTIONAL
                    -- if omitted return whole EDB in
                    -- one operation

} 

                                                               150

GetEntryDataBlockResult ::= SEQUENCE { 

            versionHeld [0] EDBVersion,
            [1] SEQUENCE OF RelativeEntry OPTIONAL,
                    -- if omitted, only version is returned
            nextEntryPostion INTEGER OPTIONAL
                    -- if omitted there are no more entries
    }

                                                               160

RelativeEntry ::= SEQUENCE { 

    RelativeDistinguishedName,
    SET OF Attribute
    }

EDBVersion ::= UTCTime END

___________________Figure_3:__Summary_of_the_ASN.1_____________________

Hardcastle-Kille Page 17

Retrieved from "https://rfc-wiki.org/index.php?title=RFC1276&oldid=19400"