upstream/openldap
1
0
Fork 0
mirror of https://git.openldap.org/openldap/openldap.git synced 2026-01-02 04:59:39 -05:00
Code Issues Projects Releases Packages Wiki Activity Actions

More ldapbis cleanup

Browse source
This commit is contained in:
Kurt Zeilenga 2006-10-28 04:47:58 +00:00
parent 99b954e2c3
commit dbaf7c5c25
5 changed files with 20 additions and 21 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

19
libraries/libldap/getdn.c
View file

@ -337,9 +337,8 @@ ldap_dn2ad_canonical( LDAP_CONST char *dn )
* from ( fin & LDAP_DN_FORMAT_MASK ) to ( fout & LDAP_DN_FORMAT_MASK )
*
* fin can be one of:
* LDAP_DN_FORMAT_LDAP (RFC 4514 and ldapbis liberal,
* plus some RFC 1779)
* LDAP_DN_FORMAT_LDAPV3 (RFC 4514 and ldapbis)
* LDAP_DN_FORMAT_LDAP (RFC 4514 liberal, plus some RFC 1779)
* LDAP_DN_FORMAT_LDAPV3 (RFC 4514)
* LDAP_DN_FORMAT_LDAPV2 (RFC 1779)
* LDAP_DN_FORMAT_DCE (?)
*
@ -433,14 +432,14 @@ ldap_dn_normalize( LDAP_CONST char *dnin,
#define LDAP_DN_VALUE_END(c) \
( LDAP_DN_RDN_SEP(c) || LDAP_DN_AVA_SEP(c) )
/* NOTE: according to draft-ietf-ldapbis-dn, '=' can be escaped
* and treated as special, i.e. escaped both as "\<hexpair>" and
* as "\=", but it is treated as a regular char, i.e. it can also
* appear as '='.
/* NOTE: according to RFC 4514, '=' can be escaped and treated as special,
* i.e. escaped both as "\<hexpair>" and * as "\=", but it is treated as
* a regular char, i.e. it can also appear as '='.
*
* As such, in 2.2 we used to allow reading unescaped '=',
* but we always produced escaped '\3D'; this changes
* since 2.3, if compatibility issues do not arise */
* As such, in 2.2 we used to allow reading unescaped '=', but we always
* produced escaped '\3D'; this changes since 2.3, if compatibility issues
* do not arise
*/
#define LDAP_DN_NE(c) \
( LDAP_DN_RDN_SEP_V2(c) || LDAP_DN_AVA_SEP(c) \
|| LDAP_DN_QUOTES(c) \

2
libraries/libldap/schema.c
View file

@ -1028,7 +1028,7 @@ get_token( const char ** sp, char ** token_val )
**sp != '$' &&
**sp != '\'' &&
/* for suggested minimum upper bound on the number
* of characters <draft-ietf-ldapbis-syntaxes> */
* of characters (RFC 4517) */
**sp != '{' &&
**sp != '\0' )
(*sp)++;

2
servers/slapd/back-ldap/chain.c
View file

@ -421,7 +421,7 @@ ldap_chain_op(
/* We're setting the URI of the first referral;
* what if there are more?
Document: draft-ietf-ldapbis-protocol-27.txt
Document: RFC 4511
4.1.10. Referral
...

4
servers/slapd/filterentry.c
View file

@ -276,14 +276,14 @@ static int test_mra_filter(
if ( normalize_attribute && mra->ma_rule->smr_normalize ) {
/*
Document: draft-ietf-ldapbis-protocol
Document: RFC 4511
4.5.1. Search Request
...
If the type field is present and the matchingRule is present,
the matchValue is compared against entry attributes of the
specified type. In this case, the matchingRule MUST be one
suitable for use with the specified type (see [Syntaxes]),
suitable for use with the specified type (see [RFC4517]),
otherwise the filter item is Undefined.

14
servers/slapd/schema_init.c
View file

@ -795,7 +795,7 @@ bitStringValidate(
[X.520].
*
* draft-ietf-ldapbis-models-xx.txt [MODELS] says:
* RFC 4512 says:
*
1.4. Common ABNF Productions
@ -813,11 +813,11 @@ bitStringValidate(
*
* 1.3.6.1.4.1.1466.0=#04024869,o=test,c=gb#'101'B
*
* Since draft-ietf-ldapbis-dn-xx.txt clarifies that SHARP,
* i.e. "#", doesn't have to be escaped except when at the
* beginning of a value, the definition of Name and Optional
* UID appears to be flawed, because there is no clear means
* to determine whether the UID part is present or not.
* RFC 4514 clarifies that SHARP, i.e. "#", doesn't have to
* be escaped except when at the beginning of a value, the
* definition of Name and Optional UID appears to be flawed,
* because there is no clear means to determine whether the
* UID part is present or not.
*
* Example:
*
@ -1263,7 +1263,7 @@ Summary:
TelephoneNumber subset subset i + ignore all spaces and "-"
See draft-ietf-ldapbis-strpro for details (once published).
See RFC 4518 for details.
Directory String -