Re: Q: LDAP C API: LDAPAPIFeatureInfo.ldapaif_name

[Mark Smith <mcs@netscape.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.
> 
> That is:  LDAP_API_FEATURE_x -> "x"

Right.  I expect that support for widely used standards track controls
such as server side sorting will be specified as a standards track C API
extension, so I plan to use SERVER_SIDE_SORT as the feature name and
LDAP_API_FEATURE_SERVER_SIDE_SORT as the macro name.


> ...
> 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.

This sounds okay to me, but in my opinion the "X_" convention is
somewhat overrated in that as an implementor I might guess that a new
proposal will be standards track and therefore not preface it with "X_"
(but the IETF might decide otherwise).  Or vice-versa.


> ...
>   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...

And also standards track documents should avoid repurposing names that
have already been used in widely deployed implementations.  But that is
just common sense.


> ...
> >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.

Right.  Also, I think developers who use the API will demand names
anyway.  Humans just prefer names.  I realize there is more overhead in
that name conflicts can occur while OID conflicts should not.

-- 
Mark Smith
Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.  Got LDAP?