RFC 1276

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

📅 published November 1991, from ietf

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

okay bestie, let's get into it 🦋 here's the title block so you know where this came from:

Working group: Network Working Group
Author: S.E. Hardcastle-Kille, University College London
Date: November 1991
Category: IAB standards track protocol
Obsoletes / Updates: nothing is listed in the title block, but the abstract says this doc will itself get obsoleted later 🙈

Status of this Memo

so this RFC specifies an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖 if you want the standardization state and status of this protocol, check the current edition of the "IAB Official Protocol Standards." distribution of this memo is unlimited, so everyone can read it ✨

Abstract

okay so some requirements for extending X.500 were already laid out in [HK91b], and the goal is to build an Internet Directory with X.500(1988) 🧚 this document is the answer to those problems. the solutions are based on work done for the QUIPU implementation, and they were shown to work in a bunch of directory pilots. by documenting this de facto standard, we can move way faster toward a full-scale pilot 🚀

BUT, and this is a big but, these procedures are an INTERIM approach. there are known deficiencies in manageability and scalability 😭 the plan is to transition to standard approaches once the right standards exist, and at that point this RFC will be obsoleted. fr fr it's giving temporary but it's doing its job 💅

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

1. Approach ✨

okay so there are a bunch of non-negotiable requirements that have to be met before a directory can be deployed on the Internet [HK91b] 🎀 these problems are being worked on in the standards arena, but right now there's no stable solution. one option would be to try to intercept the standard, but that comes with some issues:

defining a coherent intercept would be awkward, and the effort would probably be better spent on the standard itself. it's not even clear such an intercept could be defined 🙃
the target is moving, and it's always tempting to chase it, which just causes more delay 🏃‍♀️
there would be a delay with this approach. it would be too late to help with a rapid start, and it would be so close to the timing of the final standard that lots of people would choose not to implement it 💀

so we're going with a simple approach instead 💅 it's a lot simpler than the full X.500 approach, and it's based on operational experience. the perks are:

it's proven in operation. this RFC is literally just documenting what's already being done 📝
there will be minimal delay before people can start using the approach 🚀
it's simpler, so implementation costs are way lower. that makes it way more attractive to add to an implementation, since it's less effort and can get ahead of the standard 👑

these procedures are an INTERIM approach 🦋 there are known deficiencies in manageability and scalability, and transition to standard approaches is planned once appropriate standards are available. at that point this RFC will be obsoleted.

2. Extensions to Distributed Operations 🌈

so the distributed operations of X.500 assume that all DUAs and DSAs are fully interconnected through a global network service. for the Internet Pilot, that assumption is just not valid 😭 DSAs may be operated over TCP/IP, TP4/CLNS, or TP0/CONS.

the extension to distributed operations that handles this situation is straightforward 🧚 we define the term community as an environment where direct (network) communication is possible. communities may be separated because they run different protocols, or because there's no physical connectivity between them. 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 for X.25 Networks not providing CONS, the approach described in [HK91a] allows communities to be defined for the networks of operational interest 🌸

this model can be used to figure out whether a pair of application entities can communicate 👀 for each entity, you determine the presentation address (typically by a directory lookup). each network address in the presentation address has a single associated community, so the set of communities each application entity belongs to can be determined. if the two application entities share a common community, then they can communicate directly 💖

two extensions to the standard distributed operations are needed:

okay so picture a DSA (the local DSA) that gets contacted by either a DUA or a DSA (the calling entity) to resolve a query. the local DSA figures out that the query has to be progressed by another DSA (the referred-to DSA). the DSA makes a chain/referral choice. if chaining is prohibited by service control, a referral gets passed back. otherwise, if the local DSA prefers to chain (for example, for policy reasons), it chains. the remaining situation is that the local DSA prefers to give a referral. it only does that if it believes 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 looking up the DSA's presentation address in the directory. the communities of the referred-to DSA can be 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 don't have a common community, then chaining shall be used. otherwise, a referral may be passed back to the calling entity 🔥
okay so now a DSA (or DUA), called the local entity here, is following a referral to a referred-to DSA. sometimes the local entity and the referred-to DSA just won't be able to communicate directly (aka they don't have a common community) 😬 there are two ways to solve this:
- (a) pass the query to a DSA the local entity 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 works without any additional configuration 🎀
- (b) use a "relay DSA" to access the community. a relay DSA is one that 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 the local entity belongs to. the choice of relay DSA for a given community is manually configured by a DSA manager, so you can reach a community you don't have direct connectivity to. this is typically used where the default DSA is a poor choice (for example, because relaying isn't authorised through that DSA) 🫶

a DSA conforming to this specification shall follow these procedures 💅 a DUA may also follow these procedures too, and that gives improvements in some circumstances (like being able to resolve certain queries without chaining). however, this specification does not place requirements on DUAs, so it's totally optional for them 🌈

