[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
retrieving operational attributes (was Re: Clarification of RootDSE information retrieval required)
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
================================================