directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kirill Kovalenko (JIRA)" <>
Subject [jira] Commented: (DIREVE-228) Schema container issue.
Date Fri, 19 Aug 2005 11:38:54 GMT
    [ ] 

Kirill Kovalenko commented on DIREVE-228:

> I faced problems due to this one with Softerra LDAP Browser 2.6, when I was trying to
find/fix this bug
> This browser provides a schema cache, which is even not refreshed after a restart, if
the server fails to give the 
> attribute Kirill mentioned. I had to delete the cache on disk in order verify that my
Fix for DIREVE-227 works 
> with this client. 

Just FYI: 
LDAP Browser supports manual schema reload. (Profiles properties->LDAP Settings->Advanced->LDAP
Schema->Reload schema). The application restart required. 

> Schema container issue.
> -----------------------
>          Key: DIREVE-228
>          URL:
>      Project: Directory Server
>         Type: Bug
>   Components: schema
>     Versions: 0.9.2
>     Reporter: Kirill Kovalenko
>     Assignee: Alex Karasulu

> 1) It looks like that recently implemented [1],[2] RFC3673 support (all operational attributes)
doesn't work for the schema entry. Attributes objectClasses, matchingRules, attributeTypes
are not returned when '+' special attribute is used. 
> 2) Schema container doesn't seem to provide modifyTimestamp attribute. Absence of modifyTimestamp
attribute makes it impossible for client to track schema modifications easily. 
> Here is what RFC2251 [3] says about it (section 3.2.2).
>    Servers SHOULD provide the attributes createTimestamp and
>    modifyTimestamp in subschema entries, in order to allow clients to
>    maintain their caches of schema information.
> [1]
> [2]
> [3]

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message