Zhang Weiwu writes:
> What if we change the syntax of PostalAddress, change the
> caseIgnoreListSubstringsMatch to something else for our particular
> installation? Can this solve the problem just for me? I know this is
> not standard but I must solve customer's problem in a timely fasion
> and unfortunately this is a big problem for my customer (they bought
> the LDAP system in order to search postalAddress!)
That may work. It won't work quite right - e.g. whitespace around '$'
separators are not handled properly.
For OpenLDAP, this in core.schema should do for a server side change:
attributetype ( 2.5.4.16 NAME 'postalAddress'
DESC 'RFC2256: postal address (hacked definition, not quite right)'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
You should probably slapcat the database before changing the syntax and
rebuild a new database with slapadd afterwards. Don't know if it's
necessary in this case but mucking with the schema of existing entries
does not seem like a good idea.
How your clients like it is another matter.
With plain '$' characters for separators like the normal postalAddress
syntax, a client which knows postalAttribute's expected syntax will work
reasonably well.
A client which reads the attribute syntaxes from the server and acts
accordingly, will treat the '$' as a plain character instead of a
separator, and will not treat '\' as an escape character for (for $ and
\). And who knows what it'll do if it tries to construct a
postalAddress from internal data and add it to the server.
Maybe it'll work better to use newline as a separator instead of '$'.
Translating between that and postalAddress syntax, remember to convert
newlines, $ and \ characters. Then clients using the '$' separator will
misbehave though.
> We should be able to first re-define postalAddress and wait for openldap to
> update their software (in the next revision) and change it back later then.
It's in the next revision? Maybe you could get some files from the CVS
sources or the latest alpha release then. Since it's OpenLDAP I suggest
you ask at the openldap-software list.
> I knew it is a better idea to separate postalAddress to
> st,l,street,roomNumber but the data before we implemented OpenLDAP
> mess them up in one field, for historical reasons. The customer used
> it this way for 8 years and don't wish to see a change, especially any
> change involve human work.
I wouldn't want such a change in our server either. Much more
cumbersome for applications that just want to display the address.
Also, foreign applications would not assemble the fields right for
Norwegian addresses.
--
Hallvard
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED]
To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the
SUBJECT of the message.
