ITU-T X 518 CORR 2-2012 Information technology – Open Systems Interconnection – The Directory Procedures for distributed operation Technical Corrigendum 2 (Study Group 17)《信息技术 开放.pdf

《ITU-T X 518 CORR 2-2012 Information technology – Open Systems Interconnection – The Directory Procedures for distributed operation Technical Corrigendum 2 (Study Group 17)《信息技术 开放.pdf》由会员分享，可在线阅读，更多相关《ITU-T X 518 CORR 2-2012 Information technology – Open Systems Interconnection – The Directory Procedures for distributed operation Technical Corrigendum 2 (Study Group 17)《信息技术 开放.pdf（12页珍藏版）》请在麦多课文档分享上搜索。

1、 International Telecommunication Union ITU-T X.518TELECOMMUNICATION STANDARDIZATION SECTOR OF ITU Corrigendum 2(10/2012) SERIES X: DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY Directory Information technology Open Systems Interconnection The Directory: Procedures for distributed operation

2、Technical Corrigendum 2 Recommendation ITU-T X.518 (2008) Technical Corrigendum 2 ITU-T X-SERIES RECOMMENDATIONS DATA NETWORKS, OPEN SYSTEM COMMUNICATIONS AND SECURITY PUBLIC DATA NETWORKS Services and facilities X.1X.19 Interfaces X.20X.49 Transmission, signalling and switching X.50X.89 Network asp

3、ects X.90X.149 Maintenance X.150X.179 Administrative arrangements X.180X.199 OPEN SYSTEMS INTERCONNECTION Model and notation X.200X.209 Service definitions X.210X.219 Connection-mode protocol specifications X.220X.229 Connectionless-mode protocol specifications X.230X.239 PICS proformas X.240X.259 P

4、rotocol Identification X.260X.269 Security Protocols X.270X.279 Layer Managed Objects X.280X.289 Conformance testing X.290X.299 INTERWORKING BETWEEN NETWORKS General X.300X.349 Satellite data transmission systems X.350X.369 IP-based networks X.370X.379 MESSAGE HANDLING SYSTEMS X.400X.499 DIRECTORY X

5、.500X.599OSI NETWORKING AND SYSTEM ASPECTS Networking X.600X.629 Efficiency X.630X.639 Quality of service X.640X.649 Naming, Addressing and Registration X.650X.679 Abstract Syntax Notation One (ASN.1) X.680X.699 OSI MANAGEMENT Systems management framework and architecture X.700X.709 Management commu

6、nication service and protocol X.710X.719 Structure of management information X.720X.729 Management functions and ODMA functions X.730X.799 SECURITY X.800X.849 OSI APPLICATIONS Commitment, concurrency and recovery X.850X.859 Transaction processing X.860X.879 Remote operations X.880X.889 Generic appli

7、cations of ASN.1 X.890X.899 OPEN DISTRIBUTED PROCESSING X.900X.999 INFORMATION AND NETWORK SECURITY X.1000X.1099 SECURE APPLICATIONS AND SERVICES X.1100X.1199 CYBERSPACE SECURITY X.1200X.1299 SECURE APPLICATIONS AND SERVICES X.1300X.1399 CYBERSECURITY INFORMATION EXCHANGE X.1500X.1599 For further de

8、tails, please refer to the list of ITU-T Recommendations. Rec. ITU-T X.518 (2008)/Cor.2 (10/2012) i INTERNATIONAL STANDARD ISO/IEC 9594-4 RECOMMENDATION ITU-T X.518 Information technology Open Systems Interconnection The Directory: Procedures for distributed operation Technical Corrigendum 2 History

9、 Edition Recommendation Approval Study Group 1.0 ITU-T X.518 1988-11-25 2.0 ITU-T X.518 1993-11-16 7 3.0 ITU-T X.518 1997-08-09 7 3.1 ITU-T X.518 (1997) Technical Cor. 1 2000-03-31 7 3.2 ITU-T X.518 (1997) Amd. 1 2000-03-31 7 3.3 ITU-T X.518 (1997) Technical Cor. 2 2001-02-02 7 4.0 ITU-T X.518 2001-

10、02-02 7 4.1 ITU-T X.518 (2001) Technical Cor. 1 2005-05-14 17 4.2 ITU-T X.518 (2001) Cor. 2 2008-05-29 17 5.0 ITU-T X.518 2005-08-29 17 5.1 ITU-T X.518 (2005) Cor. 1 2008-05-29 17 5.2 ITU-T X.518 (2005) Cor. 2 2011-02-13 17 6.0 ITU-T X.518 2008-11-13 17 6.1 ITU-T X.518 (2008) Cor. 1 2011-02-13 17 6.

