Re: (ITS#4639) slurpd parses attribute named delete incorrectly

[Kurt@OpenLDAP.org]

At 10:56 PM 8/14/2006, ken_yap_aus@yahoo.com wrote:
>Full_Name: Ken Yap
>Version: 2.3
>OS: SUSE 10.1 (GNU/Linux)
>URL: 
>Submission from: (NULL) (220.233.132.138)
>
>
>The schema contains an attribute called delete. It's the JAMM schema
>(jamm.sf.net).
>
>These lines were left behind in a .rej file:
>
>ERROR: Undefined attribute type: FALSE: attribute type undefined
>replica: ldap2.bar.com:389
>time: 1155618838.3
>dn: mail=fred@bar.com,jvd=bar.com,o=hosting,dc=myhosting,dc=bar
>changetype: modify
>replace: delete
>delete: FALSE
>
>I believe the problem is that the LDIF parser sees delete as a keyword rather
>than as an attribute at that point.

I consider the behavior a feature than a bug.  LDIF parsers
should be liberal in what they accept as many LDIF files are
created by humans, which are generally not strict in what
they produce.  The LDIF keywords should be regarded as
reserved.

I am more inclined to regard this as a new feature request to
support a 'strict' mode.

Regardless, I doubt any developer will invest time/energy to
address this issue.  slurpd(8) is considered deprecated in favor
of syncrepl.  This is just one more reason why it might be good
to remove slurpd(8) from future releases.

There are two obvious workarounds to this problem.  One is to
rename the attribute type.  The second is to use syncrepl
instead of slurpd(8).

Kurt