[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: retrieving operational attributes (was Re: Clarification of RootDSE information retrieval required)
Bruce,
If you want to extend the scope of the discussion to user entries, I have
no problems with your proposal.
Cheers, ....Erik.
-----------------------------------
Erik Skovgaard
GeoTrain Corp.
LDAP & X.500 Training and Professional Services
http://www.geotrain.com
At 19:16 98/11/25 -0800, Bruce Greenblatt wrote:
>At 09:34 AM 11/24/98 -0800, Erik Skovgaard wrote:
>>Bruce,
>>
>>Agreed that we should fix the problem of retrieving all attributes from the
>>rootDSE entry. We are just discussing the method.
>
>Let's make sure about that. I don't think that we're discussing the exact
>same thing (but we're close).
>
>If all we want to do is to be able to retrieve rootDSE attributes, they
>could just be reclassified as suggested (by David Chadwick, I think)
>previously. I think that, this might make currently compliant LDAP
>servers, suddenly non-compliant if the server doesn't treat the empty
>attribute list correctly. I think that this is what Erik is talking about.
>
>If we are looking for a generic method of retrieving all of an object's
>operational attributes, then a new mechanism should be used. Changing the
>meaning of the empty attribute list or the "*" in the attribute list has
>the potential of breaking existing LDAP clients that aren't expecting scads
>of extra operational attribute values. It would definitely also make
>compliant LDAP servers, non-compliant. I think that this is what I'm
>talking about.
>
>The generic operational attribute retrieval problem subsumes the rootDSE
>problem, but may not be a necessary problem to solve. I think that it'd be
>nice to have a way to get things like "lastModifiedTime" and
>"creatorsName", etc. without having to list them all out, or even to know
>all of the various LDAP-generic and vendor-specific operational attributes.
> I'd only support a solution to this generic problem that doesn't break
>anything.
>
>Bruce
>
>>
>>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
>>>================================================
>>>
>>>
>>>
>>
>>
>================================================
>Bruce Greenblatt bruceg@innetix.com
>http://www.innetix.com/~bruceg
>================================================
>
>
>