11、2 ITU-T X.518 (2008) Cor. 2 2012-10-14 17 7.0 ITU-T X.518 2012-10-14 17 ii Rec. ITU-T X.518 (2008)/Cor.2 (10/2012) FOREWORD The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of telecommunications, information and communication technologies (ICTs).

12、The ITU Telecommunication Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical, operating and tariff questions and issuing Recommendations on them with a view to standardizing telecommunications on a worldwide basis. The World Telecommunication Stan

13、dardization Assembly (WTSA), which meets every four years, establishes the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics. The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1. In some areas of informatio

14、n technology which fall within ITU-Ts purview, the necessary standards are prepared on a collaborative basis with ISO and IEC. NOTE In this Recommendation, the expression “Administration“ is used for conciseness to indicate both a telecommunication administration and a recognized operating agency. C

15、ompliance with this Recommendation is voluntary. However, the Recommendation may contain certain mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the Recommendation is achieved when all of these mandatory provisions are met. The words “shall“ or some othe

16、r obligatory language such as “must“ and the negative equivalents are used to express requirements. The use of such words does not suggest that compliance with the Recommendation is required of any party. INTELLECTUAL PROPERTY RIGHTS ITU draws attention to the possibility that the practice or implem

17、entation of this Recommendation may involve the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of the Recommendation development process.

18、 As of the date of approval of this Recommendation, ITU had not received notice of intellectual property, protected by patents, which may be required to implement this Recommendation. However, implementers are cautioned that this may not represent the latest information and are therefore strongly ur

19、ged to consult the TSB patent database at http:/www.itu.int/ITU-T/ipr/. ITU 2013 All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior written permission of ITU. Rec. ITU-T X.518 (2008)/Cor.2 (10/2012) iii CONTENTS Page 1) Correction of the de

20、fects reported in defect report 375 1 2) Correction of the defects reported in defect report 376 1 3) Correction of the defects reported in defect report 377 1 4) Correction of the defects reported in defect report 380 2 5) Correction of the defects reported in defect report 383 2 6) Correction of t

21、he defects reported in defect report 384 2 7) Correction of the defects reported in defect report 385 3 8) Correction of the defects reported in defect report 386 3 9) Correction of the defects reported in defect report 387 3 ISO/IEC 9594-4:2008/Cor.2:2013 (E) Rec. ITU-T X.518 (2008)/Cor.2 (10/2012)

22、 1 INTERNATIONAL STANDARD RECOMMENDATION ITU-T Information technology Open Systems Interconnection The Directory: Procedures for distributed operation Technical Corrigendum 2 (covering resolution to defect reports 375, 376, 377, 380, 383, 384, 385, 386 and 387) 1) Correction of the defects reported

23、in defect report 375 Change the second paragraph of item 1) in 16.1.4.2 as shown: If the DSA using local knowledge knows, possibly reflected in the appropriate MasterOrShadowAccessPoint value, that chaining is required to the DSA to which an association is lost, it shall elect to send a serviceError

24、 with problem unavailable,. and tThe notification component of the CommonResults data type may be included and shall then contain: a dSAProblem notification attribute with the value id-pr-targetDsaUnavailable; and a distinguishedName attribute having as value the distinguished name of the DSA. Chang

25、e the second paragraph in 16.1.4.4 as shown: Additional information may shall be returned by a DSA in a dSAProblem notification attribute as follows: 2) Correction of the defects reported in defect report 376 In 10.3 replace: a) The originator component conveys the name of the (ultimate) originator

26、of the request unless already specified in the security parameters. If requestor is present in CommonArguments, this argument may be omitted. NOTE 1 Where the originator has alternative names differentiated by context, then the name used as the value of originator shall be the primary distinguished

27、name, if known. Otherwise, authentication and access control based on the value of originator may not work as desired. with: a) The originator component need not be present if the requestor component is present in CommonArguments, if the certification-path component is present in the SecurityParamet

28、ers value, or if requestor information is only made available in the request, but not during the Bind operation. It shall not be present if requestor information is not available. It shall be present, if requestor information is only available as the result of the Bind operation. 3) Correction of th

29、e defects reported in defect report 377 In 10.3, replace: n) authenticationLevel component is optionally supplied when it is required to indicate the manner in which authentication has been carried out. The AuthenticationLevel data type is described in ITU-T Rec. X.501 | ISO/IEC 9594-2. with: n) aut

30、henticationLevel component, when present, shall indicate the authentication level as established during the Bind operation. If this component is absent, a performing DSA shall assume that there has been no authentication (anonymous Bind). This component should be present whenever the requestor has b

31、een authenticated. The AuthenticationLevel data type is described in Rec. ITU-T X.501 | ISO/IEC 9594-2. ISO/IEC 9594-4:2008/Cor.2:2013 (E) 2 Rec. ITU-T X.518 (2008)/Cor.2 (10/2012) 4) Correction of the defects reported in defect report 380 Update 10.3, item v) as shown: v) The dspPaging component ma

