INTERNET-DRAFT S. Legg draft-legg-xed-protocols-00.txt Adacel Technologies Intended Category: Standard Track D. Prager Deakin University September 1, 2003 XED: Protocols Copyright (C) The Internet Society (2003). All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Technical discussion of this document should take place on the XED developers mailing list . Please send editorial comments directly to the editor . This Internet-Draft expires on 1 March 2004. 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 1 March 2004 [Page 1] INTERNET-DRAFT XED: Protocols September 1, 2003 Table of Contents 1. Introduction .................................................. 2 2. Conventions ................................................... 3 3. Uniform LDAP Specification .................................... 3 3.1 Remediation of AttributeValue ............................. 5 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 4. XLDAP ......................................................... 11 4.1 XLDAP Over SOAP 1.1 ....................................... 11 5. XIDM .......................................................... 12 7. Security Considerations ....................................... 13 8. Acknowledgements .............................................. 13 9. Normative References .......................................... 14 10. Informative References ....................................... 15 11. Intellectual Property Notice ................................. 16 12. Copyright Notice ............................................. 16 13. Authors' Addresses ........................................... 17 Appendix A. ASN.1 for Uniform LDAP ............................... 18 Appendix B. Supporting Definitions for Uniform LDAP .............. 24 Appendix C. ASN.1 Schema for Uniform LDAP ........................ 25 Appendix D. XML Schema for Uniform LDAP .......................... 50 Appendix E. RELAX NG Grammar for Uniform LDAP .................... 65 1. Introduction This document defines semantically equivalent Extensible Markup Language (XML) [XML] renditions of the Lightweight Directory Access Protocol (LDAP) [LDAP] and X.500 [X500] directory protocols for use by the XML Enabled Directory (XED) [XED]. The Internet Directly Mapped (IDM) protocol [X519] 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 OSI model [OSI]. Protocol operations in the IDM protocol are encoded according to the Basic Encoding Rules (BER) [X690] of ASN.1. 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 Directory XML Encoding Rules (DXER) [DXER] instead of BER. Legg & Prager Expires 1 March 2004 [Page 2] INTERNET-DRAFT XED: Protocols September 1, 2003 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 DXER 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 [X680] containers for directory data items in LDAP are replaced by the open types [X681] and specific types used by X.500. The XML Lightweight Directory Access Protocol (XLDAP) defined in Section 4 is the result of applying DXER to instances of the message data types of Uniform LDAP. Section 4 also defines 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", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BCP14]. This document makes use of definitions from the XML Information Set (Infoset) [ISET]. In particular, information item property names are presented per the Infoset, 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. 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 differing data types (e.g. attribute values, assertion values, Legg & Prager Expires 1 March 2004 [Page 3] INTERNET-DRAFT XED: Protocols September 1, 2003 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 differing 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 [X682] 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 presented in Appendix A. Supporting definitions for Uniform LDAP are presented in Appendix B. The equivalent ASN.1 Schema representation of the Uniform LDAP specification is presented in Appendix C. A compatible XML Schema [XSD0] translation [CXSD] of the Uniform LDAP specification is presented in Appendix D and a compatible RELAX NG grammar [RNG] translation [CRNG] of the Uniform LDAP specification is presented in Appendix E. Since Uniform LDAP protocol messages and the directory data they contain are encoded in the same syntax throughout, LDAP transfer encoding options [XFER] are ignored if present. Legg & Prager Expires 1 March 2004 [Page 4] INTERNET-DRAFT XED: Protocols September 1, 2003 3.1 Remediation of AttributeValue The definition of AttributeValue is removed and each reference to AttributeValue is replaced with the following, where 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 [X501]. 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 [X501]. 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 Legg & Prager Expires 1 March 2004 [Page 5] INTERNET-DRAFT XED: Protocols September 1, 2003 preceding component of the AttributeDescription ASN.1 type: ATTRIBUTE.&equality-match.&AssertionType ({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.&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. Legg & Prager Expires 1 March 2004 [Page 6] INTERNET-DRAFT XED: Protocols September 1, 2003 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 DXER encoding of attribute values of 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 [X501]. 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 Legg & Prager Expires 1 March 2004 [Page 7] INTERNET-DRAFT XED: Protocols September 1, 2003 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. CONTROL ::= CLASS { &type OBJECT IDENTIFIER, &RequestValue OPTIONAL, &ResponseValue OPTIONAL } SupportedControls CONTROL ::= { ... } 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 incorporated into an ASN.1 type definition [GLUE], then the data type of the control value is taken to be OCTET STRING. 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 ::= { ... } Legg & Prager Expires 1 March 2004 [Page 8] INTERNET-DRAFT XED: Protocols September 1, 2003 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 ({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 contain an OCTET STRING response value whose content is determined by an associated response name. The request 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 have no counterpart in X.500 therefore the LDAP-EXTENDED-REQUEST and LDAP-EXTENDED-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 } 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 Legg & Prager Expires 1 March 2004 [Page 9] INTERNET-DRAFT XED: Protocols September 1, 2003 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. 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. If the data type of a request or response value is not an ASN.1 type, and cannot be incorporated into an ASN.1 type definition [GLUE], then the data type of the value is taken to be OCTET STRING. Definitions of LDAP-EXTENDED-REQUEST and LDAP-EXTENDED-RESPONSE objects for extended operations already defined is out of scope for this document, however such objects can be readily synthesized from the specification of an extended operation. 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. SupportedRequests LDAP-EXTENDED-REQUEST ::= { ... } SupportedResponses LDAP-EXTENDED-RESPONSE ::= { ... } In order to allow automated determination of the request value data type from the request name the definition 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 the definition of ExtendedResponse ASN.1 type is replaced with the following definition: Legg & Prager Expires 1 March 2004 [Page 10] INTERNET-DRAFT XED: Protocols September 1, 2003 ExtendedResponse ::= [APPLICATION 24] SEQUENCE { COMPONENTS OF LDAPResult, responseName [10] LDAP-EXTENDED-RESPONSE.&name ({SupportedResponses}) OPTIONAL, responseValue [11] LDAP-EXTENDED-RESPONSE.&Value ({SupportedResponses}{@responseName}) OPTIONAL } The CONTROL, LDAP-EXTENDED-REQUEST and LDAP-EXTENDED-RESPONSE information object classes and the SupportedControls, SupportedRequests and SupportedResponses information object sets need to be imported from the XED-LDAP-Extensibility module, therefore the following notation is appended to the import statement for Uniform LDAP: CONTROL, LDAP-EXTENDED-REQUEST, LDAP-EXTENDED-RESPONSE, SupportedControls, SupportedRequests, SupportedResponses FROM XED-LDAP-Extensibility {iso(1) 2 36 79672281 xed(3) module(0) ldap-ext(3)} ; 4. XLDAP Protocol messages of the XML Lightweight Directory Access Protocol (XLDAP) are instances of the LDAPMessage type from the Uniform LDAP specification encoded according to DXER [DXER], and exchanged over any of the transports defined in this document. The only transport defined thus far is SOAP 1.1 [SOAP]. A mapping of Uniform LDAP to BEEP [BEEP] is under consideration. 4.1 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 "http://xmled.info/ns/XED/1/XED-Uniform-LDAP/00". No SOAP headers are defined for XLDAP over SOAP 1.1. Uniform LDAP requests and responses are values of the LDAPMessage type from the XED-Uniform-LDAP module. Legg & Prager Expires 1 March 2004 [Page 11] INTERNET-DRAFT XED: Protocols September 1, 2003 A Uniform LDAP request is mapped onto a SOAP request message. The SOAP Body element SHALL contain a single child element with the [local name] "LDAPMessage" and the [namespace name] "http://xmled.info/ns/XED/1/XED-Uniform-LDAP/00". The content of this element SHALL be the DXER encoding [DXER] of the Uniform LDAP request. A Uniform LDAP response other than a search response is mapped onto a SOAP response message. The SOAP Body element SHALL contain a single child element with the [local name] "LDAPMessage" and the [namespace name] "http://xmled.info/ns/XED/1/XED-Uniform-LDAP/00". The content of this element SHALL be the DXER encoding [DXER] of the Uniform LDAP response. The result of a Uniform LDAP search is mapped onto a SOAP response message where the SOAP Body element contains a child element for each Uniform LDAP response making up the result, i.e. the result messages for a search (containing a value of SearchResultEntry, SearchResultReference or SearchResultDone) are concatenated into a single SOAP response. Each child element of the SOAP Body element has the [local name] "LDAPMessage" and the [namespace name] "http://xmled.info/ns/XED/1/XED-Uniform-LDAP/00". The content of each child element SHALL be the DXER encoding [DXER] of one of the Uniform LDAP responses for the search. Directory processing errors are reported as Uniform LDAP responses. SOAP processing errors are reported using the SOAP Fault element. 5. XIDM The ASN.1 data types of XIDM Protocol Data Units (PDUs) are exactly those of the IDM PDUs [X519]. Each XIDM PDU is encoded as a Standalone DXER Encoding [DXER] (instead of the BER encoding used by IDM) and then mapped to TCP/IP [TCP] in the manner prescribed in X.519 [X519] for IDM PDUs. The mapping of the X.500 protocols into XIDM [X519] is identical to the mapping of these protocols onto IDM. The mapping of the Directory Access Protocol (DAP) onto XIDM is called the XML Directory Access Protocol over TCP/IP (X-DAP-IP). The PDUs of X-DAP-IP are instances of the DAP-IDM-PDUs ASN.1 type. The mapping of the Directory System Protocol (DSP) onto XIDM is called the XML Directory System Protocol over TCP/IP (X-DSP-IP). The PDUs of X-DSP-IP are instances of the DSP-IDM-PDUs ASN.1 type. Legg & Prager Expires 1 March 2004 [Page 12] INTERNET-DRAFT XED: Protocols September 1, 2003 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). The PDUs of X-DISP-IP are instances of the DISP-IDM-PDUs ASN.1 type. 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). The PDUs of X-DOP-IP are instances of the DOP-IDM-PDUs ASN.1 type. Note that the registered [XEDNS] namespace name of the DirectoryIDMProtocols module [X519] from the fourth edition of X.500, which defines the DAP-IDM-PDUs, DSP-IDM-PDUs, DISP-IDM-PDUs and DOP-IDM-PDUs ASN.1 types, is "http://xmled.info/ns/X.500/4/DirectoryIDMProtocols/00". The DirectoryIDMProtocols module first appears in the fourth edition of X.500. 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 DXER, 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. The 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 This document and the technology it describes are a product of a joint research project between Adacel Technologies Limited and Deakin University on leveraging existing directory technology to produce an XML-based directory service. Legg & Prager Expires 1 March 2004 [Page 13] INTERNET-DRAFT XED: Protocols September 1, 2003 8. Normative References [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. [LDAP] Zeilenga, K., "LDAP: Technical Specification Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress, June 2003. [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis- protocol-xx.txt, a work in progress, June 2003. [XED] Legg, S. and D. Prager, "The XML Enabled Directory", draft-legg-xed-roadmap-xx.txt, a work in progress, September 2003. [DXER] Legg, S. and D. Prager, "Directory XML Encoding Rules for ASN.1 Types", draft-legg-xed-dxer-xx.txt, a work in progress, August 2003. [GLUE] Legg, S. and D. Prager, "XED: Schema Language Integration", draft-legg-xed-glue-xx.txt, a work in progress, August 2003. [XEDNS] Legg, S. and D. Prager, "XED: IANA Considerations", draft-legg-xed-iana-xx.txt, a work in progress, August 2003. [XFER] Legg, S., "LDAP: Transfer Encoding Options", draft-legg-ldap-transfer-xx.txt, a work in progress, August 2003. [X500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001, Information technology - Open Systems Interconnection - The Directory: Models [X519] ITU-T Recommendation X.519 (02/01) | ISO/IEC 9594-5:2001, Information technology - Open Systems Interconnection - The Directory: Protocol specifications [X680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Legg & Prager Expires 1 March 2004 [Page 14] INTERNET-DRAFT XED: Protocols September 1, 2003 Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. [X681] ITU-T Recommendation X.681 (07/02) | ISO/IEC 8824-2, Information technology - Abstract Syntax Notation One (ASN.1): Information object specification. [X682] ITU-T Recommendation X.682 (07/02) | ISO/IEC 8824-3, Information technology - Abstract Syntax Notation One (ASN.1): Constraint specification. [XML] Bray, T., Paoli, J., Sperberg-McQueen, M. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C Recommendation, http://www.w3.org/TR/2000/REC- xml-20001006, October 2000. [ISET] Cowan, J. and R. Tobin, "XML Information Set", W3C Recommendation, http://www.w3.org/TR/2001/REC-xml- infoset-20011024, October 2001. [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. Informative References [BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [SYNTAX] Legg, S. and K. Dally, "LDAP: Syntaxes and Matching Rules", draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress, June 2003. [ASD] Legg, S. and D. Prager, "ASN.1 Schema: An XML Representation for ASN.1 Specifications", draft-legg-xed-asd-xx.txt, a work in progress, August 2003. [CXSD] Legg, S. and D. Prager, "Translation of ASN.1 Specifications into XML Schema", draft-legg-xed-xsd-xx.txt, a work in progress, August 2003. [CRNG] Legg, S. and D. Prager, "Translation of ASN.1 Specifications into RELAX NG", draft-legg-xed-rng-xx.txt, a Legg & Prager Expires 1 March 2004 [Page 15] INTERNET-DRAFT XED: Protocols September 1, 2003 work in progress, August 2003. [OSI] ITU-T Recommendation X.200 (1994) | ISO/IEC 7498-1:1994, Information technology - Open Systems Interconnection - Basic Reference Model: The Basic Model. [X690] ITU-T Recommendation X.690 (07/02) | ISO/IEC 8825-1:2002, Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). [XSD0] Fallside, D., "XML Schema Part 0: Primer", W3C Recommendation, http://www.w3.org/TR/2001/REC- xmlschema-0-20010502, May 2001. [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. 10. Intellectual Property Notice The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. [BCP11] Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 11. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Legg & Prager Expires 1 March 2004 [Page 16] INTERNET-DRAFT XED: Protocols September 1, 2003 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 12. Authors' Addresses Dr. Steven Legg Adacel Technologies Ltd. 250 Bay Street Brighton, Victoria 3186 AUSTRALIA Phone: +61 3 8530 7710 Fax: +61 3 8530 7888 EMail: steven.legg@adacel.com.au Dr. Daniel Prager C/o Professor Lynn Batten Department of Computing and Mathematics Deakin University Geelong, Victoria 3217 AUSTRALIA EMail: dan@layabout.net EMail: lmbatten@deakin.edu.au Legg & Prager Expires 1 March 2004 [Page 17] INTERNET-DRAFT XED: Protocols September 1, 2003 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 -- Copyright (C) The Internet Society (2003). This version of -- this ASN.1 module is part of RFC XXXX; see the RFC itself -- for full legal notices. -- The namespace name for this module is: -- http://xmled.info/ns/XED/1/XED-Uniform-LDAP/00 -- The SchemaIdentity for this module is: -- http://xmled.info/id/XED/1/XED-Uniform-LDAP/00 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) 4} CONTROL, LDAP-EXTENDED-REQUEST, LDAP-EXTENDED-RESPONSE, SupportedControls, SupportedRequests, SupportedResponses FROM XED-LDAP-Extensibility {iso(1) 2 36 79672281 xed(3) module(0) ldap-ext(3)} ; LDAPMessage ::= SEQUENCE { messageID MessageID, protocolOp CHOICE { bindRequest BindRequest, bindResponse BindResponse, unbindRequest UnbindRequest, searchRequest SearchRequest, searchResEntry SearchResultEntry, searchResDone SearchResultDone, Legg & Prager Expires 1 March 2004 [Page 18] INTERNET-DRAFT XED: Protocols September 1, 2003 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, ... }, controls [0] Controls OPTIONAL } 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 } AttributeDescriptionList ::= SEQUENCE OF AttributeDescription 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}) } Attribute ::= SEQUENCE { type SEQUENCE { Legg & Prager Expires 1 March 2004 [Page 19] INTERNET-DRAFT XED: Protocols September 1, 2003 type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL }, vals SET OF ATTRIBUTE.&Type ({SupportedAttributes}{@type.type}) } LDAPResult ::= SEQUENCE { resultCode ENUMERATED { success (0), operationsError (1), protocolError (2), timeLimitExceeded (3), sizeLimitExceeded (4), compareFalse (5), compareTrue (6), authMethodNotSupported (7), strongAuthRequired (8), -- 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), Legg & Prager Expires 1 March 2004 [Page 20] INTERNET-DRAFT XED: Protocols September 1, 2003 entryAlreadyExists (68), objectClassModsProhibited (69), -- 70 reserved for CLDAP -- affectsMultipleDSAs (71), -- 72-79 unused -- other (80), ... }, -- 81-90 reserved for APIs -- matchedDN LDAPDN, diagnosticMessage LDAPString, referral [3] Referral OPTIONAL } Referral ::= SEQUENCE OF URL URL ::= LDAPString -- limited to characters permitted in -- URLs Controls ::= SEQUENCE OF Control 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 } Legg & Prager Expires 1 March 2004 [Page 21] INTERNET-DRAFT XED: Protocols September 1, 2003 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 AttributeDescriptionList } Filter ::= CHOICE { and [0] SET SIZE (1..MAX) OF Filter, or [1] SET SIZE (1..MAX) OF 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 }, -- at least one must be present, -- initial and final can occur at most once substrings SEQUENCE OF CHOICE { initial [0] ATTRIBUTE.&equality-match.&AssertionType ({SupportedAttributes}{@type.type}), any [1] ATTRIBUTE.&equality-match.&AssertionType ({SupportedAttributes}{@type.type}), final [2] ATTRIBUTE.&equality-match.&AssertionType ({SupportedAttributes}{@type.type}) } } MatchingRuleAssertion ::= SEQUENCE { matchingRule [1] MATCHING-RULE.&id OPTIONAL, Legg & Prager Expires 1 March 2004 [Page 22] INTERNET-DRAFT XED: Protocols September 1, 2003 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 SEQUENCE { type SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL }, vals SET OF ATTRIBUTE.&Type ({SupportedAttributes}{@type.type}) } SearchResultReference ::= [APPLICATION 19] SEQUENCE OF URL SearchResultDone ::= [APPLICATION 5] LDAPResult ModifyRequest ::= [APPLICATION 6] SEQUENCE { object LDAPDN, modification SEQUENCE OF SEQUENCE { operation ENUMERATED { add (0), delete (1), replace (2) }, modification AttributeTypeAndValues } } AttributeTypeAndValues ::= SEQUENCE { type SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL }, vals SET OF ATTRIBUTE.&Type ({SupportedAttributes}{@type.type}) } ModifyResponse ::= [APPLICATION 7] LDAPResult AddRequest ::= [APPLICATION 8] SEQUENCE { entry LDAPDN, attributes AttributeList } AttributeList ::= SEQUENCE OF SEQUENCE { type SEQUENCE { type ATTRIBUTE.&id({SupportedAttributes}), options SEQUENCE SIZE (1..MAX) OF option UTF8String OPTIONAL }, Legg & Prager Expires 1 March 2004 [Page 23] INTERNET-DRAFT XED: Protocols September 1, 2003 vals SET OF ATTRIBUTE.&Type ({SupportedAttributes}{@type.type}) } 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 { COMPONENTS OF LDAPResult, responseName [10] LDAP-EXTENDED-RESPONSE.&name ({SupportedResponses}) OPTIONAL, responseValue [11] LDAP-EXTENDED-RESPONSE.&Value ({SupportedResponses}{@responseName}) OPTIONAL } END Appendix B. Supporting Definitions for Uniform LDAP This appendix is normative. XED-LDAP-Extensibility Legg & Prager Expires 1 March 2004 [Page 24] INTERNET-DRAFT XED: Protocols September 1, 2003 {iso(1) 2 36 79672281 xed(3) module(0) ldap-ext(3)} -- Copyright (C) The Internet Society (2003). This version of -- this ASN.1 module is part of RFC XXXX; see the RFC itself -- for full legal notices. -- The namespace name for this module is: -- http://xmled.info/ns/XED/1/XED-LDAP-Extensibility/00 -- The SchemaIdentity for this module is: -- http://xmled.info/id/XED/1/XED-LDAP-Extensibility/00 DEFINITIONS AUTOMATIC TAGS EXTENSIBILITY IMPLIED ::= BEGIN 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 ::= { ... } END Appendix C. ASN.1 Schema for Uniform LDAP This appendix contains the ASN.1 Schema [ASD] translations of the XED-Uniform-LDAP and XED-LDAP-Extensibility modules. This appendix is non-normative. Legg & Prager Expires 1 March 2004 [Page 26] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 27] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 28] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 29] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 30] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 31] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 32] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 33] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 34] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 35] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 36] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 37] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 38] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 39] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 40] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 41] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 42] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 43] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 44] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 45] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 46] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 47] INTERNET-DRAFT XED: Protocols September 1, 2003
Legg & Prager Expires 1 March 2004 [Page 48] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 49] INTERNET-DRAFT XED: Protocols September 1, 2003 Appendix D. XML Schema for Uniform LDAP This appendix contains a compatible XML Schema [CXSD] translation of the XED-Uniform-LDAP module. The XML Schema translation of the XED-LDAP-Extensibility module contains no XML Schema definitions. This appendix is non-normative. Legg & Prager Expires 1 March 2004 [Page 50] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 51] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 52] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 53] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 54] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 55] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 56] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 57] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 58] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 59] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 60] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 61] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 62] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 63] INTERNET-DRAFT XED: Protocols September 1, 2003 Legg & Prager Expires 1 March 2004 [Page 64] INTERNET-DRAFT XED: Protocols September 1, 2003 Appendix E. RELAX NG Grammar for Uniform LDAP This appendix contains a compatible RELAX NG grammar [CRNG] translation of the XED-Uniform-LDAP module. The RELAX NG translation of the XED-LDAP-Extensibility module contains no RELAX NG definitions. This appendix is non-normative. To be supplied. Legg & Prager Expires 1 March 2004 [Page 65]