Subject: [ldapext] LDIFv2

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Tue, 08 Jun 2004 09:25:47 -0700

Andrew,

I'm a bit concerned by the use of whitespace to indicate
continuations in LDIFv2 XML values, especially in the last
line of the value.  I think this choice will make it
especially hard on those who create LDIF by hand, often by
example (instead of by reading the specification), to
get it right.  I suggest instead LDIFv2 that looks like:

dn: cn=Andrew Sciberras,o=Adacel,c=AU
objectClass: organizationalPerson
attr;transfer-rxer>:
><?xml version=3D'1.0'?>
>       <value>
>        <item>250 Bay Street</item>
>        <item>Brighton Victoria 3186</item>
>        <item>Australia</item>
>       </value>
>sn: Sciberras

I note as well that nothing in this extension is XML specific,
the extension is useful for incorporation of values which are
represented in any multi-line format.

Kurt

PS: your I-D seems to be encoded using quotable-printable... 

_______________________________________________
Ldapext mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ldapext

---

From: "Andrew Sciberras" <[email-masked]>
Date: Thu, 10 Jun 2004 10:41:26 +1000

>Andrew,

Hi Kurt! Thanks for your comments.

>get it right.

I think you may be right and will incorporate this into my next draft.

Below is your suggestion:

>        <item>Brighton Victoria 3186</item>

Incorporating your changes, this should actually look like this:

attr;transfer-rxer>:
><?xml version='1.0'?>
sn: Sciberras

The difference (ignoring the fact that I've removed the 3D text after
'version=' ) is that "sn: Sciberras" is on a new line. And that the value
ends with a line that contains '>' followed by a new line
character/sequence.

>represented in any multi-line format.

This is correct, assuming that values can all be represented in UTF8
excluding the NULL character.

The intention of this draft is to specifically allow XML encoded information
to be displayed in its encoding, rather than BASE64, because XML encodings
are text based.
Allowing this draft to be open-ended in what it applies to (i.e. including
non text based encodings which meet the aforementioned requirements) will be
counter to my original intention. From my point of view, a text encoding
(i.e. XML) is more presentable than BASE64, which in turn is more
presentable than non-ASCII character encoding.

>Kurt

Cheers,
Andrew.