directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] extendedSubtreeSpecification
Date Thu, 20 Sep 2007 06:04:53 GMT
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 <ersin.er@gmail.com> 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 <akarasulu@apache.org> 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 <ersin.er@gmail.com> 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 < ersin.er@gmail.com> 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 < akarasulu@apache.org> 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
>

Mime
View raw message