As mentioned, NetMeeting violates the LDAP protocol in several ways. For the record, NetMeeting:
Doesn't structure Distinguished Names (DNs) properly
NetMeeting puts the most significant elements in the DN first, instead of last, using:
C=US, O=Microsoft, CN=xxx@abc.com, OBJECTCLASS=rtperson
instead of the proper formating, which is:
CN=xxx@abc.com, O=Microsoft, C=US
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.