INTERNET-DRAFT A. Sciberras draft-sciberras-xed-eldif-03.txt S. Legg Intended Category: Standards Track eB2Bcom October 20, 2004 The Extended LDAP Data Interchange Format (ELDIF) Copyright (C) The Internet Society (2004). All Rights Reserved. Status of this Memo By submitting this Internet-draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-draft, we accept the provisions of Section 3 of RFC 3667. 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 LDAP Extensions 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 20 April 2005. Abstract This document extends the Lightweight Directory Access Protocol (LDAP) Data Interchange Format (LDIF) to permit Extensible Markup Sciberras & Legg Expires 20 April 2005 [Page 1] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2004 Language (XML) encoded directory attribute values to be represented in a human readable format, instead of Base64. Sciberras & Legg Expires 20 April 2005 [Page 2] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2004 Table of Contents 1. Introduction .................................................. 3 2. Conventions ................................................... 3 3. Syntax Definitions for ELDIF .................................. 4 3.1 ELDIF Version Number ...................................... 4 3.2 Safe Character Values ..................................... 4 3.3 Attribute Specification ................................... 5 3.4 XML-STRING Identifier ..................................... 5 4. ELDIF Example ................................................. 5 5. Security Considerations ....................................... 6 6. IANA Considerations ........................................... 6 7. Acknowledgements .............................................. 7 8. References .................................................... 7 8.1 Normative References ...................................... 7 8.2 Informative References .................................... 7 9. IPR Disclosure ................................................ 8 10. Authors' Addresses ........................................... 8 11. Full Copyright Statement ..................................... 8 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", Sciberras & Legg Expires 20 April 2005 [Page 3] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2004 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 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. RANGLE = %x3E ; ASCII Right Angle Character '>' 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 RANGLE 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 2005 [Page 4] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2004 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 RANGLE ('>' - ASCII 0x3E) 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 RANGLE is also inserted as the first character on the new line. When parsing ELDIF values, the initial line separator and RANGLE 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 LDIF 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 RANGLE 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 RANGLE character MUST be discarded. 4. ELDIF Example The following is an example of how an attribute value, which has been encoded using the Robust XML Encoding Rules (RXER) [RXER], 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 2005 [Page 5] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2004 The RXER encoding of this postalAddress value is: 250 Bay Street Brighton Victoria 3186 Australia Note: This RXER encoding includes a line feed (ASCII 0x0A) as its last character. The ELDIF representation of an entry which represented the postalAddress value in its RXER encoded form would be: version: 2 dn: cn=Andrew Sciberras,o=Adacel,c=AU objectClass: organizationalPerson postalAddress;transfer-rxer>: > > > 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. IANA Considerations This document does not contain any actions for IANA. Sciberras & Legg Expires 20 April 2005 [Page 6] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2004 7. Acknowledgements This document has been based on work completed for the XED framework (a joint research project between Adacel Technologies Limited and Deakin University) and the LDIF Technical Specification (RFC 2849). 8. References 8.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. 8.2 Informative References [BCP11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996. [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. [RFC3668] Bradner, S, "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004. [RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules for ASN.1 Types", draft-legg-xed-rxer-xx.txt, a work in progress, May 2004. [SCHEMA] Dally, K., "LDAP: Schema for User Applications", draft- ietf-ldapbis-user-schema-xx.txt, a work in progress, Sciberras & Legg Expires 20 April 2005 [Page 7] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2004 June 2003. [XED] Legg, S. and D. Prager, "The XML Enabled Directory", draft-legg-xed-roadmap-xx.txt, a work in progress, June 2004. [XED-SCHEMA] Legg, S. and D. Prager, "XED: Schema Operational Attributes", draft-legg-xed-schema-xx.txt, a work in progress, June 2004. 9. IPR Disclosure By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, in accordance with RFC 3668 [RFC3668]. 10. Authors' Addresses Andrew Sciberras eB2Bcom Suite3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA Phone: +61 3 9896 7833 Fax: +61 3 9896 7801 EMail: andrew.sciberras@eb2bcom.com Dr. Steven Legg eB2Bcom Suite3, 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 11. Full Copyright Statement Copyright (C) The Internet Society (2004). All Rights Reserved. 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. This document and the information contained herein are provided on an Sciberras & Legg Expires 20 April 2005 [Page 8] INTERNET-DRAFT Extended LDIF (ELDIF) October 20, 2004 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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. Sciberras & Legg Expires 20 April 2005 [Page 9]