replication and 'no objectclass attribute' message

[Peter Duffy <peter@supanet.net.uk>]

I've been noticing recently that a number of our servers (seemingly only
when they're running 2.0.7+) generate messages when processing updates
like: 

"Oct 17 04:04:26 wart slapd[13557]:
is_entry_objectclass("uid=xxxxx,ou=customer,dc=netline,dc=net,dc=uk",
"2.16.840.1.113730.3.2.6") no objectClass attribute" 

- but the replication works, and the replicated entry matches the
original.

I noticed that there had already been some comment and discussion about
this message on the List. I decided to dig into the source and try to
understand what was going on, and whether a problem was indicated: I
believe I've now figured it out, and I'd be grateful if someone could
check my analysis:

As far as I can make out, the message results when a client sends an
update with the ManageDsaIT control set (I believe slurpd always does
set it), and the entry is not a referral.
(draft-zeilenga-ldap-namedref-xx.txt line 147 et seq states that in the
presence of this control, referrals are to be treated as normal entries,
so this would give a client setting this control the power to actually
place a referral entry into the tree.) Unfortunately, at present, the
test to check whether or not an entry contains an objectClass attribute
of type referral maps via a macro to the is_entry_objectclass function,
which always prints a warning message if it doesn't find the objectclass
type it is looking for (sorry if this is a clumsy explanation.)

Have I at least understood the basis of this correctly, and am I right
in thinking that the message doesn't really represent a problem? If so,
I'd like to suggest that it might be better if the macro
is_entry_referral was rewritten as a separate function based on
is_entry_objectclass, to give finer control over the content and level
of the warning message.