[Date Prev][Date Next] [Chronological] [Thread] [Top]
RE: Clarification of RootDSE information retrieval required

To: ietf-ldapext@netscape.com
Subject: RE: Clarification of RootDSE information retrieval required
From: "Salter, Thomas A" <Thomas.Salter@unisys.com>
Date: Tue, 24 Nov 1998 14:48:08 -0500
Resent-date: Tue, 24 Nov 1998 11:48:21 -0800 (PST)
Resent-from: ietf-ldapext@netscape.com
Resent-message-id: <"N-qVt.0.Cv5.1smMs"@glacier>
Resent-sender: ietf-ldapext-request@netscape.com
Perhaps the problem is in the definition of the root attributes, not in
the protocol.  Why not just change the defintion of these attributes so
they are User rather than Operational.  Then there is no need for to
make a special case of root.


> -----Original Message-----
> From: Erik Skovgaard [mailto:eskovgaard@geotrain.com]
> Sent: Tuesday, November 24, 1998 12:35 PM
> To: Bruce Greenblatt
> Cc: ietf-ldapext@netscape.com
> Subject: Re: Clarification of RootDSE information retrieval required
> 
> 
> Bruce,
> 
> Agreed that we should fix the problem of retrieving all 
> attributes from the
> rootDSE entry.  We are just discussing the method.
> 
> Why not simply use the same method that is used for user 
> entries?  I.e. if
> you do not specify any attributes, you get them all - subject 
> to access
> control, of course.
> 
> It seems simpler and more consistent to me.  Maybe I am being 
> unreasonable?
> 
> Cheers,               ....Erik.
> 
> --------------------------------------
> Erik Skovgaard
> GeoTrain Corp.
> Enterprise Directory Engineerign Services
> http://www.geotrain.com
> 
> At 08:44 98/11/24 -0800, Bruce Greenblatt wrote:
> >At 03:35 PM 11/23/98 -0800, Erik Skovgaard wrote:
> >>Bruce,
> >>
> >>You are still not getting it.
> >>
> >
> >Thanks for pointing this out.
> >
> >>Why do we need a wildcard at all?  When I go and read user 
> attributes, I do
> >>not have to supply one.
> >
> >You don't need it.  It would just be a convenience.  Similar 
> to the empty
> >attribute type list or the special "*" attribute type 
> appearing in the list.
> >
> >>
> >>The *only* possible use would be to pick up operational 
> attributes from
> >>user entries, but we are talking about the rootDSE here.  
> It does not have
> >>any user attributes, so why define a new way of retrieving 
> all attributes
> >>from this particular entry?
> >
> >Because there is no way to retrieve all attributes from the 
> rootDSE (or any
> >other object).  It was never my intention to restrict this 
> new proposed
> >wildcard character to the rootDSE entry, just as the "*" 
> attribute type
> >name can appear against any object class.
> >
> >Bruce
> >
> >>
> >>Cheers,                    ....Erik.
> >>
> >>------------------------------------
> >>Erik Skovgaard
> >>GeoTrain Corp.
> >>The PSC Group
> >>Directory Engineering Services
> >>http://www.geotrain.com
> >>
> >>At 13:27 98/11/23 -0800, Bruce Greenblatt wrote:
> >>>Erik,
> >>>
> >>>You're right that there is no particular reason to 
> restrict the use of this
> >>>new wildcard character to the rootDSE object.  It seems 
> like there are
> >>>other objects that might well have numerous operational attributes
> >available.
> >>>
> >>>Bruce
> >>>
> >>>At 01:19 PM 11/23/98 -0800, Erik Skovgaard wrote:
> >>>>Bruce,
> >>>>
> >>>>Yes, I am aware of the reason for this discussion.
> >>>>
> >>>>The purpose of my comment was to point out that you do 
> not specify any
> >>>>wildcard character when you retrieve other entries.  Why 
> make the rootDSE
> >>>>any different?
> >>>>
> >>>>Cheers,                   ....Erik.
> >>>>
> >>>>-----------------------------------
> >>>>Erik Skovgaard
> >>>>GeoTrain Corp.
> >>>>Enterprise Directory Training and Consulting
> >>>>http://www.geotrain.com
> >>>>
> >>>>At 12:19 98/11/23 -0800, Bruce Greenblatt wrote:
> >>>>>At 09:42 AM 11/23/98 -0800, you wrote:
> >>>>>>Bruce,
> >>>>>>
> >>>>>>I am not sure what purpose this would serve.  It is 
> also inconsistent
> >with
> >>>>>>the way other searches are made.
> >>>>>
> >>>>>I think that it is actually quite consistent (see below)...
> >>>>>
> >>>>>>
> >>>>>>If you want to retrieve specific attributes, you can 
> simply specify
> them.
> >>>>>
> >>>>>As currently defined, when the "*" character appears as 
> an attribute type
> >>>>>name in the attributes component of a search operation, 
> "The "*" allows
> >the
> >>>>>client to request all user attributes in addition to 
> specific operational
> >>>>>attributes." The point of the thread was that there was no way to
> retrieve
> >>>>>all of the operational attributes of the rootDSE object without
> >>>>>specifically listing them out.  To me, this conundrum 
> seems similar to
> the
> >>>>>problem that is solved by the "*" attribute type name.  
> That's why I
> >>>>>suggested using another special attribute type name 
> (namely "+").  One
> >>>>>problem that I thought that I heard with simply 
> specifying the attributes
> >>>>>of the rootDSE that you want to retrieve, is that many DSA
> implementations
> >>>>>will add vendor specific attributes (e.g. via auxiliary 
> object class
> >>>>>definitions), so that there is no way for the LDAP 
> client to know what
> all
> >>>>>of the operational attributes of the rootDSE object are.
> >>>>>
> >>>>>Bruce
> >>>>>
> >>>>>>
> >>>>>>Cheers,                  ....Erik.
> >>>>>>
> >>>>>>-----------------------------------------
> >>>>>>Erik Skovgaard
> >>>>>>GeoTrain Corp.
> >>>>>>LDAP & X.500 Training and Consulting
> >>>>>>http://www.geotrain.com
> >>>>>>
> >>>>>>At 21:44 98/11/22 -0800, Bruce Greenblatt wrote:
> >>>>>>>I'd prefer something analogous to the "*" character that can
> >currently be
> >>>>>>>used in the attribute type list when requesting 
> operational attributes.
> >>>>>>>Having an additional special character wouldn't change 
> the LDAP v3
> >>>>>>>protocol.  Perhaps if the attribute type list includes 
> the special
> >>>>>>>character "+", then this would be an indication that 
> the client is
> >>>>>>>requesting all available operational attributes for the objects
> matching
> >>>>>>>the search filter.  
> >>>>>>>
> >>>>>>>Bruce
> >>>>>>>
> >>>>>>>At 02:14 PM 11/22/98 -0800, David Boreham wrote:
> >>>>>>>> 
> >>>>>>>>>If this is the case then IMHO we need some sort of fast-track
> >>>>>>>>>process to identify, agree and document definitive 
> changes which
> >>>>>>>>>are to apply to a base IETF standard such as LDAPv3 
> (call it an
> >>>>>>>>>Implementor's Guide?) - new RFCs should only be 
> necessary to cover
> >>>>>>>>>major changes, e.g. introduction of LDAPv4.
> >>>>>>>>
> >>>>>>>>Such things exist. e.g. RFC2181, which clarifies 
> >>>>>>>>and corrects RFC822 et al.
> >>>>>>>>
> >>>>>>>>Having one for LDAP seems like an excellent idea.
> >>>>>>>>
> >>>>>>>>Start writing !
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>================================================
> >>>>>>>Bruce Greenblatt              bruceg@innetix.com
> >>>>>>>http://www.innetix.com/~bruceg
> >>>>>>>================================================
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>================================================
> >>>>>Bruce Greenblatt              bruceg@innetix.com
> >>>>>http://www.innetix.com/~bruceg
> >>>>>================================================
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>================================================
> >>>Bruce Greenblatt              bruceg@innetix.com
> >>>http://www.innetix.com/~bruceg
> >>>================================================
> >>>
> >>>
> >>>
> >>
> >>
> >================================================
> >Bruce Greenblatt              bruceg@innetix.com
> >http://www.innetix.com/~bruceg
> >================================================
> >
> >
> >
>
Follow-Ups:
- RE: Clarification of RootDSE information retrieval required
  - From: Erik Skovgaard <eskovgaard@geotrain.com>
Prev by Date: I-D ACTION:draft-ietf-ldapext-ldapv3-vlv-02.txt
Next by Date: LDAP application intelligence
Index(es):
- Chronological
- Thread