[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: [ldapext] UTF-8 full support in LDIF / LDIF v2


Hi Jim,

Jim Willeke wrote:
We, doing LDAP consulting, often run into these type of issues, but I believe they could be covered utilizing UTF8.

Although I love the discussions, regardless of how individuals feel, these discussions have already been and the decision was unicode.

The decision of the today's environment was also to use XML.

Not saying that either is right or wrong, but this is today's reality. 

Yep.


Why not use DSML 

The problem with DSML is that controls and extended operations have to
appear as the base64 encoding of the BER encoding, and directory attribute
values that contain XML have to have the markup escaped. I invented XLDAP
(http://www.xmled.info/drafts/draft-legg-xed-protocols-05.txt) so that
controls, extended operations and directory attribute values would all
appear as markup, without fiddly escaping and obscuring encodings.

> or perhaps go wild and use protocol buffers.
(http://code.google.com/p/protobuf/) 

It seems to be doing much the same thing as what we can already do with
ASN.1 and GSER encodings.

I believe DSML would also handle the concern for LDAP transactions as is or with some minor tweaks. 

If you don't mind base64 encodings of BER encodings. XLDAP does it better.

Regards,
Steven


-jim
Jim Willeke


On Thu, Mar 26, 2009 at 9:49 AM, Yves Dorfsman <yves@zioup.com <mailto:yves@zioup.com>> wrote:

    Steven Legg wrote:

                See
                http://www.xmled.info/drafts/draft-sciberras-xed-eldif-05.txt


        We created a solution for presenting directory attribute values
        that are
        arbitrary UTF-8 character strings including line breaks. That
        accommodates
        UTF-8 encoded XML documents, but would also be useful for GSER
        encodings
        if the whitespace separator is extended to include line breaks.

            Any reason why the draft never made it to an RFC ?


        It may yet. We've just been busy with other things and there
        hasn't been
        external pressure to move it along.


    Yes I was wondering about that, do we need multi-line values as work
    around because schemas aren't precise enough ?


        Escaping the line break characters in the value and using the
        existing
        LDIF line folding method would work. The output function can
        optionally
        fold lines immediately after an escaped line break so that the
        number
        of lines in the value matches the number of lines in the LDIF
        output.

     >

        Another solution is to drop into a literal mode until a special
        character
        sequence is encountered (e.g., END-OF-VALUE). One must then take
        care to
        escape the special sequence if it happens to occur in the
        attribute value.

        Both of the above solutions require messing about with escape
        sequences,
        whereas the simple prefix method we settled on doesn't need to.

            Would quoting a la python work, or would that add too much
            complexity, too much of a change from the current LDIF ?


        Can you present an example of what you mean ?


    Python style would be usint a special character that then needs to
    be escaped, something like:
    #####################################
    organizationName: Smith, Smith
    &
    Smith
    givenName: John
    #####################################

    or
    #####################################
    organizationName: 'Smith, Smith
    &
    Smith'
    givenName: John
    #####################################


    But now that I think of it, it does look messy in the middle of an
    LDIF file. What about a mix, like:
    #####################################
    organizationName: 'Smith, Smith\' \
                     '&\' \
                     'Smith'
    givenName: John
    #####################################


    I find it a lot more LDIFic...

    Again, before we get into something like that, I'd like to have a
    better feeling for how much of a need we have for it ?

-- Yves.
http://www.sollers.ca/

    _______________________________________________
    Ldapext mailing list
    Ldapext@ietf.org <mailto:Ldapext@ietf.org>
    https://www.ietf.org/mailman/listinfo/ldapext



------------------------------------------------------------------------

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext