INTERNET-DRAFT S. Legg draft-legg-xed-protocols-04.txt eB2Bcom Intended Category: Standards Track D. Prager November 16, 2006 The XML Enabled Directory: Protocols Copyright (C) The IETF Trust (2006). Status of This Memo By submitting this Internet-draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Technical discussion of this document should take place on the XED developers mailing list . Please send editorial comments directly to the editor . Further information is available on the XED website: www.xmled.info. This Internet-Draft expires on 16 May 2007. Abstract This document defines semantically equivalent Extensible Markup Language (XML) renditions of the Lightweight Directory Access Protocol (LDAP) and X.500 directory protocols for use by the XML Enabled Directory (XED). Legg & Prager Expires 16 May 2007 [Page 1] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Table of Contents 1. Introduction ....................................................2 2. Conventions .....................................................3 3. Uniform LDAP Specification ......................................3 3.1. Remediation of AttributeValue ..............................4 3.2. Remediation of AssertionValue ..............................5 3.3. Remediation of AttributeDescription ........................6 3.4. Remediation of LDAPString ..................................6 3.5. Importation of Pre-existing Definitions ....................7 3.6. Remediation of Controls ....................................7 3.7. Remediation of Extended Operations .........................9 3.8. Other Changes .............................................11 4. XLDAP ..........................................................12 4.1. XLDAP Over TCP/IP .........................................14 4.2. XLDAP Over SOAP 1.1 .......................................15 4.3. Relationship to DSMLv2 ....................................15 5. XIDM ...........................................................16 6. Security Considerations ........................................18 7. Acknowledgements ...............................................18 8. IANA Considerations ............................................18 9. References .....................................................18 9.1. Normative References ......................................18 9.2. Informative References ....................................20 Appendix A. ASN.1 for Uniform LDAP ................................21 Appendix B. ASN.1 for XED Protocol Elements .......................29 Appendix C. ASN.X for Uniform LDAP ................................30 Appendix D. ASN.X for XED Protocol Elements .......................54 1. Introduction This document defines semantically equivalent Extensible Markup Language (XML) [XML10][XML11] renditions of the Lightweight Directory Access Protocol (LDAP) [LDAP] and X.500 [X.500] directory protocols for use by the XML Enabled Directory (XED) [XED]. The Internet Directly Mapped (IDM) protocol [X.519] permits X.500 protocol operations to be exchanged between directory agents using TCP/IP [TCP] with minimal encapsulation, bypassing (and dispensing with) the ROSE, ACSE, Presentation, Session and Transport layers of the Open Systems Interconnection (OSI) model [OSI]. Protocol operations in the IDM protocol are encoded according to the Basic Encoding Rules (BER) [X.690] of Abstract Syntax Notation One (ASN.1) [X.680]. Section 5 defines a new exclusively XML-based protocol, the XML Internet Directly Mapped (XIDM) protocol, which differs from the IDM protocol only in that the protocol operations are encoded using the Robust XML Encoding Rules (RXER) [RXER] instead Legg & Prager Expires 16 May 2007 [Page 2] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 of BER. Whilst the IDM protocol is amenable to a simple substitution of the encoding rules to create a uniformly XML formatted protocol operation, LDAP is not, due to discontinuities in the encoding, i.e., places where transfer syntax transitions occur (typically from BER to LDAP-specific [SYNTAX] and back to BER). The discontinuities are the result of directory data being conveyed as the content of ASN.1 OCTET STRINGs. A straight application of RXER to an LDAP operation would inconveniently force attribute values, among other things, to be represented as hexadecimal strings. Section 3 describes a transformation of the LDAP ASN.1 specification [PROT] that creates a new specification without the discontinuities called Uniform LDAP. Essentially, the bland OCTET STRING [X.680] containers for directory data items in LDAP are replaced by the open types [X.681] and specific types used by X.500. The XML Lightweight Directory Access Protocol (XLDAP) defined in Section 4 is the result of applying RXER to instances of the message data types of Uniform LDAP. Section 4 also defines two transports for Uniform LDAP messages. Apart from the change in syntax, XLDAP is semantically equivalent to LDAP. Since the XED protocols are algorithmically generated from the LDAP and X.500 specifications, all future extensions to LDAP and X.500 automatically acquire a XED protocol representation. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [BCP14]. The key word "OPTIONAL" is exclusively used with its ASN.1 meaning. This document makes use of definitions from the XML Information Set (Infoset) [ISET]. In particular, information item property names follow the Infoset convention of being shown in square brackets, e.g., [local name]. In the sections that follow, the term "element" shall be taken to mean an Infoset element information item. Throughout this document the term "attribute" is taken to mean a directory attribute, unless it is qualified as an XML attribute. 3. Uniform LDAP Specification The OCTET STRING fields in the LDAP specification each serve one of two purposes; to contain the encodings of directory data values of Legg & Prager Expires 16 May 2007 [Page 3] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 differing data types (e.g., attribute values, assertion values, control values), and to contain an LDAP-specific string encoding of a data value of a fixed data type (e.g., attribute type, distinguished name). In both cases the encoding of the directory data values is disconnected from the encoding of the surrounding protocol message (the transfer syntax of the directory data values and the transfer syntax of the surrounding protocol message are typically quite different) and the relationships that determine which data type to use (e.g., the data type of an attribute value is determined by its associated attribute type) are not specified in a way that is machine-processable. As a consequence, off-the-shelf ASN.1 tools are unable to treat directory data in protocol messages as anything other than raw octets. This defect is addressed by transforming the LDAP specification into a form, called the Uniform LDAP specification, which faciliates the uniform encoding of protocol message and directory data in a single syntax (e.g., XML). This is done by replacing the OCTET STRING fields in the LDAP specification, as detailed in the subsections that follow. OCTET STRINGs that contain directory data values of fixed data types are replaced by the associated fixed data type. OCTET STRINGs that contain directory data values of varying data types are replaced by open types. Open types permit the directory data values to be seamlessly encoded in the same syntax as the surrounding protocol message. Furthermore, ASN.1 table constraints [X.682] can be applied so that the actual data type of a value of an open type can be determined programmatically. Derivative works of the original LDAP specification can also be remediated for use by XED by making the same transformations. The final result of applying these transformations is the XED-Uniform-LDAP ASN.1 module presented in Appendix A. The equivalent Abstract Syntax Notation X (ASN.X)[ASN.X] representation of the Uniform LDAP specification is presented in Appendix C. Since Uniform LDAP protocol messages and the directory data they contain are encoded in the same syntax throughout, LDAP transfer encoding options [TRANSFER] are ignored if present. 3.1. Remediation of AttributeValue The definition of AttributeValue is removed and each reference to AttributeValue is replaced with the following, where Legg & Prager Expires 16 May 2007 [Page 4] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 is replaced with the identifier of the preceding component of the AttributeDescription ASN.1 type: ATTRIBUTE.&Type ({SupportedAttributes}{@.type}) In addition, the reference to AttributeDescription in that preceding component is replaced with: SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL } ATTRIBUTE.&id equates to the OBJECT IDENTIFIER of an attribute type. ATTRIBUTE.&Type is an open type. The constraint on ATTRIBUTE.&Type restricts the ASN.1 type in the open type to be the syntax of the attribute indicated by ATTRIBUTE.&id. ATTRIBUTE and SupportedAttributes are defined in X.501 [X.501]. 3.2. Remediation of AssertionValue The definition of MatchingRuleId is removed and the definition of MatchingRuleAssertion is replaced with the following definition: MatchingRuleAssertion ::= SEQUENCE { matchingRule [1] MATCHING-RULE.&id OPTIONAL, type [2] AttributeDescription OPTIONAL, matchValue [3] MATCHING-RULE.&AssertionType, dnAttributes [4] BOOLEAN DEFAULT FALSE } MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching rule. MATCHING-RULE.&AssertionType is an open type. The relationship between the value of the matchingRule component, the value of the type component and the ASN.1 type in the open type (i.e., the syntax of the assertion value) is not expressible in ASN.1 constraint notation. The relationship defined by LDAP applies [PROT]. MATCHING-RULE is defined in X.501 [X.501]. The definition of AssertionValue is removed and each remaining reference to AssertionValue is replaced with the following, where is replaced with the identifier of the preceding component of the AttributeDescription ASN.1 type: ATTRIBUTE.&equality-match.&AssertionType ({SupportedAttributes}{@.type}) In addition, the reference to AttributeDescription in that preceding Legg & Prager Expires 16 May 2007 [Page 5] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 component is replaced with: SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL } ATTRIBUTE.&equality-match.&AssertionType is an open type. The constraint on ATTRIBUTE.&equality-match.&AssertionType restricts the ASN.1 type in the open type to be the syntax of the equality matching rule of the attribute indicated by ATTRIBUTE.&id. 3.3. Remediation of AttributeDescription To maintain consistency in the structure of attribute descriptions throughout the Uniform LDAP specification the definition of AttributeDescription is replaced with the following definition: AttributeDescription ::= SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL } The attribute type in an LDAP AttributeDescription is represented as the OBJECT IDENTIFIER of that attribute type in the type component of a Uniform LDAP AttributeDescription. Each attribute option in an LDAP AttributeDescription is represented as a separate UTF8String value in a Uniform LDAP AttributeDescription. The semi-colons that separate attribute options in an LDAP AttributeDescription are not present in any of the UTF8String values. 3.4. Remediation of LDAPString Some directory constructs have ASN.1 types but are represented in LDAP messages as a UTF-8 character string encoding wrapped in an OCTET STRING, i.e., LDAPString. Uniform LDAP replaces these uses of LDAPString with the underlying ASN.1 type. The definition of LDAPOID is replaced with the following definition: LDAPOID ::= OBJECT IDENTIFIER The definition of LDAPDN is replaced with the following definition: LDAPDN ::= DistinguishedName This change aligns the encoding of distinguished names in the protocol messages with the RXER encoding of attribute values of Legg & Prager Expires 16 May 2007 [Page 6] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 attributes with the DN syntax [SYNTAX]. The definition of RelativeLDAPDN is replaced with the following definition: RelativeLDAPDN ::= RelativeDistinguishedName DistinguishedName and RelativeDistinguishedName are defined in X.501 [X.501]. The remaining uses of LDAPString are represented naturally as UTF-8 character strings, therefore the definition of LDAPString is replaced with the following definition: LDAPString ::= UTF8String 3.5. Importation of Pre-existing Definitions ATTRIBUTE, MATCHING-RULE, RelativeDistinguishedName, DistinguishedName and SupportedAttributes need to be imported from the X.500 InformationFramework module, therefore the following import statement is added to the Uniform LDAP specification following the BEGIN keyword: IMPORTS ATTRIBUTE, MATCHING-RULE RelativeDistinguishedName, DistinguishedName, SupportedAttributes FROM InformationFramework { joint-iso-itu-t ds(5) module(1) informationFramework(1) 4 } ; 3.6. Remediation of Controls LDAP controls contain an OCTET STRING control value whose content is determined by an associated control type. The control type is an OBJECT IDENTIFIER represented as a string in LDAP. The data type of the control value is typically specified as an ASN.1 type, though this is not a requirement of LDAP. Controls have no counterpart in X.500, therefore the CONTROL information object class is defined in this document to allow specific control types to be programmatically linked to specific control value data types. Legg & Prager Expires 16 May 2007 [Page 7] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 CONTROL ::= CLASS { &type OBJECT IDENTIFIER, &RequestValue OPTIONAL, &ResponseValue OPTIONAL } The &type field of a CONTROL object specifies the OBJECT IDENTIFIER identifying the control (the control type). The &RequestValue field of a CONTROL object specifies an ASN.1 type describing the data type of the control value for that control in an LDAP request message. If the control value is required to be absent in a request, then the &RequestValue field is absent. The &ResponseValue field of a CONTROL object specifies an ASN.1 type describing the data type of the control value for that control in an LDAP response message. If the control value is required to be absent in a response, then the &RequestValue field is absent. If the data type of a control value is not an ASN.1 type, and cannot be represented as an ASN.1 type definition [RXEREI], then the data type of the control value is taken to be OCTET STRING. A mechanism for representing an XML Schema named type [XSD0], a RELAX NG named pattern [RNG] or a DTD element type declaration [XML10][XML11] as an ASN.1 type definition is specified elsewhere [RXEREI]. If a control uses different OBJECT IDENTIFIERs in the request and response, then it is necessarily represented by two CONTROL objects. Definitions of CONTROL objects for controls already defined is out of scope for this document, however such objects can be readily synthesized from the specification of a control. The extensible SupportedControls information object set notionally contains CONTROL objects for all the controls known to an implementation. SupportedControls CONTROL ::= { ... } In order to allow automated determination of the control value data type from the control type, the definition of the Control ASN.1 type in LDAP is replaced with the following definition in Uniform LDAP: Control ::= SEQUENCE { controlType CONTROL.&type({SupportedControls}), criticality BOOLEAN DEFAULT FALSE, controlValue CHOICE { request [0] CONTROL.&RequestValue Legg & Prager Expires 16 May 2007 [Page 8] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 ({SupportedControls}{@controlType}), response [1] CONTROL.&ResponseValue ({SupportedControls}{@controlType}) } OPTIONAL } 3.7. Remediation of Extended Operations LDAP extended operation requests contain an OCTET STRING request value whose content is determined by an associated request name. The request name type is an OBJECT IDENTIFIER represented as a string in LDAP. LDAP extended operation responses and intermediate responses contain an OCTET STRING response value whose content is determined by an associated response name. The response name type is an OBJECT IDENTIFIER represented as a string in LDAP. The data type of the request or response value is typically specified as an ASN.1 type, though this is not a requirement of LDAP. Extended operations and intermediate responses have no counterpart in X.500, therefore the LDAP-EXTENDED-REQUEST, LDAP-EXTENDED-RESPONSE and LDAP-INTERMEDIATE-RESPONSE information object classes are defined in this document to allow specific request names to be programmatically linked to specific request value data types, and to allow specific response names to be programmatically linked to specific response value data types. LDAP-EXTENDED-REQUEST ::= CLASS { &name OBJECT IDENTIFIER, &Value OPTIONAL } LDAP-EXTENDED-RESPONSE ::= CLASS { &name OBJECT IDENTIFIER, &Value OPTIONAL } LDAP-INTERMEDIATE-RESPONSE ::= CLASS { &name OBJECT IDENTIFIER, &Value OPTIONAL } The &name field of an LDAP-EXTENDED-REQUEST object specifies the OBJECT IDENTIFIER identifying the extended operation request. The &Value field of an LDAP-EXTENDED-REQUEST object specifies an ASN.1 type describing the data type of the request value for that request. If the request value is required to be absent in a request, then the &Value field is absent. Legg & Prager Expires 16 May 2007 [Page 9] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 The &name field of an LDAP-EXTENDED-RESPONSE object specifies the OBJECT IDENTIFIER identifying the extended operation response. The &Value field of an LDAP-EXTENDED-RESPONSE object specifies an ASN.1 type describing the data type of the response value for that response. If the response value is required to be absent in a response, then the &Value field is absent. The &name field of an LDAP-INTERMEDIATE-RESPONSE object specifies the OBJECT IDENTIFIER identifying the intermediate response. The &Value field of an LDAP-INTERMEDIATE-RESPONSE object specifies an ASN.1 type describing the data type of the response value for that intermediate response. If the response value is required to be absent in an intermediate response, then the &Value field is absent. If the data type of a request or response value is not an ASN.1 type, and cannot be represented as an ASN.1 type definition [RXEREI], then the data type of the value is taken to be OCTET STRING. A mechanism for representing an XML Schema named type [XSD0], a RELAX NG named pattern [RNG] or a DTD element type declaration [XML10][XML11] as an ASN.1 type definition is specified elsewhere [RXEREI]. Definitions of LDAP-EXTENDED-REQUEST, LDAP-EXTENDED-RESPONSE and LDAP-INTERMEDIATE-RESPONSE objects for extended operations and intermediate responses already defined is out of scope for this document, however such objects can be readily synthesized from the specification of an extended operation or intermediate response. The extensible SupportedRequests information object set notionally contains LDAP-EXTENDED-REQUEST objects for all the extended operation requests known to an implementation. The extensible SupportedResponses information object set notionally contains LDAP-EXTENDED-RESPONSE objects for all the extended operation responses known to an implementation. The extensible SupportedIntermediateResponses information object set notionally contains LDAP-INTERMEDIATE-RESPONSE objects for all the intermediate responses known to an implementation. SupportedRequests LDAP-EXTENDED-REQUEST ::= { ... } SupportedResponses LDAP-EXTENDED-RESPONSE ::= { ... } SupportedIntermediateResponses LDAP-INTERMEDIATE-RESPONSE ::= { ... } In order to allow automated determination of the request value data type from the request name in an extended operation, the definition Legg & Prager Expires 16 May 2007 [Page 10] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 of the ExtendedRequest ASN.1 type in LDAP is replaced with the following definition in Uniform LDAP: ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAP-EXTENDED-REQUEST.&name ({SupportedRequests}), requestValue [1] LDAP-EXTENDED-REQUEST.&Value ({SupportedRequests}{@requestName}) OPTIONAL } In order to allow automated determination of the response value data type from the response name in an extended operation, the definition of the ExtendedResponse ASN.1 type is replaced with the following definition: ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAP-EXTENDED-RESPONSE.&name ({SupportedResponses}) OPTIONAL, responseValue [11] LDAP-EXTENDED-RESPONSE.&Value ({SupportedResponses}{@responseName}) OPTIONAL } In order to allow automated determination of the response value data type from the response name in an intermediate response, the definition of the IntermediateResponse ASN.1 type is replaced with the following definition: IntermediateResponse ::= [APPLICATION 25] SEQUENCE { responseName [0] LDAP-INTERMEDIATE-RESPONSE.&name ({SupportedIntermediateResponses}) OPTIONAL, responseValue [1] LDAP-INTERMEDIATE-RESPONSE.&Value ({SupportedIntermediateResponses} {@responseName}) OPTIONAL } The definitions for the CONTROL, LDAP-EXTENDED-REQUEST, LDAP-EXTENDED-RESPONSE and LDAP-INTERMEDIATE-RESPONSE information object classes and the SupportedControls, SupportedRequests, SupportedResponses and SupportedIntermediateResponses information object sets are added to the end of the Uniform LDAP specification. 3.8. Other Changes The Absolute True and False Filters extension to LDAP [FILTER] effectively removes the SIZE constraint on the "and" and "or" components of the LDAP Filter ASN.1 type. These two SIZE constraints are removed in the Uniform LDAP specification. Legg & Prager Expires 16 May 2007 [Page 11] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 4. XLDAP A protocol message of the XML Lightweight Directory Access Protocol (XLDAP) is the RXER encoding of a value of the ldapMessage top-level NamedType from the XED-Protocols ASN.1 module presented in Appendix B (which is the RXER encoding of an abstract value of the LDAPMessage type from the XED-Uniform-LDAP module encapsulated in an element with the [local name] "LDAPMessage" and the [namespace name] "urn:ietf:params:xml:ns:xed"), exchanged over either of the transports defined in Sections 4.1 and 4.2. Aside: The specification for RXER [RXER] introduces the notion of an ASN.1 NamedType having a value that can be encoded. Aside: Each top-level NamedType in the XED-Protocols module is subject to a TYPE-AS-VERSION encoding instruction [RXEREI], which means that the XML attributes of the root element of the encoding of an XLDAP protocol message should contain an xsi:type XML attribute with a value that is a qualified name for the expanded name [XMLNS10] of the LDAPMessage ASN.1 type from the XED-Uniform-LDAP module. This expanded name will have the namespace name "urn:ietf:params:xml:ns:xed-uldap" and the local name "LDAPMessage". It is intended that future editions of XED will use the same expanded name for the protocol message element, but that the value of the xsi:type XML attribute will be a qualified name for the expanded name of the LDAPMessage ASN.1 type (or its successor) in that future edition's version of the XED-Uniform-LDAP module. Any future version of the XED-Uniform-LDAP module is expected to use a different target namespace. An RXER decoder using the first edition specification would ignore the xsi:type XML attribute, and simply apply the ASN.1 extensibility rules, if it receives an encoding from a later edition. Implementations using compatible XML Schema translations of this and subsequent revisions of the XED-Uniform-LDAP ASN.1 module would use the value of the xsi:type XML attribute to select the appropriate version for validation purposes. The equivalent ASN.X representation of the XED-Protocols module is provided in Appendix D. This first edition of the XLDAP specification is semantically equivalent to LDAP version 3, therefore the version field of an XLDAP BindRequest message SHOULD be set to 3. Implementations of XLDAP MUST support "XLDAP Over TCP/IP" and MAY support "XLDAP Over SOAP 1.1". Example Legg & Prager Expires 16 May 2007 [Page 12] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 This is an example of an XLDAP search operation. 0 0.9.2342.19200300.100.1.25 com 0.9.2342.19200300.100.1.25 example wholeSubtree derefInSearching 100 5 false 2.5.4.0 2.5.6.6 2.5.4.4 Smith Legg & Prager Expires 16 May 2007 [Page 13] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 4.1. XLDAP Over TCP/IP This section defines a simple mapping of XLDAP protocol messages onto TCP/IP [TCP]. It is the same as the mapping onto TCP/IP used by the IDM protocol. An XLDAP protocol message is encoded as an XML document with the protocol message element as its root element. The octets of the XML document are partitioned into one or more fragments. Each fragment is placed in a segment to be sent over the TCP/IP connection. Each segment has a header followed by the octets of the fragment. The number and size of the fragments resulting from the partitioning of the encoding of the protocol message are at the discretion of the sender and carry no significance. All fragments of a particular protocol message MUST be sent (in order) before another protocol message is sent. The format for a segment is as follows: +-----------+-----------+-------------------+-------------------+ | version | final | length | data | | (1 octet) | (1 octet) | (4 octets) | (length octets) | +-----------+-----------+-------------------+-------------------+ The version field indicates the version of the mapping onto TCP/IP. The version described in this document is indicated by the value 1. All segments on a TCP/IP connection SHALL have the same value for the version. The final field SHALL be 1 if the data field contains the final or only fragment of the encoding of the XLDAP protocol message, otherwise the final field SHALL be 0. The length field indicates the size of the data field in number of octets. It is sent in network byte order as a 32 bit unsigned integer with more significant octets preceding less significant octets. The minimum permitted value of length is 1. The data field holds the next fragment of the XLDAP protocol message being sent, or the entire encoding of the XLDAP protocol message if it is being sent as one fragment. Legg & Prager Expires 16 May 2007 [Page 14] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Being relatively short, the entire XLDAP protocol message will typically be sent in one segment. 4.2. XLDAP Over SOAP 1.1 This section defines a binding of XLDAP to SOAP version 1.1 [SOAP] using the HTTP binding. The value of the SOAPAction HTTP request header field SHALL be "urn:ietf:params:xml:ns:xed". No SOAP headers are defined for XLDAP over SOAP 1.1. XLDAP protocol messages can be categorized as either Uniform LDAP requests or Uniform LDAP responses. A Uniform LDAP request is mapped onto a SOAP request message. The SOAP Body element SHALL contain the protocol message element as its only child element. A Uniform LDAP response other than a search response is mapped onto a SOAP response message. The SOAP Body element SHALL contain the protocol message element as its only child element. The result of a Uniform LDAP search is a sequence of one or more protocol messages, each containing a value of SearchResultEntry, SearchResultReference or, for the final message, SearchResultDone. The result of a Uniform LDAP search is mapped onto a SOAP response message where the SOAP Body element contains each of the protocol message elements making up the search result, i.e., the multiple response messages for a search are concatenated into a single SOAP response. Directory processing errors are reported as Uniform LDAP responses. SOAP processing errors are reported using the SOAP Fault element. 4.3. Relationship to DSMLv2 The Directory Services Markup Language v2.0 (DSMLv2) [DSML] is an alternative protocol for accessing an LDAP or X.500 directory. Attribute values are represented in DSMLv2 as simple content, either a UTF-8 string (the usual LDAP-specific ad-hoc string encoding), a base64 [MIME] string or a URI. An attribute value in XML format must either have its markup escaped with XML character references or CDATA sections, or else must be placed in a separate URI-referenced document from which the client needs to fetch the value later. Attribute values with structure (e.g., schema descriptions) are Legg & Prager Expires 16 May 2007 [Page 15] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 normally represented as LDAP-specific string encodings instead of a more useful markup format. In XLDAP, attribute values with non- trivial syntaxes, including new attribute syntaxes whose data type is defined in terms of an XML Schema, a RELAX NG grammar or a DTD, are naturally represented as markup in the protocol. No escaping or other indirection is required. Control values and the request and response values of extended operations are typically represented in DSMLv2 as the base64 encodings of the BER encodings of the values. In XLDAP the control values and the request and response values of extended operations are all directly represented as markup. 5. XIDM The mapping of the X.500 protocols into XIDM is identical to the mapping of these protocols into IDM [X.519]. The ASN.1 data types of XIDM Protocol Data Units (PDUs) are exactly those of the IDM PDUs [X.519]. The difference between XIDM and IDM is in the choice of transfer syntax (RXER instead of BER). Each XIDM PDU is the RXER encoding of a value of one of the top-level NamedType definitions [RXEREI] from the XED-Protocols ASN.1 module presented in Appendix B. Aside: The specification for RXER [RXER] introduces the notion of an ASN.1 NamedType having a value that can be encoded. The RXER encoding is then mapped to TCP/IP [TCP] in the manner prescribed in X.519 [X.519] for the encodings of IDM PDUs (which is the same as the mapping defined in Section 4.1 for "XLDAP Over TCP/IP"). The mapping of the Directory Access Protocol (DAP) onto XIDM is called the XML Directory Access Protocol over TCP/IP (X-DAP-IP). An X-DAP-IP operation is the RXER encoding of a value of the dap-idm-pdu top-level NamedType from the XED-Protocols module (which is the RXER encoding of an abstract value of the DAP-IDM-PDUs ASN.1 type encapsulated in an element with the [local name] "DAP-IDM-PDU" and the [namespace name] "urn:ietf:params:xml:ns:xed"). The mapping of the Directory System Protocol (DSP) onto XIDM is called the XML Directory System Protocol over TCP/IP (X-DSP-IP). An X-DSP-IP operation is the RXER encoding of a value of the dsp-idm-pdu top-level NamedType from the XED-Protocols module (which is the RXER encoding of an abstract value of the DSP-IDM-PDUs ASN.1 type encapsulated in an element with the [local name] "DSP-IDM-PDU" and the [namespace name] "urn:ietf:params:xml:ns:xed"). Legg & Prager Expires 16 May 2007 [Page 16] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 The mapping of the Directory Information Shadowing Protocol (DISP) onto XIDM is called the XML Directory Information Shadowing Protocol over TCP/IP (X-DISP-IP). An X-DISP-IP operation is the RXER encoding of a value of the disp-idm-pdu top-level NamedType from the XED-Protocols module (which is the RXER encoding of an abstract value of the DISP-IDM-PDUs ASN.1 type encapsulated in an element with the [local name] "DISP-IDM-PDU" and the [namespace name] "urn:ietf:params:xml:ns:xed"). The mapping of the Directory Operational Binding Protocol (DOP) onto XIDM is called the XML Directory Operational Binding Protocol over TCP/IP (X-DOP-IP). An X-DOP-IP operation is the RXER encoding of a value of the dop-idm-pdu top-level NamedType from the XED-Protocols module (which is the RXER encoding of an abstract value of the DOP-IDM-PDUs ASN.1 type encapsulated in an element with the [local name] "DOP-IDM-PDU" and the [namespace name] "urn:ietf:params:xml:ns:xed"). Aside: Each top-level NamedType in the XED-Protocols module is subject to a TYPE-AS-VERSION encoding instruction [RXEREI] which means that the XML attributes of the root element of the encoding of an XIDM PDU should contain an xsi:type XML attribute with a value that is a qualified name for the expanded name of the ASN.1 type of the IDM PDU. This expanded name will have the namespace name "http://xmled.info/ns/X.500/4/DirectoryIDMProtocols" or "http://xmled.info/ns/X.500/5/DirectoryIDMProtocols" (the target namespaces allocated [XEDNS] to the DirectoryIDMProtocols module [X.519-4][X.519] from the fourth and fifth edition of X.500, respectively) and the local name DAP-IDM-PDUs, DSP-IDM-PDUs, DISP-IDM-PDUs or DOP-IDM-PDUs, as appropriate. It is intended that the expanded names of the XIDM root elements will remain unchanged in any revision of the XED-Protocols module that references a future edition of the DirectoryIDMProtocols module. However, the value of the xsi:type XML attribute on the these elements will be a qualified name for the expanded name of the specific IDM PDU ASN.1 type (or its successor) in the future edition of the DirectoryIDMProtocols module. The ASN.1 modules of any future edition of X.500 are expected to be allocated different target namespaces. An RXER decoder using the fourth edition X.500 specification would ignore the xsi:type XML attribute, and simply apply the ASN.1 extensibility rules, if it receives an encoding from a later edition. Implementations using compatible XML Schema translations of the fourth, fifth and subsequent editions of the X.500 ASN.1 modules would use the value of the xsi:type XML attribute to select the appropriate version for validation purposes. The DirectoryIDMProtocols module first appears in the fourth Legg & Prager Expires 16 May 2007 [Page 17] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 edition of X.500. The equivalent ASN.X representation of the XED-Protocols module is provided in Appendix D. Since the IDM protocol does not itself support any form of negotiation of the transfer syntax, communication end points for the XIDM protocol must be distinct, with different ports and/or different IP addresses. XIDM end point address formats are for further study. 6. Security Considerations Since XLDAP is derived from LDAP the security considerations that apply to LDAP apply equally to XLDAP. XLDAP encodes all attribute values using RXER, which does not necessarily enable an original BER encoding of an attribute value to be recovered. Such recovery is needed for the verification of digital signatures. XLDAP MUST NOT be used by applications requiring such recovery. When interpreting security-sensitive fields, and in particular fields used to grant or deny access, implementations MUST ensure that any comparisons are done on the underlying abstract value, regardless of the particular encoding used. 7. Acknowledgements The technology described in this document is the product of a research project begun jointly by Adacel Technologies Limited and Deakin University, and subsequently refined and completed by eB2Bcom. 8. IANA Considerations The Internet Assigned Numbers Authority (IANA) is requested to register two new XML namespaces in accordance with RFC 3688 [XMLREG]. URI: urn:ietf:params:xml:ns:xed URI: urn:ietf:params:xml:ns:xed-uldap Registrant Contact: Steven Legg XML: None 9. References 9.1. Normative References Legg & Prager Expires 16 May 2007 [Page 18] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 [TCP] Postel, J., "TRANSMISSION CONTROL PROTOCOL", RFC 793, September 1981. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [LDAP] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006. [PROT] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. [FILTER] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP) Absolute True and False Filters", RFC 4526, June 2006. [XED] Legg, S. and D. Prager, "The XML Enabled Directory", draft-legg-xed-roadmap-xx.txt, a work in progress, October 2006. [RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)", draft-legg-xed-rxer-xx.txt, a work in progress, October 2006. [RXEREI] Legg, S., "Encoding Instructions for the Robust XML Encoding Rules (RXER)", draft-legg-xed-rxer-ei-xx.txt, a work in progress, October 2006. [XEDNS] Legg, S., "The XML Enabled Directory: Amended Modules" draft-legg-xed-amend-xx.txt, a work in progress, to be published. [TRANSFER] Legg, S., "Lightweight Directory Access Protocol (LDAP): Transfer Encoding Options", draft-legg-ldap-transfer-xx.txt, a work in progress, August 2006. [X.500] ITU-T Recommendation X.500 (08/05) | ISO/IEC 9594-1:2005, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services [X.501] ITU-T Recommendation X.501 (08/05) | ISO/IEC 9594-2:2005, Information technology - Open Systems Interconnection - Legg & Prager Expires 16 May 2007 [Page 19] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 The Directory: Models [X.519-4] ITU-T Recommendation X.519 (02/01) | ISO/IEC 9594-5:2001, Information technology - Open Systems Interconnection - The Directory: Protocol specifications [X.519] ITU-T Recommendation X.519 (08/05) | ISO/IEC 9594-5:2005, Information technology - Open Systems Interconnection - The Directory: Protocol specifications [X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. [X.681] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2, Information technology - Abstract Syntax Notation One (ASN.1): Information object specification. [X.682] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3, Information technology - Abstract Syntax Notation One (ASN.1): Constraint specification. [XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml-20060816, August 2006. [XML11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml11-20060816, August 2006. [XMLNS10] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml-names-20060816, August 2006. [ISET] Cowan, J. and R. Tobin, "XML Information Set (Second Edition)", W3C Recommendation, http://www.w3.org/TR/2004/REC-xml-infoset-20040204, February 2004. [SOAP] Box, D., et al, "Simple Object Access Protocol (SOAP) 1.1", W3C Note, http://www.w3.org/TR/2000/NOTE- SOAP-20000508, May 2000. 9.2. Informative References Legg & Prager Expires 16 May 2007 [Page 20] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [SYNTAX] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. [ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", draft-legg-xed-asd-xx.txt, a work in progress, October 2006. [OSI] ITU-T Recommendation X.200 (1994) | ISO/IEC 7498-1:1994, Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model. [X.690] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). [XSD0] Fallside, D., and P. Walmsley, "XML Schema Part 0: Primer Second Edition", W3C Recommendation, http://www.w3.org/TR/2004/REC-xmlschema-0-20041028/, October 2004. [RNG] Clark, J. and M. Makoto, "RELAX NG Tutorial", OASIS Committee Specification, http://www.oasis- open.org/committees/relax-ng/tutorial-20011203.html, December 2001. [DSML] "Directory Services Markup Language v2.0", OASIS Standard, http://www.oasis-open.org/committees/dsml/docs/DSMLv2.doc, December 2001. Appendix A. ASN.1 for Uniform LDAP The ASN.1 module in this appendix is the result of applying the transformation described in this document to the original LDAP ASN.1 specification. This appendix is normative. XED-Uniform-LDAP { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) ds(5) module(1) uniform-ldap(2) } Legg & Prager Expires 16 May 2007 [Page 21] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 -- Copyright (C) The IETF Trust (2006). This version of -- this ASN.1 module is part of RFC XXXX; see the RFC itself -- for full legal notices. DEFINITIONS IMPLICIT TAGS EXTENSIBILITY IMPLIED ::= BEGIN IMPORTS ATTRIBUTE, MATCHING-RULE, RelativeDistinguishedName, DistinguishedName, SupportedAttributes FROM InformationFramework { joint-iso-itu-t ds(5) module(1) informationFramework(1) 5 } ; LDAPMessage ::= SEQUENCE { messageID MessageID, protocolOp CHOICE { bindRequest BindRequest, bindResponse BindResponse, unbindRequest UnbindRequest, searchRequest SearchRequest, searchResEntry SearchResultEntry, searchResDone SearchResultDone, searchResRef SearchResultReference, modifyRequest ModifyRequest, modifyResponse ModifyResponse, addRequest AddRequest, addResponse AddResponse, delRequest DelRequest, delResponse DelResponse, modDNRequest ModifyDNRequest, modDNResponse ModifyDNResponse, compareRequest CompareRequest, compareResponse CompareResponse, abandonRequest AbandonRequest, extendedReq ExtendedRequest, extendedResp ExtendedResponse, ..., intermediateResponse IntermediateResponse }, controls [0] Controls OPTIONAL } Legg & Prager Expires 16 May 2007 [Page 22] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 MessageID ::= INTEGER (0 .. maxInt) maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) -- LDAPString ::= UTF8String LDAPOID ::= OBJECT IDENTIFIER LDAPDN ::= DistinguishedName RelativeLDAPDN ::= RelativeDistinguishedName AttributeDescription ::= SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL } AttributeValueAssertion ::= SEQUENCE { attributeDesc SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL }, assertionValue ATTRIBUTE.&equality-match.&AssertionType ({SupportedAttributes}{@attributeDesc.type}) } PartialAttribute ::= SEQUENCE { type SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL }, vals SET OF value ATTRIBUTE.&Type ({SupportedAttributes}{@type.type}) } Attribute ::= PartialAttribute(WITH COMPONENTS { ..., vals (SIZE(1..MAX))}) LDAPResult ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), compareFalse (5), compareTrue (6), authMethodNotSupported (7), strongerAuthRequired (8), Legg & Prager Expires 16 May 2007 [Page 23] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 -- 9 reserved -- referral (10), adminLimitExceeded (11), unavailableCriticalExtension (12), confidentialityRequired (13), saslBindInProgress (14), noSuchAttribute (16), undefinedAttributeType (17), inappropriateMatching (18), constraintViolation (19), attributeOrValueExists (20), invalidAttributeSyntax (21), -- 22-31 unused -- noSuchObject (32), aliasProblem (33), invalidDNSyntax (34), -- 35 reserved for undefined isLeaf -- aliasDereferencingProblem (36), -- 37-47 unused -- inappropriateAuthentication (48), invalidCredentials (49), insufficientAccessRights (50), busy (51), unavailable (52), unwillingToPerform (53), loopDetect (54), -- 55-63 unused -- namingViolation (64), objectClassViolation (65), notAllowedOnNonLeaf (66), notAllowedOnRDN (67), entryAlreadyExists (68), objectClassModsProhibited (69), -- 70 reserved for CLDAP -- affectsMultipleDSAs (71), -- 72-79 unused -- other (80), ... }, matchedDN LDAPDN, diagnosticMessage LDAPString, referral [3] Referral OPTIONAL } Referral ::= SEQUENCE SIZE (1..MAX) OF uri URI URI ::= LDAPString -- limited to characters permitted in -- URIs Controls ::= SEQUENCE OF control Control Legg & Prager Expires 16 May 2007 [Page 24] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Control ::= SEQUENCE { controlType CONTROL.&type({SupportedControls}), criticality BOOLEAN DEFAULT FALSE, controlValue CHOICE { request [0] CONTROL.&RequestValue ({SupportedControls}{@controlType}), response [1] CONTROL.&ResponseValue ({SupportedControls}{@controlType}) } OPTIONAL } BindRequest ::= [APPLICATION 0] SEQUENCE { version INTEGER (1 .. 127), name LDAPDN, authentication AuthenticationChoice } AuthenticationChoice ::= CHOICE { simple [0] OCTET STRING, -- 1 and 2 reserved sasl [3] SaslCredentials, ... } SaslCredentials ::= SEQUENCE { mechanism LDAPString, credentials OCTET STRING OPTIONAL } BindResponse ::= [APPLICATION 1] SEQUENCE { COMPONENTS OF LDAPResult, serverSaslCreds [7] OCTET STRING OPTIONAL } UnbindRequest ::= [APPLICATION 2] NULL SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { baseObject (0), singleLevel (1), wholeSubtree (2), ... }, derefAliases ENUMERATED { neverDerefAliases (0), derefInSearching (1), derefFindingBaseObj (2), derefAlways (3) }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), typesOnly BOOLEAN, filter Filter, attributes AttributeSelection } Legg & Prager Expires 16 May 2007 [Page 25] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 AttributeSelection ::= SEQUENCE OF selector AttributeDescription Filter ::= CHOICE { and [0] SET OF filter Filter, or [1] SET OF filter Filter, not [2] Filter, equalityMatch [3] AttributeValueAssertion, substrings [4] SubstringFilter, greaterOrEqual [5] AttributeValueAssertion, lessOrEqual [6] AttributeValueAssertion, present [7] AttributeDescription, approxMatch [8] AttributeValueAssertion, extensibleMatch [9] MatchingRuleAssertion, ... } SubstringFilter ::= SEQUENCE { type SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL }, substrings SEQUENCE SIZE (1..MAX) OF substring CHOICE { initial [0] ATTRIBUTE.&equality-match.&AssertionType ({SupportedAttributes}{@type.type}), -- can occur at most once any [1] ATTRIBUTE.&equality-match.&AssertionType ({SupportedAttributes}{@type.type}), final [2] ATTRIBUTE.&equality-match.&AssertionType ({SupportedAttributes}{@type.type}) } -- can occur at most once } MatchingRuleAssertion ::= SEQUENCE { matchingRule [1] MATCHING-RULE.&id OPTIONAL, type [2] AttributeDescription OPTIONAL, matchValue [3] MATCHING-RULE.&AssertionType, dnAttributes [4] BOOLEAN DEFAULT FALSE } SearchResultEntry ::= [APPLICATION 4] SEQUENCE { objectName LDAPDN, attributes PartialAttributeList } PartialAttributeList ::= SEQUENCE OF partialAttribute PartialAttribute SearchResultReference ::= [APPLICATION 19] SEQUENCE SIZE (1..MAX) OF uri URI SearchResultDone ::= [APPLICATION 5] LDAPResult Legg & Prager Expires 16 May 2007 [Page 26] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, changes SEQUENCE OF change SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2), ... }, modification PartialAttribute } } ModifyResponse ::= [APPLICATION 7] LDAPResult AddRequest ::= [APPLICATION 8] SEQUENCE { entry LDAPDN, attributes AttributeList } AttributeList ::= SEQUENCE OF attribute Attribute AddResponse ::= [APPLICATION 9] LDAPResult DelRequest ::= [APPLICATION 10] LDAPDN DelResponse ::= [APPLICATION 11] LDAPResult ModifyDNRequest ::= [APPLICATION 12] SEQUENCE { entry LDAPDN, newrdn RelativeLDAPDN, deleteoldrdn BOOLEAN, newSuperior [0] LDAPDN OPTIONAL } ModifyDNResponse ::= [APPLICATION 13] LDAPResult CompareRequest ::= [APPLICATION 14] SEQUENCE { entry LDAPDN, ava AttributeValueAssertion } CompareResponse ::= [APPLICATION 15] LDAPResult AbandonRequest ::= [APPLICATION 16] MessageID ExtendedRequest ::= [APPLICATION 23] SEQUENCE { requestName [0] LDAP-EXTENDED-REQUEST.&name ({SupportedRequests}), requestValue [1] LDAP-EXTENDED-REQUEST.&Value ({SupportedRequests}{@requestName}) OPTIONAL } ExtendedResponse ::= [APPLICATION 24] SEQUENCE { Legg & Prager Expires 16 May 2007 [Page 27] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 COMPONENTS OF LDAPResult, responseName [10] LDAP-EXTENDED-RESPONSE.&name ({SupportedResponses}) OPTIONAL, responseValue [11] LDAP-EXTENDED-RESPONSE.&Value ({SupportedResponses}{@responseName}) OPTIONAL } IntermediateResponse ::= [APPLICATION 25] SEQUENCE { responseName [0] LDAP-INTERMEDIATE-RESPONSE.&name ({SupportedIntermediateResponses}) OPTIONAL, responseValue [1] LDAP-INTERMEDIATE-RESPONSE.&Value ({SupportedIntermediateResponses} {@responseName}) OPTIONAL } CONTROL ::= CLASS { &type OBJECT IDENTIFIER, &RequestValue OPTIONAL, &ResponseValue OPTIONAL } SupportedControls CONTROL ::= { ... } LDAP-EXTENDED-REQUEST ::= CLASS { &name OBJECT IDENTIFIER, &Value OPTIONAL } SupportedRequests LDAP-EXTENDED-REQUEST ::= { ... } LDAP-EXTENDED-RESPONSE ::= CLASS { &name OBJECT IDENTIFIER, &Value OPTIONAL } SupportedResponses LDAP-EXTENDED-RESPONSE ::= { ... } LDAP-INTERMEDIATE-RESPONSE ::= CLASS { &name OBJECT IDENTIFIER, &Value OPTIONAL } SupportedIntermediateResponses LDAP-INTERMEDIATE-RESPONSE ::= { ... } ENCODING-CONTROL RXER SCHEMA-IDENTITY "urn:oid:1.3.6.1.4.1.21472.5.1.2" Legg & Prager Expires 16 May 2007 [Page 28] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 TARGET-NAMESPACE "urn:ietf:params:xml:ns:xed-uldap" PREFIX "xldap" END The object identifier for the XED-Uniform-LDAP module has been assigned for use in this specification by xmled.org, under an arc assigned to xmled.org by IANA. Appendix B. ASN.1 for XED Protocol Elements This appendix is normative. XED-Protocols { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) ds(5) module(1) protocols(4) } -- Copyright (C) The IETF Trust (2006). This version of -- this ASN.1 module is part of RFC XXXX; see the RFC itself -- for full legal notices. DEFINITIONS RXER INSTRUCTIONS AUTOMATIC TAGS EXTENSIBILITY IMPLIED ::= BEGIN IMPORTS LDAPMessage FROM XED-Uniform-LDAP { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) ds(5) module(1) uniform-ldap(2) } DAP-IDM-PDUs, DSP-IDM-PDUs, DISP-IDM-PDUs, DOP-IDM-PDUs FROM DirectoryIDMProtocols { joint-iso-itu-t(2) ds(5) module(1) directoryIDMProtocols(31) 5 } ; null NULL ::= NULL -- an ASN.1 module must have at least one assignment ENCODING-CONTROL RXER SCHEMA-IDENTITY "urn:oid:1.3.6.1.4.1.21472.5.1.4" Legg & Prager Expires 16 May 2007 [Page 29] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 TARGET-NAMESPACE "urn:ietf:params:xml:ns:xed" PREFIX "xed" COMPONENT ldapMessage [NAME "LDAPMessage"] [TYPE-AS-VERSION] LDAPMessage COMPONENT dap-idm-pdu [NAME "DAP-IDM-PDU"] [TYPE-AS-VERSION] DAP-IDM-PDUs COMPONENT dsp-idm-pdu [NAME "DSP-IDM-PDU"] [TYPE-AS-VERSION] DSP-IDM-PDUs COMPONENT disp-idm-pdu [NAME "DISP-IDM-PDU"] [TYPE-AS-VERSION] DISP-IDM-PDUs COMPONENT dop-idm-pdu [NAME "DOP-IDM-PDU"] [TYPE-AS-VERSION] DOP-IDM-PDUs END The object identifier for the XED-Protocols module has been assigned for use in this specification by xmled.org, under an arc assigned to xmled.org by IANA. Appendix C. ASN.X for Uniform LDAP This appendix contains the ASN.X [ASN.X] translation of the XED-Uniform-LDAP module. This appendix is non-normative. Legg & Prager Expires 16 May 2007 [Page 30] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Copyright (C) The IETF Trust (2006). This version of this ASN.X module is part of RFC XXXX; see the RFC itself for full legal notices. Legg & Prager Expires 16 May 2007 [Page 31] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 (2^^31 - 1) Legg & Prager Expires 16 May 2007 [Page 32] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006
attributeDesc/type
 Legg & Prager Expires 16 May 2007 [Page 34] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006
