Hi guys,
the following Syntax are missing in the cn=subschema LDAPSyntaxes list, while those syntaxes are refered by many ATs :
AttributeTypeDescription DataQualitySyntax DSAQualitySyntax EnhancedGuide Fax Guide LdapSyntaxDescription MatchingRuleDescription MatchingRuleUse Description ObjectClassDescription PresentationAddress ProtocolInformation TeletexTerminalInformation
I guess that the server does not care too much as most of those Syntax (and associated AT) are not manipulated frequently by users, and the server might have a default handling of AT without syntax. In Apache Directory Studio and the Java LDAP API, it's a bit more annoying, as we try to load the full schema from the server to locally check that values are correct before sending them back to the server. We have a mechanism to 'bypass' the missing syntaxes, of course, but I think that from a completness POV, it would be better if OpenLDAP add those missing syntaxes...
Does it deserver an ITS ?
Emmanuel Lécharny wrote:
In Apache Directory Studio and the Java LDAP API, it's a bit more annoying, as we try to load the full schema from the server to locally check that values are correct before sending them back to the server. We have a mechanism to 'bypass' the missing syntaxes, of course, but I think that from a completness POV, it would be better if OpenLDAP add those missing syntaxes...
As a developer of a generic, schema-aware LDAPv3 client you should prepared to deal with incomplete/false subschema. Otherwise your client will joke very often.
Most work for schema support in my web2ldap was caused by incomplete schema elements in various LDAP server implementations (see also my various ITS for getting missing attribute types visible in OpenLDAP). There are various override/fallback mechanisms in web2ldap to make best possible use of the subschema while trying not to get stuck if schema is false, incomplete or simply not accessible because of stupid access control. Last schema work-around added in python-ldap was for duplicate OIDs found in standard subschema shipped with Novell eDirectory...
Ciao, Michael.
Le 2/14/12 1:19 PM, Michael Ströder a écrit :
Emmanuel Lécharny wrote:
In Apache Directory Studio and the Java LDAP API, it's a bit more annoying, as we try to load the full schema from the server to locally check that values are correct before sending them back to the server. We have a mechanism to 'bypass' the missing syntaxes, of course, but I think that from a completness POV, it would be better if OpenLDAP add those missing syntaxes...
As a developer of a generic, schema-aware LDAPv3 client you should prepared to deal with incomplete/false subschema. Otherwise your client will joke very often.
We *are* ready to handle such schemas. M$ AD is most certainly the worst use case around. The question is more about OpenLDAP compliance : does those missing Syntaxes deserve an ITS or not.
On Feb 14, 2012, at 5:03 AM, Emmanuel Lécharny wrote:
Le 2/14/12 1:19 PM, Michael Ströder a écrit :
Emmanuel Lécharny wrote:
In Apache Directory Studio and the Java LDAP API, it's a bit more annoying, as we try to load the full schema from the server to locally check that values are correct before sending them back to the server. We have a mechanism to 'bypass' the missing syntaxes, of course, but I think that from a completness POV, it would be better if OpenLDAP add those missing syntaxes...
As a developer of a generic, schema-aware LDAPv3 client you should prepared to deal with incomplete/false subschema. Otherwise your client will joke very often.
We *are* ready to handle such schemas. M$ AD is most certainly the worst use case around. The question is more about OpenLDAP compliance
Compliance?
RFC 4512: Clients SHOULD NOT assume that a published subschema is complete, that the server supports all of the schema elements it publishes, or that the server does not support an unpublished element.
: does those missing Syntaxes deserve an ITS or not.
Generally speaking, if it's missing, it's missing for a reason... generally that reason is the syntax is not implemented, or implemented to the degree needed to one to have a userApplications attribute using that syntax.
This can be viewed as a signal to the client application that listed attributes of that syntax cannot be stored/modified in the subtree of the subschema controls.
-- Kurt
-- Regards, Cordialement, Emmanuel Lécharny www.iktek.com
Le 2/14/12 2:58 PM, Kurt Zeilenga a écrit :
On Feb 14, 2012, at 5:03 AM, Emmanuel Lécharny wrote:
Le 2/14/12 1:19 PM, Michael Ströder a écrit :
Emmanuel Lécharny wrote:
In Apache Directory Studio and the Java LDAP API, it's a bit more annoying, as we try to load the full schema from the server to locally check that values are correct before sending them back to the server. We have a mechanism to 'bypass' the missing syntaxes, of course, but I think that from a completness POV, it would be better if OpenLDAP add those missing syntaxes...
As a developer of a generic, schema-aware LDAPv3 client you should prepared to deal with incomplete/false subschema. Otherwise your client will joke very often.
We *are* ready to handle such schemas. M$ AD is most certainly the worst use case around. The question is more about OpenLDAP compliance
Compliance?
RFC 4512: Clients SHOULD NOT assume that a published subschema is complete, that the server supports all of the schema elements it publishes, or that the server does not support an unpublished element.
Compliance is most certainly the wrong word in this context :) Excuse my french !
: does those missing Syntaxes deserve an ITS or not.
Generally speaking, if it's missing, it's missing for a reason... generally that reason is the syntax is not implemented, or implemented to the degree needed to one to have a userApplications attribute using that syntax.
This can be viewed as a signal to the client application that listed attributes of that syntax cannot be stored/modified in the subtree of the subschema controls.
I'm not sure the client application is smart enough to infer such a meaning ;) Although I think that Syntax like Fax, Guide, EnhancedGuide and a few others are just missing because nobody store such data in LDAP any more... (my own perception of course).
Ok thanks for those explainations.
openldap-technical@openldap.org
-
Emmanuel Lécharny -
Kurt Zeilenga -
Michael Ströder