Full_Name: Paul Makepeace Version: 1.2.1, BDB 2.7.3 OS: Solaris 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (163.185.164.194) openldap:dbm$ /usr/local/sbin/ldbmcat archive/id2entry.dbb | grep 'dn: .*, ' dn: cn=Paul Makepeace, LDAP deployment,ou=hacker,dc=realprogrammers,dc=com Commas which appear in RDNs are not being escaped as \, but appear unadorned. http://www.ietf.org/rfc/rfc2253.txt, section 2.4 says: If the UTF-8 string does not have any of the following characters which need escaping, then that string can be used as the string representation of the value. o a space or "#" character occurring at the beginning of the string o a space character occurring at the end of the string o one of the characters ",", "+", """, "\", "<", ">" or ";" Implementations MAY escape other characters. If a character to be escaped is one of the list shown above, then it is prefixed by a backslash ('\' ASCII 92). Otherwise the character to be escaped is replaced by a backslash and two hex digits, which form a single byte in the code of the character. --
Paul.Makepeace@realprogrammers.com wrote: >Subject: ldbmcat does not produce RFC2253 DN: linesAt 03:21 PM 4/21/99 GMT, Note: If you are going to quote an RFC, get the right one! OpenLDAP is currently LDAPv2, hence RFC1779 is more applicable. Of course, both require ',' within RDN values to be quoted. >Subject: ldbmcat does not produce RFC2253 DN: lines ldbmcat doesn't produce DNs. It just prints what it finds. How did the DN get added to the directory? I suspect you used ldif2ldbm. ldif2ldbm does NO schema checking (it's a database recovery tool). To ldif2ldbm, it's just a string. When adding new data to your directory, I recommend using ldapadd/modify. However, even here, you must realize that our schema checking codes are somewhat dated and lax in comparision with commericial vendors. I should also note that we also still support an alternative e-mail/domain DN format (dn: kurt@openldap.org) which complicates DN checking. We'll likely depreciate this older format in our LDAPv3 implementation to facilate LDAPv3 DN checking. Kurt
On Wed, 21 Apr 1999, Kurt@OpenLDAP.org wrote: > I should also note that we also still support an alternative > e-mail/domain DN format (dn: kurt@openldap.org) which complicates > DN checking. We'll likely depreciate this older format in our "Deprecate"{*}. :-) > LDAPv3 implementation to facilate LDAPv3 DN checking. Speaking of LDAPv3, does the OpenLDAP Development Roadmap include the ability to feed in new-style attributes/objects along the lines of RFC 2256 (ie., includes OIDs, syntax, &c.)? Just as at the moment standardised format MIBs can be fed into almost any SNMP application to increase its functionality, it'd be nice to feed these attribute/object definitions straight into OpenLDAP instead of the current arrangement of hacking the "at" and "oc" files... {*} I wasn't intentionally trying to be pedantic; it's just curious that it's becoming increasingly common to see some words being completely substituted with something else (like "authentification" instead of "authentication", or "depreciate" instead of "deprecate"). *shrug* Cheers.. dave
d.begley@nepean.uws.edu.au wrote: > Speaking of LDAPv3, does the OpenLDAP Development Roadmap include the ability > to feed in new-style attributes/objects along the lines of RFC 2256 (ie., > includes OIDs, syntax, &c.)? Affirmative. The exact details will have to be worked out, but work has started. It is unclear, however, whether you will be able to add syntaxes, since they are little more than an OID and a long textual description about what they are supposed to mean. In other words, complete support for a syntax requires code. Julio
Earlier today, Julio Sánchez Fernández wrote: > d.begley@nepean.uws.edu.au wrote: > > > Speaking of LDAPv3, does the OpenLDAP Development Roadmap include the ability > > to feed in new-style attributes/objects along the lines of RFC 2256 (ie., > > includes OIDs, syntax, &c.)? > > Affirmative. The exact details will have to be worked out, but work has > started. It is unclear, however, whether you will be able to add syntaxes, > since they are little more than an OID and a long textual description about > what they are supposed to mean. In other words, complete support for a syntax > requires code. True.. aren't the syntaxes "fixed" though (ie., I thought I saw an RFC that explained each of the possible syntax types for attributes)? Or can anyone essentially define their own syntaxes? dave
changed notes changed state Open to Closed
garbage in, garbage out.