3. Alternative DSAs 🦋

there's a need to give information on slave copies of data. this can be done using the standard protocol, but with the semantics modified 🧚 it relies on the fact that there may only be a single subordinate reference or cross reference.

if there's a need to include references to both master and slave data (EDB copies) in a referral, then this should be done by specifying a subordinate reference with multiple values. this can't be a standard subordinate reference, since that would only have a single value. so this usage doesn't conflict with standard references 🙌 the first reference is the master copy, and the subsequent references are slave copies ✨

4. Data Model 🍓

in X.500, the unit of mastering data is the entry. a DSA may hold an arbitrary collection of entries. this model gets restricted 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. this is called an Entry Data Block (EDB) 💖 an EDB is named by its parent entry. it contains the relative distinguished names of all 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 the 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, and it will contain two types of entry:

entries for which this DSA is the master.
slave copies of entries that are mastered in another DSA, indicated by a subordinate reference. this copy must be maintained automatically by the DSA holding the master EDB 🔥

so the master EDB is a mix of master entries and entries that are mastered elsewhere but shadowed by the DSA holding the master EDB, entry by entry. other DSAs may hold slave copies of this EDB (slave EDBs), which are replicated in their entirety, directly or indirectly, from the master EDB 💅 this approach has the following advantages:

name resolution is simplified, and performance is improved. ✨
single level searching and listing have good performance, and they're straightforward to implement. in a more general case of applying the standard without sophisticated replication, these operations might need to access very many DSAs, which would be prohibitively expensive 🚀

5. DSA Naming 👑

all DSAs must be named in the DIT, and the master definition of the presentation address must be 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 DSA's address, bestie, because this can get messy fast 💀 It's solved in two ways:

Use of a well known DSA with "root knowledge" 🌸
Naming DSAs in a manner which prevents deadlocks. Right now that's 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. Those policies will be defined in a future RFC 🧚

6. Knowledge Representation 🎀

Knowledge information lives in the DIT, and ngl it would be unreasonable to manage it any other way 💅 It's represented in an entry through knowledge attributes. These are treated separately from everything else in the entry, which are called "user attributes" 🫶 Each entry in a master EDB falls into one of four categories:

The entry is a leaf entry mastered in this EDB, so it only contains user attributes 🍓
The level below has an associated EDB (meaning the DIT keeps going down using the data model of this spec). All attributes of this entry are mastered right here in this entry. The entry will contain an attribute with the name of the DSA that holds the master of the associated EDB. Optionally, it can also contain an attribute holding the names of DSAs that hold slave EDBs. The entry may not hold a subordinate reference attribute. The DIT is followed by using the master and slave attributes 🦋
The entry is mastered in a DSA that doesn't follow this spec. The entry in the EDB will contain a master attribute, which holds a subordinate reference (or cross reference) to the DSA that holds the master entry. The user attributes of the entry are mastered in the DSA the reference points to. The DSA holding the master EDB, which acts as an intermediate shadow for this entry, reads these attributes from the DSA indicated by the reference, so it ends up with a full copy of the entry, using a standard 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, they do get the knowledge attributes copied, and can use them (for example, for modify operations) 💜
The entries at the level below are held in DSAs that don't follow this spec, and all of these are indicated by a set of NSSRs (Non Specific Subordinate References). The NSSRs are stored as an attribute of the entry. The user attributes are either mastered in the EDB. It's 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, they're stored in shadow entries below that point and named by the RDN. If there are NSSRs, they're stored in the entry itself, since there's 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 NSSRs. Here, the NSSR attributes are used to identify these DSAs 🏢 This model of replication isn't tightly integrated with NSSRs. Where there's a mixture of NSSRs and subordinate references at a given point in the DIT, it's handled by giving a single subordinate reference to a DSA that 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. 🖼️

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 references

MasterDSA ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
    SINGLE VALUE

SlaveDSA ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax

SubordinateReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint
    SINGLE VALUE

CrossReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint
    SINGLE VALUE

NonSpecificSubordinateReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint

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 ✨

InternetDSNonLeafObject is for where the level below follows the model defined here, and there's 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 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 it's not present, it should be looked up in the DSA's own entry. For NonSpecificSubordinateReference, the master of the entry will be in the master EDB. For SubordinateReference or CrossReference¹, the DSA which masters the EDB will "spot shadow" the entry by reading it at intervals. This ensures that the master EDB contains a copy of each entry. Single level searching can then be done efficiently where it's not required to access the master copy of the data. DSAs holding slave copies of the EDB don't perform spot shadowing, but they 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 {
        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
                        -- 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
        }

RelativeEntry ::= SEQUENCE {
        RelativeDistinguishedName,
        SET OF Attribute
        }

