Internet DRAFT - draft-sciberras-xed-eldif
draft-sciberras-xed-eldif
INTERNET-DRAFT A. Sciberras
draft-sciberras-xed-eldif-05.txt S. Legg
Intended Category: Standards Track eB2Bcom
December 9, 2005
The Extended LDAP Data Interchange Format (ELDIF)
Copyright (C) The Internet Society (2005). All Rights Reserved.
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
This document is intended to be, after appropriate review and
revision, submitted to the RFC Editor as a Standard Track document.
Distribution of this document is unlimited. Technical discussion of
this document should take place on the XED developers mailing list
<xeddev@eb2bcom.com>. Please send editorial comments directly to the
editor <andrew.sciberras@eb2bcom.com>. Further information is
available on the XED website: www.xmled.info.
This Internet-Draft expires on 9 June 2006.
Sciberras & Legg Expires 9 June 2006 [Page 1]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
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 9 June 2006 [Page 2]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
Table of Contents
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Syntax Definitions for ELDIF. . . . . . . . . . . . . . . . . . . 5
3.1 ELDIF Version Number. . . . . . . . . . . . . . . . . . . . . 5
3.2 Safe Character Values . . . . . . . . . . . . . . . . . . . . 5
3.3 Attribute Specification . . . . . . . . . . . . . . . . . . . 6
3.4 XML-STRING Identifier . . . . . . . . . . . . . . . . . . . . 6
4. ELDIF Example . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 8
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1 Normative References. . . . . . . . . . . . . . . . . . . . . 8
8.2 Informative References. . . . . . . . . . . . . . . . . . . . 8
9. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 9
10. Intellectual Property Statement. . . . . . . . . . . . . . . . . 9
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 10
Sciberras & Legg Expires 9 June 2006 [Page 3]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
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 [TRANSFER], 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
to be interpreted as described in RFC 2119 [RFC2119].
Throughout this document "attribute value" and "value" shall be taken
to mean the encoded value of an attribute within the directory.
Sciberras & Legg Expires 9 June 2006 [Page 4]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
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 <attrval-spec> from LDIF
; See section 3.3 for details
xml-value-spec = ">:" FILL SEP RANGLE XML-STRING
; See section 3.4 for details
The <UTF8-2>, <UTF8-3>, <UTF8-4>, <AttributeDescription>, <attrval-
spec>, <SEP> 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 9 June 2006 [Page 5]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
3.3 Attribute Specification
An attribute value in an 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 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 <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 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 9 June 2006 [Page 6]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
The RXER encoding of this postalAddress value is:
<?xml version='1.0'?>
<value>
<item>250 Bay Street</item>
<item>Brighton Victoria 3186</item>
<item>Australia</item>
</value>
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>:
><?xml version='1.0'?>
><value>
> <item>250 Bay Street</item>
> <item>Brighton Victoria 3186</item>
> <item>Australia</item>
></value>
>
sn: Sciberras
The 'transfer-rxer' transfer encoding option is defined in Transfer
Encoding Options [TRANSFER].
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. IANA Considerations
This document does not contain any actions for IANA.
Sciberras & Legg Expires 9 June 2006 [Page 7]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
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.
[LDIF] Good, G., "The LDAP Data Interchange Format (LDIF) -
Technical Specification", RFC 2849, June 2000.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
[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, October 20045.
[SCHEMA] Sciberras, A., "LDAP: Schema for User Applications",
draft-ietf-ldapbis-user-schema-xx.txt, a work in
progress.
[TRANSFER] Legg, S., "Lightweight Directory Access Protocol
(LDAP): Transfer Encoding Options", draft-legg-ldap-
Sciberras & Legg Expires 9 June 2006 [Page 8]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
transfer-xx.txt, a work in progress, June 2004.
9. Authors' Addresses
Andrew Sciberras
eB2Bcom
Suite 3, 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
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
10. Intellectual Property Statement
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
Sciberras & Legg Expires 9 June 2006 [Page 9]
INTERNET-DRAFT Extended LDIF (ELDIF) December 9, 2005
ietf-ipr@ietf.org.
11. Full Copyright Statement
Copyright (C) The Internet Society (2005).
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
"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.
Sciberras & Legg Expires 9 June 2006 [Page 10]
