Yep that's what I've been trying to say:
"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."
On 9/20/07, Ersin Er <[EMAIL PROTECTED]> wrote:
>
> 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
>
