mirror of
https://git.openldap.org/openldap/openldap.git
synced 2026-02-01 11:29:27 -05:00
Move large string comment to just above UTF8StringValidate().
This commit is contained in:
Kurt Zeilenga
parent
50d490be6c
commit
4a4323e3b7
1 changed files with 76 additions and 72 deletions
|
|
@ -5,74 +5,6 @@
|
|||
* COPYING RESTRICTIONS APPLY, see COPYRIGHT file
|
||||
*/
|
||||
|
||||
/****
|
||||
LDAP/X.500 string syntax / matching rules have a few oddities. This
|
||||
comment attempts to detail how slapd(8) treats them.
|
||||
|
||||
Summary:
|
||||
StringSyntax X.500 LDAP Matching
|
||||
DirectoryString CHOICE UTF8 i/e + ignore insignificant spaces
|
||||
PrintableString subset subset i/e + ignore insignificant spaces
|
||||
NumericString subset subset ignore all spaces
|
||||
IA5String ASCII ASCII i/e + ignore insignificant spaces
|
||||
TeletexString T.61 T.61 i/e + ignore insignificant spaces
|
||||
|
||||
TelephoneNumber subset subset i + ignore all spaces and "-"
|
||||
|
||||
See draft-ietf-ldapbis-strpro for details (once published).
|
||||
|
||||
|
||||
Directory String -
|
||||
In X.500(93), a directory string can be either a PrintableString,
|
||||
a bmpString, or a UniversalString (e.g., UCS (a subset of Unicode)).
|
||||
In later versions, more CHOICEs were added. In all cases the string
|
||||
must be non-empty.
|
||||
|
||||
In LDPAv3, a directory string is a UTF-8 encoded UCS string.
|
||||
|
||||
For matching, there are both case ignore and exact rules. Both
|
||||
also require that "insignificant" spaces be ignored.
|
||||
spaces before the first non-space are ignored;
|
||||
spaces after the last non-space are ignored;
|
||||
spaces after a space are ignored.
|
||||
Note: by these rules (and as clarified in X.520), a string of only
|
||||
spaces is to be treated as if held one space, not empty (which would
|
||||
be a syntax error).
|
||||
|
||||
NumericString
|
||||
In ASN.1, numeric string is just a string of digits and spaces and
|
||||
could be empty. However, in X.500, all attribute values of numeric
|
||||
string carry a non-empty constraint. For example:
|
||||
|
||||
internationalISDNNumber ATTRIBUTE ::= {
|
||||
WITH SYNTAX InternationalISDNNumber
|
||||
EQUALITY MATCHING RULE numericStringMatch
|
||||
SUBSTRINGS MATCHING RULE numericStringSubstringsMatch
|
||||
ID id-at-internationalISDNNumber }
|
||||
InternationalISDNNumber ::= NumericString (SIZE(1..ub-international-isdn-number))
|
||||
|
||||
Unfornately, some assertion values are don't carry the same constraint
|
||||
(but its unclear how such an assertion could ever be true). In LDAP,
|
||||
there is one syntax (numericString) not two (numericString with constraint,
|
||||
numericString without constraint). This should be treated as numericString
|
||||
with non-empty constraint. Note that while someone may have no
|
||||
ISDN number, there are no ISDN numbers which are zero length.
|
||||
|
||||
In matching, spaces are ignored.
|
||||
|
||||
PrintableString
|
||||
In ASN.1, Printable string is just a string of printable characters and
|
||||
can be empty. In X.500, semantics much like NumericString (see serialNumber
|
||||
for a like example) excepting uses insignificant space handling instead of
|
||||
ignore all spaces.
|
||||
|
||||
IA5String
|
||||
Basically same as PrintableString. There are no examples in X.500, but
|
||||
same logic applies. So we require them to be non-empty as well.
|
||||
|
||||
****/
|
||||
|
||||
|
||||
#include "portable.h"
|
||||
|
||||
#include <stdio.h>
|
||||
|
|
@ -556,6 +488,76 @@ booleanMatch(
|
|||
return LDAP_SUCCESS;
|
||||
}
|
||||
|
||||
/*-------------------------------------------------------------------
|
||||
LDAP/X.500 string syntax / matching rules have a few oddities. This
|
||||
comment attempts to detail how slapd(8) treats them.
|
||||
|
||||
Summary:
|
||||
StringSyntax X.500 LDAP Matching
|
||||
DirectoryString CHOICE UTF8 i/e + ignore insignificant spaces
|
||||
PrintableString subset subset i/e + ignore insignificant spaces
|
||||
NumericString subset subset ignore all spaces
|
||||
IA5String ASCII ASCII i/e + ignore insignificant spaces
|
||||
TeletexString T.61 T.61 i/e + ignore insignificant spaces
|
||||
|
||||
TelephoneNumber subset subset i + ignore all spaces and "-"
|
||||
|
||||
See draft-ietf-ldapbis-strpro for details (once published).
|
||||
|
||||
|
||||
Directory String -
|
||||
In X.500(93), a directory string can be either a PrintableString,
|
||||
a bmpString, or a UniversalString (e.g., UCS (a subset of Unicode)).
|
||||
In later versions, more CHOICEs were added. In all cases the string
|
||||
must be non-empty.
|
||||
|
||||
In LDPAv3, a directory string is a UTF-8 encoded UCS string.
|
||||
|
||||
For matching, there are both case ignore and exact rules. Both
|
||||
also require that "insignificant" spaces be ignored.
|
||||
spaces before the first non-space are ignored;
|
||||
spaces after the last non-space are ignored;
|
||||
spaces after a space are ignored.
|
||||
Note: by these rules (and as clarified in X.520), a string of only
|
||||
spaces is to be treated as if held one space, not empty (which
|
||||
would be a syntax error).
|
||||
|
||||
NumericString
|
||||
In ASN.1, numeric string is just a string of digits and spaces
|
||||
and could be empty. However, in X.500, all attribute values of
|
||||
numeric string carry a non-empty constraint. For example:
|
||||
|
||||
internationalISDNNumber ATTRIBUTE ::= {
|
||||
WITH SYNTAX InternationalISDNNumber
|
||||
EQUALITY MATCHING RULE numericStringMatch
|
||||
SUBSTRINGS MATCHING RULE numericStringSubstringsMatch
|
||||
ID id-at-internationalISDNNumber }
|
||||
InternationalISDNNumber ::=
|
||||
NumericString (SIZE(1..ub-international-isdn-number))
|
||||
|
||||
Unforunately, some assertion values are don't carry the same
|
||||
constraint (but its unclear how such an assertion could ever
|
||||
be true). In LDAP, there is one syntax (numericString) not two
|
||||
(numericString with constraint, numericString without constraint).
|
||||
This should be treated as numericString with non-empty constraint.
|
||||
Note that while someone may have no ISDN number, there are no ISDN
|
||||
numbers which are zero length.
|
||||
|
||||
In matching, spaces are ignored.
|
||||
|
||||
PrintableString
|
||||
In ASN.1, Printable string is just a string of printable characters
|
||||
and can be empty. In X.500, semantics much like NumericString (see
|
||||
serialNumber for a like example) excepting uses insignificant space
|
||||
handling instead of ignore all spaces.
|
||||
|
||||
IA5String
|
||||
Basically same as PrintableString. There are no examples in X.500,
|
||||
but same logic applies. So we require them to be non-empty as
|
||||
well.
|
||||
|
||||
-------------------------------------------------------------------*/
|
||||
|
||||
static int
|
||||
UTF8StringValidate(
|
||||
Syntax *syntax,
|
||||
|
|
@ -665,7 +667,7 @@ UTF8StringNormalize(
|
|||
assert( q+len <= p );
|
||||
|
||||
/* cannot start with a space */
|
||||
assert( !ASCII_SPACE(normalized->bv_val[0]) );
|
||||
assert( !ASCII_SPACE( normalized->bv_val[0] ) );
|
||||
|
||||
/*
|
||||
* If the string ended in space, backup the pointer one
|
||||
|
|
@ -717,10 +719,12 @@ UTF8SubstringsassertionNormalize(
|
|||
for( i=0; sa->sa_any[i].bv_val != NULL; i++ ) {
|
||||
/* empty */
|
||||
}
|
||||
nsa->sa_any = (struct berval *)ch_malloc( (i + 1) * sizeof(struct berval) );
|
||||
nsa->sa_any = (struct berval *)
|
||||
ch_malloc( (i + 1) * sizeof(struct berval) );
|
||||
|
||||
for( i=0; sa->sa_any[i].bv_val != NULL; i++ ) {
|
||||
UTF8bvnormalize( &sa->sa_any[i], &nsa->sa_any[i],
|
||||
casefold );
|
||||
casefold );
|
||||
if( nsa->sa_any[i].bv_val == NULL ) {
|
||||
goto err;
|
||||
}
|
||||
|
|
@ -739,7 +743,7 @@ UTF8SubstringsassertionNormalize(
|
|||
|
||||
err:
|
||||
if ( nsa->sa_final.bv_val ) free( nsa->sa_final.bv_val );
|
||||
if ( nsa->sa_any )ber_bvarray_free( nsa->sa_any );
|
||||
if ( nsa->sa_any ) ber_bvarray_free( nsa->sa_any );
|
||||
if ( nsa->sa_initial.bv_val ) free( nsa->sa_initial.bv_val );
|
||||
ch_free( nsa );
|
||||
return NULL;
|
||||
|
|
|
|||
Loading…
Reference in a new issue