Doesn't include the required "objectclass" attribute
Instead, it tacks an "OBJECTCLASS" element to the end of the DN,
as shown above.
Doesn't insert parents into the LDAP server
This is a clear violation of the LDAP standard, which requires
parents to exist before children can be created. I.e, to insert
this DN:
CN=xxx@abc.com, O=Microsoft, C=US
this DN must already exist:
O=Microsoft, C=US
as must this one:
C=US
Doesn't understand attribute aliases, and is therefore unable
to recognize that "sn" and "surname" refer to the same attribute.
Requires that attributes in a search request be returned in
exactly the same order they were requested, a requirement not
guaranteed by the OpenLDAP server.
Specifies "base" scope in search requests, when it really should
use "sub", since it wants a list of entries, not just one
Uses the "%" character as wildcard in search requests, instead
of the "*" character specified by the standard.
Uses a non-standard means of refreshing dynamic entries.
The Microsoft server maintains an "sttl" attribute, which is a
time to live for the entry in minutes. A search request for
attribute "sttl" resets the timer. If the timer goes to zero,
the entry is supposed to disappear from the database.
NetMeeting 2 supplies an "sttl" attribute, but
NetMeeting 3 doesn't actually
create the "sttl" attribute at all. Also,
the client doesn't bother to give us the whole DN it wants updated,
only supplying the "cn" component.