I-D: The Java LDAP Application Program Interface

[Michael Ströder]

David Leonard wrote:
> 
> On Tue, 6 Feb 2001, Michael Ströder typed thusly:
> 
> > http://www.ietf.org/internet-drafts/draft-ietf-ldapext-ldap-java-api-13.txt
> >
> > might be interesting. It looks more suitable for Python than going
> > with the C-oriented LDAPEXT-API. Anyone interested in implementing
> > that?
>
> I think that if we take the java api, and convert all the Javaisms
> to Pythonisms we could even submit "our own" RFC draft. :)

You're keen on having your name on top of a RFC? Well, why not...
;-)

>         * do we really need a LDAPDN class? Isn't python's string enough?

Well, the string representation of DNs according to RFC2253 is
somewhat limited. A DN is something like:

       RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
        AttributeTypeAndValue

       AttributeTypeAndValue ::= SEQUENCE {
        type  AttributeType,
        value AttributeValue }

AttributeValue can actually be any type. If e.g. a T61String is used
and you convert it to a UTF-8-encoded string representation there's
an information loss (the information about the original encoding).
I'm not sure whether this affects handling DNs in LDAP but it
affects handling DNs of certificate (in PKIX you might have to hash
the DER-encoding of a DN e.g. in OCSP queries).

I already have some code for a generic X.500 name class (for parsing
certificates). It's not ready for prime time yet but I would like to
improve it and contribute it to python-ldap.

>           (same with LDAPUrl - could be done in the urllib style)

I think it's necessary to have distinguished classes. Because there
are no method signatures in Python we have to distinguish the type
of parameters in many class methods.

Doing e.g. something like isinstance(param,LDAPURL) or other
Pythonism like checking param.__class__.__name__ elps in this
regard.

>         * AttributeSet is just a list

No. ASN.1 type SET is a set which isn't a list. A set has no
particular order. Believe me, you will need it. E.g. think about
comparing to instances of AttributeSet...

>         * can we ignore/hide LDAPExtendedOperation/Response/Listener?
> 
> the java api looks overly complex. after whittling it back a bit, i think
> a nice pythonesqe api could be developed.

If X.500-based standards are involved things will always get
complex. :-(

Especially from my experience with parsing X.509 certs/CRLs I would
strongly argue to stay as close as possible to this I-D. In the long
run it's less work than repairing a limited subset afterwards. Off
course some classes like LDAPExtendedOperation can be
deferred...(though interesting for server-side sorting, virtual list
controls etc.)

Ciao, Michael.