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
<xeddev@adacel.com>. Please send editorial comments directly to the
editor <andrew.sciberras@adacel.com.au>.
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 <attrval-spec> from LDIF
; See section 3.3 for details
xml-value-spec = ">:" FILL SEP SPACE XML-STRING
; See section 3.4 for details
The <UTF8-2>, <UTF8-3>, <UTF8-4>, <AttributeDescription>, <attrval-
spec>, <SEP>, <SPACE> and <FILL> 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 <BASE64-STRING> 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
<AttributeDescription> (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 <xml-value-spec>. The
<xml-value-spec> 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:
<?xml version='1.0'?>
<item>
<item>250 Bay Street</item>
<item>Brighton Victoria 3186</item>
<item>Australia</item>
</item>
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>:
<?xml version='1.0'?>
<item>
<item>250 Bay Street</item>
<item>Brighton Victoria 3186</item>
<item>Australia</item>
</item>
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 <xml-
value-spec> 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]