type/type
 Legg & Prager Expires 16 May 2007 [Page 35] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 36] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 limited to characters permitted in URIs Legg & Prager Expires 16 May 2007 [Page 37] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006
controlType
 controlType
 Legg & Prager Expires 16 May 2007 [Page 38] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 39] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 40] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 41] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 42] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 can occur at most once Legg & Prager Expires 16 May 2007 [Page 43] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006
type/type
 type/type
 can occur at most once type/type
 Legg & Prager Expires 16 May 2007 [Page 44] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 45] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 46] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 47] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 48] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 49] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006
requestName
 Legg & Prager Expires 16 May 2007 [Page 50] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006
responseName
 Legg & Prager Expires 16 May 2007 [Page 51] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006
responseName
 Legg & Prager Expires 16 May 2007 [Page 52] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 53] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 Appendix D. ASN.X for XED Protocol Elements This appendix contains the ASN.X [ASN.X] translation of the XED-Protocols module. This appendix is non-normative. Copyright (C) The IETF Trust (2006). This version of this ASN.X module is part of RFC XXXX; see the RFC itself for full legal notices. Legg & Prager Expires 16 May 2007 [Page 54] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 an ASN.1 module must have at least one assignment Authors' Addresses Dr. Steven Legg eB2Bcom Suite 3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com Dr. Daniel Prager EMail: dap@austhink.com Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Legg & Prager Expires 16 May 2007 [Page 55] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Note to the RFC Editor: the remainder of this document is to be removed before final publication. Changes in Draft 01 A simple TCP/IP transport for XLDAP has been defined. The new transport uses the TCP/IP framing of IDM and is analogous to the way LDAP is mapped to TCP/IP. A section comparing XLDAP to DSMLv2 has been added. The ASN.1, ASN.1 Schema (ASN.X) and XML Schema in the appendices has been revised to take account of the latest draft for the LDAP protocol (draft-ietf-ldapbis-protocol-17.txt). Changes in Draft 02 Legg & Prager Expires 16 May 2007 [Page 56] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 The Directory XML Encoding Rules (DXER) have been renamed to the Robust XML Encoding Rules (RXER). The ASN.1, ASN.1 Schema (ASN.X) and XML Schema in the appendices has been revised to take account of the latest draft for the LDAP protocol (draft-ietf-ldapbis-protocol-24.txt). The LDAP-INTERMEDIATE-RESPONSE information object class has been added to account for the new IntermediateResponse LDAP message type. The effect of Absolute True and False Filters for LDAP has been incorporated into the Uniform LDAP specification. The qualified names of the root elements of XED protocol messages have been changed so as to be independent of the specific version of X.500 or Uniform LDAP an implementation is using. This change makes it easier for a subsequent edition of the XED specification, or a subsequent edition of X.500, to be backward compatible with this version of XED. Appendix H has been added as an alternative description of the root elements. The namespace names defined by this document have been shortened. The XED-Uniform-LDAP module has been assigned an object identifier. Changes in Draft 03 ASN.1 Schema has been renamed to Abstract Syntax Notation X (ASN.X) and the element has been renamed to . The strongAuthRequired result code has been changed to strongerAuthRequired to match the same change in the latest draft for the LDAP protocol (draft-ietf-ldapbis-protocol-32.txt). The encodings of the root elements of XED protocol messages have been formalized with RXER encoding instructions in the XED-Protocols ASN.1 module added as Appendix C. An ASN.X translation of the XED-Protocols module has been added as Appendix F. Appendix H is now the XML Schema translation of the XED-Protocols module. Changes in Draft 04 Appendices G and H, XML Schema translations of the XED-Uniform-LDAP and XED-Protocols modules, have been removed. The XED-LDAP-Extensibility module has been merged into the XED-Uniform-LDAP module. The URLs for the namespaces of the XED-Protocols and XED-Uniform-LDAP Legg & Prager Expires 16 May 2007 [Page 57] INTERNET-DRAFT The XML Enabled Directory: Protocols November 16, 2006 modules have been replaced. Permanent URNs will be requested from IANA. Legg & Prager Expires 16 May 2007 [Page 58]