32、y be used to request DSP paging. If the bound DSA is different from the initial performer (see 15.5.5) and the bound DSA supports DSP paged results, it may set this component to TRUE to instruct the initial performer to provide DSP paged results. If this component is FALSE (default), the initial per

33、former shall not perform DSP paged result. An initial performer that supports DSP paged results performer shall not forward this component to DSA(s) to which it is sending subrequests. 5) Correction of the defects reported in defect report 383 In 10.3, item h), delete the note and update as shown: h

34、) The referenceType component, when present, shall indicates, to the DSA being asked to perform the operation, what type of knowledge was used to route the request to it. The DSA may therefore be able to detect errors in the knowledge held by the invoker. If such an error is detected, it shall be in

35、dicated by a serviceError with problem invalidReference. ReferenceType is specified fully in 10.7. If the referenceType is absent, the value superior shall be assumed. In 10.3, item u), make the note to normal text: In 10.11, update item b) as shown: b) The aliasedRDNs component indicates how many (

36、if any) of the RDNs in the target object name have been produced by dereferencing an alias. The argument is only present if an alias has been dereferenced. NOTE This component is provided for compatibility with first edition implementations of the Directory. DUAs (and DSAs) implemented according to

37、later editions of the Directory Specifications shall always omit this parameter from the CommonArguments of a subsequent request. In this way, the Directory will not signal an error if aliases dereference to further aliases. This component shall not be included in CommonArguments when implementing a

38、ccording to the second or later editions of these Directory Specifications. 6) Correction of the defects reported in defect report 384 In 10.6, replace the text under the ASN.1 with: Each DSA, which is propagating an operation to another DSA, shall add a new TraceItem to the end of the TraceInformat

39、ion. Each such TraceItem value has the following components: a) the dsa component that shall hold the name of the DSA which is adding the item; b) the targetObject component, when present, shall be the value the DSA adding the item received on targetObject component of the ChainingArguments value of

40、 the incoming request. This parameter shall be omitted if: the request being chained came from a DUA, in which case its implied value is the object or baseObject in the DAP operation; the request is received from an LDAP client, in which case its implied value is the object or baseObject of the LDAP

41、 request; or if its value is the same as the (actual or implied) targetObject in the ChainingArgument of the outgoing request; c) the operationProgress component shall have a value determined as follows: If the incoming request is received from a DUA, the value shall be taken from the operationProgr

42、ess component of the CommonArguments of the DAP request. If this component is absent on the DAP request, the default value notStarted shall be used. If the incoming request is received from an LDAP client, the value notStarted shall be used. If the incoming request is received from a DSA, the value

43、shall be taken from the operationProgress component of the ChainedArguments value. If this component is absent on the request, the default value notStarted shall be used. ISO/IEC 9594-4:2008/Cor.2:2013 (E) Rec. ITU-T X.518 (2008)/Cor.2 (10/2012) 3 7) Correction of the defects reported in defect repo

44、rt 385 In 3.7, add the following definition: 3.7.6 distributed directory: An interconnection set of a DSA and, in addition, one or more DSAs and/or LDAP servers. In 15.1, change the first paragraph as shown: Each DSA is equipped with procedures capable of completely fulfilling all Directory operatio

45、ns. In the case that a DSA contains the entire DIB, all operations are, in fact, completely carried out within that DSA. In the case that the DIB is distributed across a distributed directorymultiple DSAs, the completion of a typical operation is fragmented, with just a portion of that operation car

46、ried out in each of potentially many cooperating DSAs and LDAP servers. 8) Correction of the defects reported in defect report 386 Update 16.1.3 as shown: 16.1.3 Errors At each stage of the processing, an error may be detected during the execution of any sub-procedure. The error identified within th

47、is sub-procedure is normally returned to the requestor as a corresponding protocol error. In this case, the Operation Dispatcher is terminated immediately. In the case that multiple errors are received, one shall be local procedures may selected one of them to be returned (see 12.1 of Rec. ITU-T X.5

48、11 | ISO/IEC 9594-3). Alternatively, a procedure may choose to process errors (e.g., if a serviceError with problem busy is returned to a chained search subrequest) at certain points of operation processing. In this case, the procedure continues with its execution and no error is returned to the req

49、uestor. The conditions under which a DSA may optionally sign the errors returned are specified in clause 12 of Rec. ITU-T X.511 | ISO/IEC 9594-3 in a distributed operation based on error protection requested. 9) Correction of the defects reported in defect report 387 In 10.8 and Annex A, update as shown: MasterOrShadowAccessPoint := SET COMPONENTS OF AccessPoint, category 3 ENUMERATED master (0), shadow (1), writeableCopy (2) DEFAULT master, chainingRequired 5 BOOLEAN DEFAULT FALS