From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc1276.txt | 946 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 946 insertions(+) create mode 100644 doc/rfc/rfc1276.txt (limited to 'doc/rfc/rfc1276.txt') diff --git a/doc/rfc/rfc1276.txt b/doc/rfc/rfc1276.txt new file mode 100644 index 0000000..bac97bc --- /dev/null +++ b/doc/rfc/rfc1276.txt @@ -0,0 +1,946 @@ + + + + + + +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. + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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. + + +1. 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + + 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. + +2. 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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: + +1. Entries for which this DSA is the master. + +2. 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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: + + +1. Use of a well known DSA with ``root knowledge'' + +2. 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. + +1. The entry is a leaf entry mastered in this EDB, and so only + contains user attributes + +2. 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +3. 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). + +4. 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + + +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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + + 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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: + + +1. 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). + +2. 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. + +3. 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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: S.Kille@CS.UCL.AC.UK + + + +Hardcastle-Kille Page 13 + + + + +RFC 1276 Internet Directory Replication November 1991 + + +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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + + 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + + + + + + + + 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 + + + + +RFC 1276 Internet Directory Replication November 1991 + + + 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 + -- cgit v1.2.3