3:03 a.m.
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 ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
4:19 a.m.
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.
5:03 a.m.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
5:58 a.m.
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
6:10 a.m.
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.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
4246
days inactive
4246
days old
openldap-technical@openldap.org
5 comments
3 participants
participants (3)
-
Emmanuel Lécharny -
Kurt Zeilenga -
Michael Ströder