In the last episode (Aug 21), Henrik Grubbström said:
> On Thu, 20 Aug 2009, Martin Stjernholm wrote:
> > Dan Nelson <<dnelson[at]allantgroup.com>> wrote:
> >> There seems to be other issues with 7.8's ldap module. Trying to fetch
> >> always throws an error parsing the schema. I tried against Novell
> >> eDirectory, Lotus Domino, and IBM Tivoli Directory Server
> >> implementations and failed each time:
> >>
> >> (<dan[at]dan.16>) /usr/tmp/pike/build/freebsd-7.2-stable-i386> ./test-pike
> >> Pike v7.8 release 337 running Hilfe v3.5 (Incremental Pike Frontend)
> >>>
Protocols.LDAP.client("ldap://domino/??sub")->search("(cn=*nelson*)")->fetch();
> >> Error in attributeTypes when querying schema: Invalid chars in quoted descr
after term "NAME" at pos 19: "( id-at-Domino.123 NAME '.123' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )"
> >
> > The problem is the period in '.123' - it is not allowed according to
> > rfc 4512, section 4.1.1. Protocols.LDAP could be more relaxed there,
> > but I wonder how relaxed - e.g. if there's some "best practice" or
> > similar in this area.
>
> I seem to recall that there used to be a similar problem with
> Protocols.DNS and the domainname 123.org.
This is a little different, I think. Waybackwhen, rfc 1034 section 3.5
recommended starting domains with a letter but doesn't mandate it, then rfc
1123 section 2.1 required you to allow leading digits, and now rfc 3696
section 2 explicitly allows all characters, but recommends a subset. So to
conform to the RFC, Protocols.DNS shouldn't restrict you at all either.
That particular example may have just been a misguided check for ip
addreses, though ("if it starts with a number it must be an IP, not a domain
name").
As for LDAP, the BNF tables in rfc 4512 say that LDAP schema names have to
start with a letter and you're only allowed to backslash-escape "'" and "\".
However, I've got three LDAP stores that violate those rules, and neither
openldap, Apache Directory Studio, or JXplorer seem to mind, so this seems
more like a case where the RFC doesn't describe reality. Protocls.LDAP
should be able to read non-conforming data, but I'd be okay with it refusing
to write bad data.
--
Dan Nelson
<dnelson[at]allantgroup.com>
|