EDBVersion ::= UTCTime

Figure 2: Replication Protocol

Footnote 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.

Figure 2 defines a ROS operation to support replication. It pulls an entire copy of the EDB. In normal use, the initiator specifies the EDB Version it holds. If the responder has a more recent version, then all of the entries in the EDB are returned. There are options to re-request only the version of EDB held, or to return the full EDB regardless of the version held by the initiator 📦

For large EDBs, transferring an entire EDB in a single operation would lead to very large ROS PDUs. That's a definite scaling limitation 😬 To get around it, the protocol lets an EDB be retrieved in chunks of a size (in number of entries) specified by the 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's less efficient than an incremental technique. When scaling dictates that an incremental technique must be used, it's expected that a suitable standard will be available ✨

An implementation issue that must be noted is how to deal with updates while a multi-operation transfer is in progress. There are two possible approaches (plus a third):

Refuse or block updates until the EDB is transferred. This may cause problems where the rate of update and transfer is high, as it may make updating very difficult (for the manager) 😩
Create a new version of the EDB while retaining the old EDB to complete the bulk transfer. A suitable retention strategy would be to hold an EDB version for as long as the association on which it is being pulled 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 that 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 them². This protocol should only transfer user attributes. In particular, implementation specific attributes, such as those needed to support private access control, should not be transferred. There may be bilateral agreements on access control policy of the information (for example, size limits on listing), which are implemented by (different) system specific techniques 🔐

Footnote 2: QUIPU defines some attributes to register such agreements, but these are probably not appropriate for this specification.

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 DSA's entry, so that support of the extensions defined

here can easily be determined 💖✨

9. Policy on Replication Procedures 🎀

okay so, to be effective, a directory configuration must be laid out 📋 these protocols need to be used inside the framework of a pilot, and service providers making data available for replication have to be part of it 🫶 there is a requirement to manage the replication process, and it's giving organisation 💅 this can be done with a combination of local configuration (to register shadowing agreements) and directory operations that set pointers to the master and slave copies of the data 🦋

10. Use of the Directory by Applications 🌸

bestie, users of the directory have to be careful when replication is available 😭 this is not a change from current use of X.500, but I'm flagging it because it's so important 🚨 normal read requests should allow use of copy information 🧚 now, if the user believes the 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 is prohibited by service controls 🙈

11. Migration and Scaling 📈

the major scaling limit of this approach is the non-incremental update 💀 that puts a limit on the maximum DIT fanout which can be supported ✨ if we take an average entry size of around a thousand bytes, and a maximum reasonable transfer size of tens of megabytes, then the fanout limit of this approach is of order 10 000 🌈 ngl that's a lot of entries, periodt 💜 smaller organisations will tend to be registered geographically (e.g., in the US, by State), so the limit on 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 also using the one that 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 💀🔥

okay bestie, the dramatic truth is that security considerations are not discussed in this memo 😭 so if you're building on this, you'll need to think about security for yourself 🙈🔒

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: S.Kille@CS.UCL.AC.UK

A. ASN.1 Summary and Object Identifier Allocation 🧚💜

there are a few object identifiers needed, and they 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)}

    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)
                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)
        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

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}
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

getEntryDataBlock GetEntryDataBlock ::= 10

eDBVersionError EDBVersionError ::= 10

-- Protocol Definitions

replicationASE APPLICATION-SERVICE-ELEMENT
    OPERATIONS {getEntryDataBlock}
    ::= 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 {
        id-as-acse,
        id-as-idsp }
    ::= id-ac-idsp

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 references

MasterDSA ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax
    SINGLE VALUE

SlaveDSA ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax

SubordinateReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint
    SINGLE VALUE

CrossReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint
    SINGLE VALUE

NonSpecificSubordinateReference ::= ATTRIBUTE
    WITH ATTRIBUTE-SYNTAX AccessPoint

AccessPoint ::= SET {
        ae-title [0] Name,
        address  [2] PresentationAddress OPTIONAL }

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

GetEntryDataBlock ABSTRACT-OPERATION
        ARGUMENT GetEntryDataBlockArgument
        RESULT GetEntryDataBlockResult
        ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}

EDBVersionError ABSTRACT-ERROR
        PARAMETER versionHeld EDBVersion

GetEntryDataBlockArgument ::= SET {
        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
                        -- 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
        }

RelativeEntry ::= SEQUENCE {
        RelativeDistinguishedName,
        SET OF Attribute
        }

EDBVersion ::= UTCTime
END

Figure 3: Summary of the ASN.1 🎀💖

📦 where this page comes from

ietf: rfc1276 1991-11
💖 girlified by claude-haiku-5-5 on 2026-10-17: a language model's rewrite of the original, under its terms