Re: Q: LDAP C API: LDAPAPIFeatureInfo.ldapaif_name

[JR Heisey <jr.heisey@mediagate.com>]

"Kurt D. Zeilenga" wrote:
> 
> At 05:47 PM 6/17/99 -0700, JR Heisey wrote:
> >So if I have an extension for the controls identified with
> >the macros
> >
> >#define LDAP_CONTROL_SORTREQUEST       "1.2.840.113556.1.4.473"
> >#define LDAP_API_FEATURE_X_CONTROL_SORTREQUEST         2001
> >
> >This reads to me that one of the strings returned in
> >ldapai_extensions is "CONTROL_SORTREQUEST".
> 
> Actually it should be "X_CONTROL_SORTREQUEST" or the
> macro should be LDAP_API_FEATURE_CONTROL_SORTREQUEST.

Noted. Thanks.

> 
> That is:  LDAP_API_FEATURE_x -> "x"
> 
> One thing that isn't consistent is namespace requirements
> for API extensions.  Maybe we should just say:
> 
>         LDAP_X_*
>         LBER_X_*
>         ldap_x_*
>         ber_x_*
> 
>   are reserved for private and experimental extensions to this
>   specification.  It is RECOMMENDED that all new private and
>   experimental extensions confine themselves to the "X" namespace.

I would agree with.

I just hit me that there is no way to query the supported
controls
and identify those controls by its OID. The macro name space
is bound
to have collisions. And what about quering the server too?
Perhaps
all extended LDAP API extensions defined within the IETF
process should
have an OID assigned? I think this would be a good start in
managing the
LDAP API extensions.

How about it Mark? Do you think using OIDs would be a better
way of identifing API extensions and controls? The
ldapaif_name member
of the LDAPAPIFeature structure could be used as a friendly
name.

> 
>   All other names within the consumed namespace is reserved
>   for future revision of this standard and/or standard-track
>   extensions to this specification.  Implementations which have
>   used names which later become used by a revision of this
>   standard and/or standard-track extension to this specification
>   MUST rename private and experimental extensions
>   such they do not conflict.
> 
> Obviously, it's wise for implementators to stay involved in
> the standardization process to avoid such conflicts...
> 
> >However it occurs to me that for controls
> >the string could be its OID such as "1.2.840.113556.1.4.473".
> >Would this be appropriate?
> 
> There are features which aren't controls or extended operations.

-- 
-
J. R. Heisey