INTERNET-DRAFT A. Sciberras draft-sciberras-xed-eldif-00.txt Adacel Technologies Intended Category: Standards Track S. Legg Adacel Technologies October 20, 2003 The Extended LDAP Data Interchange Format (ELDIF) 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 20 April 2004. Abstract This document extends the Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) to permit Extensible Markup Language (XML) encoded directory attribute values to be represented in a human readable format, instead of Base64. Sciberras & Legg Expires 20 April 2004 [Page 1] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2003 Table of Contents 1. Introduction .................................................. 2 2. Conventions ................................................... 2 3. Syntax Definitions for ELDIF .................................. 3 3.1 ELDIF Version Number ...................................... 3 3.2 Safe Character Values ..................................... 3 3.3 Attribute Specification ................................... 4 3.4 XML-STRING Identifier ..................................... 4 4. ELDIF Example ................................................. 4 5. Security Considerations ....................................... 5 6. Acknowledgements .............................................. 5 7. References .................................................... 6 7.1 Normative References ...................................... 6 7.2 Informative References .................................... 6 8. Intellectual Property Right ................................... 7 9. Authors' Addresses ............................................ 7 10. Full Copyright Statement ..................................... 7 1. Introduction The LDAP Data Interchange Format (LDIF) [LDIF] describes a file format suitable for describing directory information or modifications to directory data. The LDIF file format is typically used to import and export directory information between LDAP-based directory servers, or to describe a set of changes which are to be applied to a directory. The LDIF specification requires attribute values, which contain the Carriage Return (CR) or Line Feed (LF) characters, to be represented in a Base64 [MIME] format. The Base64 encoding of attribute values does not make the values easily editable or readable without decoding the data first. Attribute values may be represented in an Extensible Markup Language (XML) [XML] encoding [XED][XED-SCHEMA], which will typically contain CR and/or LF characters. The LDIF representation of such an XML encoding will be a Base64 encoding of the markup. The motivation behind this specification is to extend LDIF to allow XML encoded attribute values to be represented as XML, rather than Base64. Thus, this extended version of LDIF, known as ELDIF, will allow the XML encoded data to be represented in a format that can be easily read and modified. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are Sciberras & Legg Expires 20 April 2004 [Page 2] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2003 to be interpreted as described in BCP14 RFC 2119 [BCP14]. Throughout this document "attribute value" and "value" shall be taken to mean the encoded value of an attribute within the directory. 3. Syntax Definitions for ELDIF The following definitions use the Augmented Backus-Naur Form (ABNF) [ABNF] and supplement the ABNF definitions of LDIF. SAFE-XML-CHAR = %x01-7F / UTF8-2 / UTF8-3 / UTF8-4 ; Any UTF8 value, excluding NUL (0x00). ; See section 3.2 for details XML-STRING = *(SAFE-XML-CHAR) ; See section 3.4 for details attrval-spec =/ AttributeDescription xml-value-spec SEP ; Extends from LDIF ; See section 3.3 for details xml-value-spec = ">:" FILL SEP SPACE XML-STRING ; See section 3.4 for details The , , , , , , and rules are defined by LDIF [LDIF]. 3.1 ELDIF Version Number For the ELDIF file format described within this document, the version number MUST be 2. If the version number is 1 or absent, implementations MUST interpret the contents according to the LDIF [LDIF] specification. 3.2 Safe Character Values Any UTF8 character, except for NUL (ASCII 0x00) can be used within an XML-STRING. If the encoded attribute value contains a NUL character, the value MUST be represented as a as described in LDIF [LDIF]. Sciberras & Legg Expires 20 April 2004 [Page 3] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2003 3.3 Attribute Specification An attribute value in XML format MAY be represented in ELDIF as an (as defined in LDIF [LDIF]) followed by an xml-value-spec and a line separator (SEP). The final line separator ensures that the next attrval-spec value will begin at the start of a new line. When parsing an xml-value-spec the final SEP sequence MUST be discarded. The final SEP sequence can be easily identified as it will not have a space (ASCII 0x20) character following it. For the purpose of aligning the start and end tags of the XML encoded value, a line separator is inserted at the start of the value. A SPACE is also inserted as the first character on the new line. When parsing ELDIF values, the initial line separator and SPACE character are not part of the attribute value and MUST be discarded. 3.4 XML-STRING Identifier The character sequence ">:" introduces an . The rule MUST NOT be used if the attribute value is not encoded with an XML based encoding rule or if the version number is absent or less than 2. The XML-STRING contains the XML encoded attribute value. Since it is valid for this string to contain line separator characters, ELDIF implementations MUST NOT perform line folding (as described in [LDIF]) of the XML-STRING. ELDIF does not impose any limits on the number of characters per line, and only when a line separator is present within the encoded value should the line be broken. Whenever a line separator is reached, a SPACE character MUST be inserted as the first character of the new line. When parsing XML-STRING data, line separator values MUST be retained and the subsequent SPACE character MUST be discarded. 4. ELDIF Example The following is an example of how an attribute value, which has been encoded using the Directory XML Encoding Rules (DXER) [DXER], is represented in ELDIF. Suppose an entry contained the following postalAddress attribute [SCHEMA]: postalAddress "250 Bay Street$Brighton Victoria 3186$Australia" Sciberras & Legg Expires 20 April 2004 [Page 4] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2003 The DXER encoding of this postalAddress value is: 250 Bay Street Brighton Victoria 3186 Australia Note: This DXER encoding includes a line feed (ASCII 0x0A) as its last character. The ELDIF representation of an entry which represented the postalAddress value in its DXER encoded form would be: version: 2 dn: cn=Andrew Sciberras,o=Adacel,c=AU objectClass: organizationalPerson postalAddress;transfer-dxer>: 250 Bay Street Brighton Victoria 3186 Australia sn: Sciberras 5. Security Considerations XML Encoding Rules may normalize the representation of a line separator sequence into a single linefeed (ASCII 0x0A) character. An exact reproduction of the original line separator character(s) cannot be guaranteed when using an XML-STRING representation. The rule MUST NOT be used if line separator normalization is undesirable. Since ELDIF is an extension to LDIF, the security considerations that apply to LDIF equally apply to ELDIF. 6. Acknowledgements This document has been based on work completed for the XED protocols (a joint research project between Adacel Technologies Limited and Deakin University) and the LDIF Technical Specification (RFC 2849). Sciberras & Legg Expires 20 April 2004 [Page 5] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2003 7. References 7.1 Normative References [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LDIF] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000. [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. 7.2 Informative References [BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [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. [LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification, RFC 3377, September 2002. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft- ietf-ldapbis-user-schema-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. [XED-SCHEMA] Legg, S. and D. Prager, "XED: Schema Operational Attributes", draft-legg-xed-schema-xx.txt, a work in progress, August 2003. Sciberras & Legg Expires 20 April 2004 [Page 6] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2003 8. 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. 9. Authors' Addresses Andrew Sciberras Adacel Technologies Ltd. 250 Bay Street Brighton, Victoria 3186 AUSTRALIA Phone: +61 3 8530 7844 Fax: +61 3 8530 7888 EMail: andrew.sciberras@adacel.com.au 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 10. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. Sciberras & Legg Expires 20 April 2004 [Page 7] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 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. Sciberras & Legg Expires 20 April 2004 [Page 8]