Movatterモバイル変換
[0]ホーム
[RFC Home] [TEXT|PDF|PDF|PS] [Tracker] [IPR] [Info page]
HISTORIC
Network Working Group S.E. Hardcastle-KilleRequests for Comments 1276 University College London November 1991Replication and Distributed Operations extensionsto provide an Internet Directory using X.500Status 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 1991Contents1 Approach 22 Extensions to Distributed Operations 33 Alternative DSAs 44 Data Model 55 DSA Naming 66 Knowledge Representation 67 Replication Protocol 98 New Application Context 129 Policy on Replication Procedures 1210 Use of the Directory by Applications 1211 Migration and Scaling 1212 Security Considerations 1313 Author's Address 13A ASN.1 Summary and Object Identifier Allocation 14List of Figures 1 Knowledge Attributes . . . . . . . . 8 2 Replication Protocol . . . . . . . . 10 3 Summary of the ASN.1 . . . . . . . . 17Hardcastle-Kille Page 1
RFC 1276 Internet Directory Replication November 19911 ApproachThere are a number of non-negotiable requirements which must be metbefore a directory can be deployed on the Internet [HK91b]. Theseproblems are being tackled in the standards arena, but there iscurrently no stable solution. One approach would be to attempt tointercept 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 dealsimpler than the full X.500 approach, and is based on operationalexperience. 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 knowndeficiencies, both in terms of manageability and scalability.Transition to standard approaches are planned when appropriatestandards are available. This RFCwill be obsoleted at this point.Hardcastle-Kille Page 2
RFC 1276 Internet Directory Replication November 19912 Extensions to Distributed OperationsThe distributed operations of X.500 assume that all DUAs and DSAs arefully interconnected with a global network service. For the InternetPilot, 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 isstraightforward. We define the term community as an environment wheredirect (network) communication is possible. Communities may beseparated because they operate different protocols, or because of lackof physical connectivity. Example communities are the DARPA/NSFInternet, and the Janet private X.25 network. A network entity in acommunity is addressed by its Network Address. If two networkentities are in the same community, they can by definitioncommunicate. A community is identified by a set of network addressprefixes. For the approach to be useful, this set should be small(typically 1). For TCP/IP Networks, and X.25 Networks not providingCONS, the approach is described in [HK91a] allows for communities tobe defined for the networks of operational interest.This model can be used to determine whether a pair of applicationentities can communicate. For each entity, determine the presentationaddress (typically by directory lookup). Each network address in thepresentation address will have a single associated community. The setof communities to which each application entity belongs can thus bedetermined. 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 beHardcastle-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 DSAsThere is a need to give information on slave copies of data. This canbe done using the standard protocol, but modifying the semantics.This relies on the fact that there may only be a single subordinatereference or cross reference.If there is a need to include references to master and slave data (EDBcopies) in a referral, then this should be done in a referral byspecifying a subordinate reference with multiple values. This cannotHardcastle-Kille Page 4
RFC 1276 Internet Directory Replication November 1991be a standard subordinate reference, which would only have a singlevalue. Therefore, this usage does not conflict with standardreferences. The first reference is the master copy, and subsequentreferences are slave copies.4 Data ModelThe X.500 data model takes the unit of mastering data as the entry. ADSA may hold an arbitrary collection of entries. We restrict thismodel so that for the replication protocol defined in thisspecification the base unit of replication (shadowing) is the completeset of immediate subordinate entries of a given entry, termed an EntryData Block (EDB). An EDB is named by its parent entry. It containsthe relative distinguished names of all of the children of the entry,and each of the child entries. For each entry, this comprises allattributes of the entry, the relative distinguished name, andknowledge information associated with the entry. If a DSA holds(non-cached) information on an entry, it will hold information on allof its siblings. One DSA will hold a master EDB. This will containtwo 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 entrieswhich are mastered elsewhere and shadowed by the DSA holding themaster EDB on an entry by entry basis. Other DSAs may hold slavecopies of this EDB (slave EDBs), which are replicated in theirentirity directly or indirectly from the master EDB. This approach hasthe 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 19915 DSA NamingAll DSAs must be named in the DIT, and the master definition of thepresentation address stored in this entry. X.500 (including some ofthe extension work) implies that the presentation address informationis extensively replicated (manually). The management overhead impliedby 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 namingDSAs, in conjunction with the replication policy. This will bedefined in a future RFC.6 Knowledge RepresentationKnowledge information is represented in the DIT. It seems unreasonableto manage this by any other means. Knowledge information isrepresented in an entry by use of knowledge attributes. Theseattributes are considered separately from all the other attributes inthe entry which are termed ``user attributes''. Each entry in amaster EDB will be in one of four categories.1. The entry is a leaf entry mastered in this EDB, and so only contains user attributes2. 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 19913. 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 inFigure_1.______________________________________________________________Hardcastle-Kille Page 7
RFC 1276 Internet Directory Replication November 1991InternetDSNonLeafObject ::= 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 referencesMasterDSA ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax SINGLE VALUESlaveDSA ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax 20SubordinateReference ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX AccessPoint SINGLE VALUECrossReference ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX AccessPoint SINGLE VALUENonSpecificSubordinateReference ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX AccessPoint 30AccessPoint ::= 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 1991InternetDSNonLeafObject 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 EDBVersionGetEntryDataBlockArgument ::= SET { 10---------------------------- 1. These references are really the same. The function and valueare the same. The name depends on where the reference is stored. Itmay 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. Thispulls an entire copy of the EDB. In normal use, the initiatorspecifies the EDB Version held. If the responder has a more recentversion, then all of the entries in the EDB are returned. There areoptions to rerequest only the version of EDB held, or to return thefull EDB irrespective of the version held by the initiator.For large EDBs, transfer of an entire EDB in a single operation wouldlead to very large ROS PDUs. This gives a definite scalinglimitation. To overcome this, the protocol allows an EDB to beretrived in chunks of a size (in number of entries) specified by theHardcastle-Kille Page 10
RFC 1276 Internet Directory Replication November 1991initiator. The responder specifies a number which indicates the nextentry to be transferred. The same operation can be used to retrievethe next chunk of the EDB, with EDBVersion and the same integer asparameters.This approach is simple to implement. It is less efficient than anincremental technique. When scaling dictates that an incrementaltechnique must be used, it is expected that a suitable standard willbe available.An implementation issue that must be noted is how to deal with updateswhilst a multi-operation transfer is in progress. There are twopossible 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 theupdate rate is greater than a few changes per day, it is recommendedto configure the master EDB in a DSA which only replicates to oneother DSA. This second DSA can then control its update rate, andsafely perform a large fanout of replications (option 3). The firstDSA will have reasonable availability for modifications (option 1).This protocol will be used by DSAs to obtain copies of EDBs high inthe tree (typically root and national EDBs). DSAs which need thesecopies 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, butthese are probably not appropriate for this specification.Hardcastle-Kille Page 11
RFC 1276 Internet Directory Replication November 1991private access control should not be transferred. There may bebilateral 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 ContextA DSA which follows these procedures will support a newApplicationContext ``Internet DSP'' defined inAppendix A. This willbe stored in the DSAs entry, so that support of the extensions definedhere can easily be determined.9 Policy on Replication ProceduresTo be effective, a directory configuration must be laid out. Theseprotocols will need to be used in the framework of a pilot, andservice providers making available data for replication.There is a requirement to manage the replication process. This can bedone by a combination of local configuration (to register shadowingagreements) and directory operations to set pointers to master andslave copies of the data.10 Use of the Directory by ApplicationsCare must be taken by users of the directory when replication isavailable. This is not a change from current use of X.500, but isnoted here as it is important. Normal read requests should allow useof copy information. If the user of the directory believes thatinformation may be out of date (e.g., because an association could notbe established), then the request should be repeated and use of copydata prohibited by service controls.11 Migration and ScalingThe major scaling limit of this approach is the non-incrementalupdate. This will put a limit on the maximum DIT fanout which can besupported. Given an average entry size of around a thousand bytes,and a maximum reasonable transfer size is tens of megabytes, then theHardcastle-Kille Page 12
RFC 1276 Internet Directory Replication November 1991fanout limit of this approach is of order 10 000. Note that smallerorganisations will tend to be registered geographically (e.g., in theUS, by State), so that the limit of the number of Organisations issomewhat larger. It should be noted that although the replicationtechnique described here is general, it is only intended for highlevels of the DIT. These figures assume this.These techniques do not preclude use of other techniques forreplication. It would be quite reasonable to replicate data usingthis 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 CommentsRFC 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 CommentsRFC 1275, Department of Computer Science, University College London, November 1991.12 Security ConsiderationsSecurity 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.UKHardcastle-Kille Page 13
RFC 1276 Internet Directory Replication November 1991A ASN.1 Summary and Object Identifier AllocationThere_are_a_few_object_identifiers_needed.__These_are_defined_here.____InternetDSP TAGS ::=BEGINIMPORTS 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)}-- Generalat OBJECT IDENTIFIER ::= {internet-dsp at(1)}oc OBJECT IDENTIFIER ::= {internet-dsp oc(2)}-- Object Classes needed for associationHardcastle-Kille Page 14
RFC 1276 Internet Directory Replication November 1991 40id-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 Typesmaster-dsa MasterDSA ::= {at 1}slave-dsa SlaveDSA ::= {at 2}subordinate-reference SubordinateReference ::= {at 3} 50cross-reference CrossReference ::= {at 4}nssr NonSpecificSubordinateReference ::= {at 5}-- Object Classesinternet-ds-non-leaf-object InternetDSNonLeafObject ::= {oc 1}external-ds-object ExternalDSObject ::= {oc 2}-- Operation and Error bindings 60getEntryDataBlock GetEntryDataBlock ::= 10eDBVersionError EDBVersionError ::= 10-- Protocol DefinitionsreplicationASE APPLICATION-SERVICE-ELEMENT OPERATIONS {getEntryDataBlock} 70 ::= id-ase-replicationinternet-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-idspHardcastle-Kille Page 15
RFC 1276 Internet Directory Replication November 1991 90InternetDSNonLeafObject ::= 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 references100MasterDSA ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntax SINGLE VALUESlaveDSA ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX distinguishedNameSyntaxSubordinateReference ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX AccessPoint 110 SINGLE VALUECrossReference ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX AccessPoint SINGLE VALUENonSpecificSubordinateReference ::= ATTRIBUTE WITH ATTRIBUTE-SYNTAX AccessPointAccessPoint ::= SET { 120 ae-title [0] Name, address [2] PresentationAddress OPTIONAL } -- Same definition as X.500 AccessPoint, -- but presentation address is optionalGetEntryDataBlock ABSTRACT-OPERATIONHardcastle-Kille Page 16
RFC 1276 Internet Directory Replication November 1991 ARGUMENT GetEntryDataBlockArgument RESULT GetEntryDataBlockResult ERRORS {nameError,ServiceError,SecurityError,EDBVersionError}130EDBVersionError ABSTRACT-ERROR PARAMETER versionHeld EDBVersionGetEntryDataBlockArgument ::= 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} 150GetEntryDataBlockResult ::= 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 } 160RelativeEntry ::= SEQUENCE { RelativeDistinguishedName, SET OF Attribute }EDBVersion ::= UTCTimeEND___________________Figure_3:__Summary_of_the_ASN.1_____________________Hardcastle-Kille Page 17
[8]ページ先頭