I perfectly understand the problem here and I tried to choose the best solution at the time of implementing this with relevant conditions. So, let's develop a new plan and consult to the guys at IEFT.
On 9/20/07, Alex Karasulu <[EMAIL PROTECTED]> wrote: > > OK you're not getting what I am trying to say. If you take the > X.500constructs based on > ASN.1 and overlay them onto the LDAP plane using the traditional means to > map them over with EBNF then you're going to have a problem. Steven is > trying to doing this now and when he does that he's going to constrain > filters if that's the representation he chooses to use, to only allow > objectClass attributes. > > If he uses a constrained filter (only with objectClass attributes) instead > of some alternate representation for refinement expressions, then we're > good. If he does not then we have a problem. > > Does this explanation make more sense? > > Alex > > > On 9/20/07, Ersin Er < [EMAIL PROTECTED]> wrote: > > > > This is an LDAP extension. It cannot be expressed in terms of > > X.500constructs. Current grammar cannot be expressed with > > ASN.1 because it breaks the ASN.1-to-String encoding schemes. I had also > > discussed this on the page I have pasted on this thread I think. > > > > On 9/20/07, Alex Karasulu < [EMAIL PROTECTED]> wrote: > > > > > > Ok we need to talk to Steven Legg who's working on those admin model > > > drafts currently > > > about this. It's very important that we align with the new > > > specifications which will emerge. > > > > > > Alex > > > > > > On 9/20/07, Ersin Er <[EMAIL PROTECTED]> wrote: > > > > > > > > BTW, here is my discussion on the topic I wrote down before: > > > > > > > > http://cwiki.apache.org/confluence/display/DIRxSRVx11/Administrative+Model+Extensions > > > > > > > > > > > > On 9/20/07, Ersin Er < [EMAIL PROTECTED]> wrote: > > > > > > > > > > Hi, > > > > > > > > > > I considered this before and concluded with the most appropriate > > > > > solution IMO. Current solution is completely backward compatible. The > > > > > syntax > > > > > supports both refinements and filters for the specificationFilter > > > > > component > > > > > of the subtreeSpecification. > > > > > > > > > > I can try to explain more why I did not choose other alternative > > > > > if you wish. > > > > > > > > > > > > > > > On 9/20/07, Alex Karasulu < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > Ersin, > > > > > > > > > > > > I got an interesting idea while thinking about subtrees and > > > > > > specifications. As you know we complied > > > > > > up until recently strictly with the X.500 administrative model > > > > > > with respect to subtreeSpecifications. The > > > > > > changes we added to handle refinements which were filters broke > > > > > > away from X.500 in many ways. > > > > > > > > > > > > I was just thinking that it may be possible to use an > > > > > > extendedSubtreeSpecification attribute which > > > > > > extends a subtreeSpecification. However the only problem with > > > > > > this is the fact that the attributeType > > > > > > subtyping another cannot switch the SYNTAX of the AT. This is > > > > > > what I always thought but perhaps > > > > > > I am wrong (I hope) but if I am wrong I think we can leverage AT > > > > > > extension while remaining compliant. > > > > > > > > > > > > Basically we can allow our subentry objectClasses to include > > > > > > extendedSubtreeSpecifications instead > > > > > > of just the usual subtreeSpecification. > > > > > > > > > > > > WDYT? > > > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Ersin Er > > > > > http://www.ersin-er.name > > > > > > > > > > > > > > > > > > > > -- > > > > Ersin Er > > > > http://www.ersin-er.name > > > > > > > > > > > > > > > > -- > > Ersin Er > > http://www.ersin-er.name > > > > -- Ersin Er http://www.ersin-er.name
